**Proposal: Optional knBONE Rewards for Real Yield Staking**

[Seizanshib]

(1) Introduction and Objective

This proposal aims to enhance the flexibility and utility of the K9 Finance Real Yield Staking program by introducing an option for users to receive their earned rewards in knBONE tokens, in addition to the current BONE token rewards. The primary objective is to directly incentivize the adoption and usage of knBONE within the K9 Finance ecosystem, particularly by simplifying the process for users who wish to deploy their Real Yield Staking rewards into existing knBONE-based farming opportunities, such as the knBONE/KNINE liquidity pool. This initiative aligns with the DAO’s goal of fostering a vibrant, interconnected DeFi ecosystem on Shibarium and continuously improving user experience by offering more strategic options for their earned yield.

---

(2) Benefits to K9 Finance Community

Introducing optional knBONE rewards offers several key advantages for the K9 Finance community:

• Enhanced knBONE Utility: By making knBONE directly accessible as a reward, its utility as a core asset in the K9 Finance ecosystem is significantly amplified, encouraging broader adoption beyond just liquid staking.
• Streamlined Farming & Reinvestment: Users engaged in Real Yield Staking can seamlessly transition their rewards directly into knBONE-based farming pools (e.g., the Bone Yard’s knBONE/KNINE pool), reducing friction and gas costs associated with manual swaps. This directly motivates participation in vital liquidity provision.
• Increased Liquidity & TVL: Easier access to knBONE via rewards is expected to drive greater participation in knBONE farming pools, leading to increased Total Value Locked (TVL) within these pools and deeper liquidity for knBONE trading pairs.
• Stronger Ecosystem Interconnectivity: This proposal further links the Real Yield Staking and Farming functionalities, creating a more cohesive and efficient user journey within the K9 Finance dApp.
• User Empowerment: Providing users with a choice in how they receive their rewards grants them greater control over their asset management strategies, catering to different financial goals and preferences.

---

(3) Proposal Details

(a) WHAT
The proposal is to modify the Real Yield Staking smart contract and the K9 Finance dApp interface to offer users a choice in their reward token. When claiming rewards from either locked or non-locked KNINE staking positions, users will have the option to receive:
• BONE (default): The current reward token, distributed as usual.
• knBONE: An equivalent value of knBONE tokens, calculated based on the prevailing real-time BONE:knBONE exchange rate within the K9 Finance protocol.

The conversion mechanism will leverage the existing logic already used within the Bonecrusher dApp for converting BONE to knBONE (or vice-versa), ensuring accurate and fair exchange rates.

(b) WHO
• KNINE Stakers/Lockers: The primary beneficiaries, gaining flexibility in their reward choices.
• knBONE Holders & Farmers: Benefit from increased knBONE utility and potentially deeper liquidity in farming pools.
• K9 Finance Development Team: Responsible for the technical implementation, smart contract modifications, and UI/UX updates.
• K9 Finance DAO Management Council: Oversees the implementation, ensuring it aligns with the DAO’s strategic vision and product roadmap.
• K9 Finance DAO Community: Benefits from enhanced platform utility, liquidity, and overall ecosystem growth.

(c) WHERE
The changes will primarily be implemented on:
• Shibarium Network: The underlying blockchain for the Real Yield Staking contract and knBONE token.
• K9 Finance dApp (app.k9finance.com): The user interface for Real Yield Staking, where the new reward claiming options will be presented.

(d) WHEN
A proposed timeline for implementation (subject to developer availability and audit schedules):
• Phase 1 (2-4 weeks post-approval): Technical specification and design, including smart contract modification planning and UI/UX mockups for the new reward options.
• Phase 2 (4-8 weeks post-Phase 1): Smart contract development, integration with existing conversion logic, and internal testing on a testnet (e.g., Puppynet).
• Phase 3 (2-4 weeks post-Phase 2): Independent security audit of the modified smart contract.
• Phase 4 (1-2 weeks post-Phase 3): Frontend (dApp) development and integration, user acceptance testing.
• Launch (Estimated 10-18 weeks post-approval): Deployment of the updated Real Yield Staking contract and dApp interface to the Shibarium mainnet.

(e) HOW
Implementing this proposal will involve:

1. Smart Contract Modification: The RealYieldStaking contract will need to be updated to include logic for converting earned BONE rewards into knBONE based on the live exchange rate (using an oracle or direct contract call to the knBONE contract for the convertBONEToKnBONE function) if the user selects this option during the claim process.
2. UI/UX Development: The K9 Finance dApp’s Real Yield Staking interface will be updated to display a clear choice between “Claim BONE” and “Claim knBONE” (or similar wording) for eligible rewards, potentially with a toggle or separate buttons for simplicity.
3. Leveraging Existing Mechanics: The proposal relies on the knBONE contract’s convertBONEToKnBONE function (or similar existing ratio calculation methods) to ensure accurate and fair conversion rates between BONE and knBONE at the time of claim. This minimizes the need for entirely new complex logic.
4. Security Audits: A comprehensive audit of the modified RealYieldStaking contract will be mandatory to ensure the security and integrity of user funds and reward distribution.

---

(4) Impact Assessment

• Short-Term Impacts
• Immediate increase in perceived utility and flexibility for KNINE stakers.
• Early adopters of the knBONE reward option will find it easier to bridge into farming activities.
• Development resources will be allocated to implementing these changes.

• Long-Term Impacts
• Sustained growth in knBONE adoption and utilization across the Shibarium DeFi ecosystem.
• Potentially higher and more stable TVL in knBONE-based liquidity pools, strengthening K9 Finance’s position as a core infrastructure provider.
• Reinforced interconnectivity between K9 Finance’s various products (Real Yield Staking, Liquid Staking, Farming).
• Increased transaction volume on Shibarium as users streamline their reward management and reinvestment.
• Risks and Mitigation
• Risk: Smart Contract Vulnerabilities. Any modification to core contracts introduces potential risks.
• Mitigation: Mandate rigorous, independent third-party security audits of the modified RealYieldStaking contract prior to deployment. Conduct thorough internal testing on testnets.
• Risk: User Confusion. Introducing new options could potentially complicate the user experience for some.
• Mitigation: Design a “stupid simple” (heard some old fella said something about that… ) and intuitive UI/UX for reward claiming. Provide clear in-app explanations and educational materials to guide users through their choices.
• Risk: Conversion Rate Volatility. While leveraging existing mechanics, extreme market volatility during the exact moment of claiming could lead to minor fluctuations in perceived value.
• Mitigation: Transparently display the current BONE:knBONE exchange rate prominently within the claiming interface. Users would be making an informed decision based on the live rate.

---

• Metrics for Success
• Percentage of users choosing knBONE rewards: Track how many users opt for knBONE versus BONE from Real Yield Staking.
• Increase in TVL within knBONE farming pools: Measure the growth of liquidity in pools like knBONE/KNINE after the feature’s launch.
• User feedback and sentiment: Gather qualitative feedback on the new feature’s ease of use and perceived value.
• Number of unique wallets holding knBONE: Monitor overall knBONE adoption.

[ShelbyGT500]

Thank you, Seizan, for taking the time to create this proposal.

One consideration is whether the development costs and smart contract re-audit for this new function would be justified for K9 compared to the gas fees users currently pay for swapping, but I appreciate the flexibility this addition would bring to K9 users.

For the UI, the team has a similar design in the Add/Remove Liquidity pop-up window. If the current “Claim” button triggered a similar pop-up, it could offer three options:

Claim rewards in Bone

Claim rewards in KnBone

Claim a 50/50 split for users looking to add rewards back into the main farm with the correct liquidity balance.

I have wondered about a similar function regarding the claim EsKnine button, since it can only be vested, could the EsKnine “Claim” button be replaced with a “Claim & Vest” button to streamline the process?

I can see why the separate vesting page needs its own button, this would be required for cases where the users cannot fully vest their earnings, allowing manual partial vesting. A “Claim & Vest” button would require the user to have sufficient vesting limits to complete the transaction.

Thank you for sharing your proposal!

[BigBoi]

I am for this proposal.

The feature could be visually similar to the unzap function as well.

3 choices of reward… Bone/KnBone/K9

@ShelbyGT500

One consideration is whether the development costs and smart contract re-audit for this new function would be justified for K9 compared to the gas fees users currently pay for swapping, but I appreciate the flexibility this addition would bring to K9 users.

Agreed

[Couch_Adventures]

I don’t think this is impossible, but I’m still trying to wrap my head around how this could work most efficiently.

The $BONE we receive from the Real-Yield is BONE that’s been purchased either on the Shibarium side or was bridged over from ETH.

In order to allow $knBONE as a reward, the team would have to either stake ETH Bone and hold knBONE for rewards, or we’d have to swap the existing BONE for knBONE on Shibarium. This can/will cause a slippage situation that we’d have to reciprocate.

It would take time to get a measure of how many users are wanting knBone vs BONE or a mix and this can fluctuate. How can we most efficiently have knBONE available and make sure to keep the LP balanced to keep slippage low or non-existent?

For me, I’d want to split my rewards to make it faster to farm my rewards, but others may only want Bone and others still might only want knBONE. This causes a need to solve how to keep the LP balanced at any given time.

I like the idea, just need a better understanding from those more familiar with how to provide the option without affecting swaps, slippage, and making sure knBONE is as close to BONE’s price as possible at all times.

[Seizanshib]

@Couch_Adventures

The $BONE we receive from the Real-Yield is BONE that’s been purchased either on the Shibarium side or was bridged over from ETH.

---

What the docs say:
• Users stake ERC‑20 BONE on Ethereum via Bonecrusher and immediately receive knBONE according to the protocol’s internal exchange rate (knBONE is a non‑rebasing share token ( plz note, a NOT rebasing token!!! ); amount stays fixed, value tracks the pool). knBONE is then moved to Shibarium by the K9‑owned bridge when submit(..., transferToL2=true) is used. (K9 Finance)
• Real Yield Staking rewards are paid in BONE and are funded by the validation rewards fee‑split from the liquid staking system (e.g., 95% to Real Yield, 5% to DAO Treasury; exact splits are DAO‑set and on‑chain). (K9 Finance)
• The knBONE contract exposes view functions like convertBONEToKnBONE/convertKnBONEToBONE to compute the live rate; these are not DEX swaps. (K9 Finance)

Implication for rewards:
You can’t synchronously mint knBONE on Shibarium at claim time. knBONE is minted when BONE is deposited on Ethereum and then bridged into Shibarium by K9’s bridge (validator‑signed). That means “Claim in knBONE” needs a pre‑funded knBONE buffer on Shibarium, not a swap on an AMM. (K9 Finance)

Practical design that avoids touching LP (0% AMM slippage path):

1. knBONE Buffer/Vault on Shibarium
   • Treasury/ops periodically top up the buffer by staking BONE on Ethereum with submit(..., transferToL2=true) so newly minted knBONE lands on Shibarium. Claims that choose knBONE draw from this buffer. (K9 Finance)
   • The claim modal offers BONE (default) / knBONE / split. If the buffer is insufficient, the flow auto‑fallbacks to BONE (no market impact).
   • Show the knBONE amount using the protocol rate from convertBONEToKnBONE(BONE_amount) for full transparency. (K9 Finance)
2. Lightweight “RewardsRouter” helper (optional, keeps RYS lean):
   • RYS continues accounting rewards in BONE. When a user picks knBONE, RYS sends the equivalent BONE debit to the router (or records it), and the router transfers knBONE from the buffer to the user.
   • Ops automation later replenishes the buffer from Ethereum deposits to keep it topped up; this is off the hot path (no claim‑time delays).

Safety & ops rails (answering the slippage/LP concerns):
• No AMM swaps in the default path ⇒ no LP disturbance at claim.
• High/low watermarks for the buffer (e.g., refill when <L; pause knBONE option or cap split when critically low).
• Daily knBONE quota to smooth bursts in preference.
• Circuit breaker UI notice if the internal BONE:knBONE rate deviates unusually (it’s a share token, so rate normally drifts gradually with rewards/slashing). (K9 Finance)

If you still want “always available” knBONE:
Offer an optional “Claim & Swap” fallback that routes via a DEX only when the buffer is empty, with tight slippage caps/TWAP checks. Call this out as a convenience path that can touch LPs; let users opt in.

Why this squares with your points:
• “Where does knBONE come from?”, from staking BONE on Ethereum and then bridging. That’s why a pre‑funded buffer is the cleanest delivery mechanism. (K9 Finance)
• “Keep knBONE ≈ BONE and avoid slippage”, using protocol rate + buffer transfer means no AMM slippage and knBONE retains its share‑based peg behaviour by design. (K9 Finance)
• “Do we buy BONE to fund rewards?”, by docs, RYS is funded from validation rewards routed in BONE by the fee‑split; you don’t need to market‑buy for each claim. (K9 Finance)

---

[NoOne]

Hi Seizanshib,

Hope you are doing great.

Thank you for your proposal.

Before diving into deeper discussions on feasibility and advisability - I suggest running a simple survey among holders to determine how big the real demand for this is.

If people don’t care in what they get their rewards (like me for example) - there is no point even exploring this option. Only if there is strong demand it might be worth returning to this conversation.

Also, one thing to remember - that every conversion from Bone to KnBone is an extra transaction on Shibarium which (depending on how contract is optimised) may disappear.

[Seizanshib]

Appreciate the thoughtful take. I don’t think we need a survey. Surveys give stated preferences; the cleaner signal is revealed behavior. Let’s add a small, optional toggle in the claim modal, BONE (default) or knBONE, and see what people actually choose over a short trial.
This is one of those “didn’t‑know‑they‑wanted‑it” quality‑of‑life upgrades. Not every decision should be gated by pre‑polled demand; sometimes the right move is to reduce friction and let the UX speak for itself. Making Bonecrusher easier to use matters even if some holders feel indifferent today.

BONE should sit and secure the network while knBONE flows. BONE is the staking/validator asset for Shibarium, so it’s the thing we want locked and delegated; knBONE is the liquid token users spend, trade, and use in DeFi. That’s the whole point of liquid staking: keep the underlying BONE working for consensus and let the liquid representation move. Bonecrusher routes staked BONE to K9’s validator via the NodeOperatorRegistry, which is exactly how it contributes to Shibarium security. (Shibarium Documentation, K9 Finance)

On “extra transactions”: this doesn’t have to turn Bonecrusher into a transaction farm. We’re not trying to maximize tx count; there are other apps/projects which are doing that. This is just an optional payout choice at claim, BONE or knBONE, so people who prefer knBONE don’t have to do the extra hop themselves. Keep it simple, keep BONE as default, and avoid busywork clicks.

Low‑risk way to proceed, then:

• Add the BONE / knBONE toggle in the claim modal, keep BONE as default.
• Keep the flow clean, still a single, straightforward claim for the user.
• Instrument opt‑in and revisit after a short window; if it’s not used, it retires on its own.

Bottom line: skip the survey and test the opt‑in. If people choose knBONE, we’ve made Bonecrusher easier and aligned with the protocol, BONE locked for validation, knBONE circulating in DeFi. And practically, this sets up a clean workflow: claim your KNINE rewards as they vest, claim knBONE from Real Yield, and drop both straight into the farm. That’s exactly the flow I’d use myself, why I proposed this in the first place.

---

[NoOne]

I get what you are saying.

But every change to the financial flow must be carefully assessed and executed.
It can become a significant lift for the Devs with various security implications involved as well.

So personally, I am not comfortable mandating something like this to the Devs just because its nice to have and good to see. Because if it does turn out that there is little demand for this - their efforts may have been better spent elsewhere.

Plus having more ways for tokens to travel/be stored provides more potential vectors for attack by malicious actors.

I’d say we need the Devs/DAO management to weigh in on the amount of lift this really puts on them and complexity involved. If it’s no biggie - then shouldn’t be a problem and always good to have such ‘quality of life’ option. If it is though - then more careful consideration is needed before pulling the trigger.

Overall - nice to have if can be executed easily and safely.
Depends on the lift involved. That’s how I’m thinking.

[buzz]

I agree with No One’s comments. This is a “nice to have” feature with an 18-week proposed roadmap and would be quite involved security-wise. It would be important to understand if there is demand for this feature.

Another point that was not addressed is that the current design was purposeful and revenue generating vs. cost prohibiting. The design suggestion above puts the onus of Ethereum gas fees on the DAO, vs the individual user which increases product operation costs. Instead of the user paying their own gas fees it assumes that gas subsidy will be co-owned by all DAO members on behalf of the most active users. This could be offset by a fee (such as the knBONE > ETH bridge) but that fee is also an aspect of the product that has gotten some of the poorest user feedback, despite it just covering the gas fees for the DAO

It’s a thoughful and good proposal, but I am unclear if there is demand

[Seizanshib]

Thanks for bringing in a developer’s perspective, it really helps to see things from that angle. I’ll put my proposal on hold for now and revisit it later. I’ll admit I’m a bit lazy and love smooth, easy-to-use tech, so I still believe this idea could improve the overall user experience. That said, as mentioned above, it might not be worth the time, effort, and cost to implement just yet.