Introduction
Kalypso is a circuit-agnostic ZK proof marketplace which supports private inputs using TEEs. As the validity of ZK proofs can be easily checked, safety violations aren’t that much of a concern in Kalypso. On the other hand, ensuring that proofs are received within certain time bounds could be important to many users of Kalypso. It has thus been proposed to use economic stake as collateral in Kalypso to provide response time guarantees.
Symbiotic is a leading restaking protocol which allows ETH holders (“Depositors”) to deposit their staked ETH in vaults and vouch for operators in different networks. The ETH in these vaults is subject to slashing if the operators they vet and delegate to, fail to follow the rules governing the networks. In exchange, operators share the fees they receive from these networks for providing prescribed services with such vault depositors.
The Kalypso smart contracts are to be deployed on Arbitrum while Symbiotic vault and protocol contracts are on Ethereum. As operators on Kalypso could benefit from delegations from various Symbiotic vaults, it is desirable to take this into account during the design of Kalypso’s smart contracts.
Constraints
Details of the Symbiotic protocol and the restrictions they impose are detailed in the tweet here: x.com
Bridge design
Details of the design of the bridge that transmits the stake information from Symbiotic contracts on Ethereum to Kalypso contracts on Arbitrum are here
The Symbiotic Delegation Tracker contract on Arbitrum
It is responsible for managing the snapshot data generated by the Oyster-based bridge and received from the Transmitter above. It has functions to expose the latest delegation information from Symbiotic vaults as well as the delegation information at a specific timestamp. The contract can accept delegations in multiple tokens like restaked ETH, BTC and POND.
The submitSnapshot function is responsible for capturing snapshots and enforces the following conditions:
- Snapshot captureTimestamp should be at least
SDseconds ahead of the captureTimestamp of last complete snapshot noOfTxsshould be consistent across all the partial snapshotstxIndex<noOfTxs- Signature should be from the signing key that is verified against the PCR values of the bridge enclave image.
- stakeData should be of the correct format which has key-value pairs of operators and stakeDelta
submitSnapshot function updates the latest complete snapshot information once the last chunk of the snapshot is received. It updates the TC based on the delay from the last complete snapshot before this. Higher the delay from the last complete snapshot, higher the TC so as to provide higher incentives when gas prices are high and the network is congested.
Delegation data submitted is the change in delegation since the last snapshot and operators missing in the data are assumed not to have any changes to their delegations. Delta instead of absolute values are used to deal with race conditions when updates to delegations from a new snapshot and processing of slashing penalties occur simultaneously.
Native staking
While Symbiotic provides the flexibility to restake tokens, it is not suitable for stakers who want to control whom their stake is being allocated to. They may not want to depend on vault operators to decide the choice of operators. To ensure flexibility to allocate stake to any operator, native staking can be implemented as well where stakers can directly pick an operator and stake towards them directly without having to deal with Symbiotic vaults.
Symbiotic is currently deployed on Ethereum which makes transactions expensive. Native staking is done directly on Arbitrum which has cheaper transaction costs. The native staking contract manages the stake information and the tokens provided by stakers which are delegated to specific operators. It has functions that can provide the latest staking information for specific users and operators.
Stake Manager
The Stake Manager consolidates stakes from both Symbiotic and Native staking, managing conversions between different tokens (e.g., POND, restaked POND, restaked ETH). It interacts with the Price Oracle to ensure accurate pricing at the time of job creation, which is crucial for fee distribution. A minimum stake (MIN_STAKE) is required for an operator to be assigned jobs. Operators have to self stake tokens to be able to receive jobs, there will be restrictions on the number of jobs that can be assigned based on self stake as each job assigned needs a specific amount of self stake and a specific amount of total stake. Self stake is given to the slasher while the rest of the stake is burnt when slashed.
How is slashing implemented?
Details of the design to implement slashing in case operator isn’t able to provide a valid proof within the specific time is here.
Operator Registry
Operators need to register themselves and provide the % of fees they would retain for providing the infrastructure and executing jobs as well as an address where they would like to receive the fees.
Fee distribution to Symbiotic vaults
Vault depositors are eligible to receive a share of the fees operators earn in exchange for the due diligence they perform. The precise mechanism of distributing the fees downstream to depositors is left to the vaults, though a few mechanisms are provided out of the box to assist vault operators. More details of the mechanism are available here.