Architecture

Interactions with HyperCore.

beHYPE leverages CoreWriter for all interactions with HyperCore including delegation management.

When a user stakes/unstakes with beHYPE, CoreWriter transfers their HYPE to/from the contract’s staking balance, interacting with HyperCore in a completely non-custodial way to transfer HYPE between HyperEVM and HyperCore.

This eliminates the need for a “middleman” account to hold custody of funds. All of the logic is fully implemented on-chain and therefore verifiable.

As Hyperliquid is still a young chain and slashing is not yet live, based on auditor feedback a keeper is in place to audit abnormal unstaking requests e.g. if slashing occurs, unstake requests trying to front run withdrawal pre-slashing can be slashed. This safety measure does not change redemption logic. The entire redemption logic remains transparent, auditable, and enforced by code.

Stake delegation

Hyperliquid staking rewards are distributed once a day, Once HYPE is delegated, it starts earning block rewards, which are paid daily and compounded into the delegated position. To reflect this growth, the protocol needs to regularly update its record of total assets.

beHYPE uses CoreWriter for stake delegation, delegating once every 6 hours to maximise staking rewards.

Users are able to stake to the validator of their choice when staking. Particularly relevant for users eager to participate in governance via LSTs.

To do this users select one validator from the beHYPE active set to delegate their HYPE to using the UI. This adds a bytestring containing the name of their chosen validator in their mint transaction. Users choice is captured on-chain and stake is verifiably routed to their desired community validator using CoreWriter.

If a user does not want to choose their validator, their stake is delegated equally amongst all validators in the beHYPE active set.

Exchange rate

beHYPE state is updated through L1 Precompiles, with exchange rates are computed dependencies on off-chain data are eliminated.

A keeper runs twice a day, beHYPE calls the staking delegation Precompile so whenever anyone wants to know the protocol’s total assets they can call the read function “exchange rate” on the beHYPE contract to get its real-time exchange rate.

The call supplies an input equal to the staking rewards accrued since the previous rebase. How that reward figure is produced is verifiable on-chain, These metrics include the rewards earned, although slashing isn't live, the same mechanism is designed to handle any slashing events.

The state is updated twice a day, since rewards are distributed once a day this programmatically ensures the exchange rate reflects rewards and slashing in real time even if the reward distribution mechanism updates.

Last updated