Ciphernode Bonding Contracts

[hmzakhalid]

Create the foundational bonding system supporting both USDC and native ENCL tokens, with preferential selection for native token holders.

Tasks

• Create a Ciphernode Bonding contract
• Support USDC & native ENCL token bonding: Dual bonding
• [~] Implement preferential selection weighting for ENCL bonds
  • Replaced by tickets mechanism and removed from scope
• Track bond amounts, timestamps, and weighting multipliers
• Enforce minimum USD-denominated bond requirements
• Integration with CiphernodeRegistry
• Per-ticket slashing and top-up

[hmzakhalid]

So, this was way more convoluted than I thought it would be.

We started with the simplest idea! one collateral to register. That evolved into a license so we can slash a committed stake, and then into tickets and allowed slashing per job per ticket. All of that was implemented all of that, then refined it with more testing and reviews.

The jank showed up when tickets lived inside Eigenlayer. In Eigenlayer the AVS never holds user assets. Operators keep their tokens and only allocate a slice of their stake to our operator set. This is normal for a license(simple collateral), but it is awkward for tickets that we want to treat like a balance you can debit. You end up doing shares to underlying to allocated calculations just to decide if a ticket exists. It looks like this:

• operator deposits ENCL into a strategy and gets deposit shares
• operator allocates a magnitude to our operator set in allocation manager
• slashable amount equals allocated magnitude times total shares mapped to underlying
• turning that into tickets forces shares to tokens to tickets math with timing edges around allocation effects

So I chose to move the tickets out of Eigenlayer. I kept the license on ENCL in Eigenlayer, and made tickets individual held in our bonding manager. That change made the tickets real money in our escrow, top ups are simple, and activation rules are clear.

The tradeoff is dual slashing(not sure if this is the right word) now exists & dual allocation delays & more confusion for the operators. ENCL license can be slashed on Eigenlayer, and tickets can be slashed in USDC in our escrow.

how Eigenlayer manages assets

flowchart LR
  subgraph Eigenlayer
    SM[Strategy manager holds tokens]
    DM[Delegation manager tracks operator status]
    AM[Allocation manager tracks magnitude per strategy]
  end
  subgraph Our contracts
    AVS[Service manager of avs]
  end
  OP[Operator]

  OP --> SM
  OP --> DM
  OP --> AM
  AVS --> AM

  N1[Tokens never move to avs]
  N2[Slash is percent of allocated magnitude]
  SM --- N1
  AM --- N2

Loading

• tokens stay with strategy manager
• operator becomes an eigenlayer operator via delegation manager
• operator tells allocation manager how much magnitude to allocate to our operator set
• our avs can only slash a percent of the allocated slice
• we cannot transfer user funds from eigenlayer and we cannot spend them

This is why tickets inside eigenlayer felt wrong. You cannot treat those allocations like a wallet. You have to translate shares to underlying to allocated, then hope allocation timing does not bite you mid check.

current flow end to end

flowchart TD
  A[Node] --> B[Register as eigenlayer operator]
  B --> C[Stake ENCL into strategy manager]
  C --> D[Allocate magnitude to our operator set & Register]
  D --> E[allocation >= licenseCost]
  E --> F[Register as ciphernode]
  F --> G[Buy tickets with usdc in bonding manager]
  G --> H[Node becomes active]

Loading

• license is enforced on the allocated ENCL slice
• tickets are individual usdc items in our escrow with id face amount slash amount status
• a ticket goes inactive at ninety five percent slash and burns at one hundred
• topping up can reactivate an inactive ticket
• node is active when it holds at least one available ticket

where this leaves us

right now we’re in a hybrid situtaion: license on Eigenlayer, tickets in our escrow. It works, but it creates two levers for the same incident. Eigenlayer can slash the ENCL license slice, and our BondingManager can slash a USDC ticket. That means two deallocation timelines, two places to look for “why am I inactive,” i.e did we hit the ticket first, or the license first, and what does “making someone whole” mean across two very different buckets.

So keeping Eigenlayer buys us a trust anchor for the license, operators can’t rug instantly, we have a credible, delayed, slashable commitment, and there’s a shared security story that’s bigger than just us. It also gives us discovery and onboarding: Eigenlayer operators already know the flow, can find our AVS in the directory, and can join by allocating a slice for the license (ofcourse theyd need to run a ciphernode to participate). That lowers the try Enclave friction.

If we remove Eigenlayer and run everything in our own escrow and registration, life gets simpler but we’d lose the Eigenlayer trust signal and the operator network effect from EL.

[hmzakhalid]

After a discussion with @auryn-macmillan around a potential way to fit our model into Eigenlayer i.e., make the tickets ephemeral, the Eigenlayer asset model still keeps fighting us. There are certain issues that come with it. Our nodes require tickets to be able to participate in the protocol.

Ephemeral tickets in EL translate to “selection weight = slashable allocation.” That sounds fine until we realize allocations are percentages over deposit shares, not a spendable balance. The moment an operator queues a withdrawal, their delegated shares drop immediately. Yes, the queued amount is still slashable during the delay and we can haircut it, but our ticket weight has already shrunk mid epoch. For month long E3s that means the committee we published can degrade after reveal. To make this safe we’d need a maintained collateral covenant at assignment, watchers to slash inside the delay window and small buffers. It’s all doable, but it’s a lot of machinery around a problem we don’t have if tickets are just balances in our escrow.

We also discussed capping E3 at (or below) the withdrawal delay. That gives us time to slash before an exit becomes completable, but it doesn’t stop weight from collapsing right after selection. On top of that we’re now scheduling against two clocks (withdrawal delay and allocation effect blocks), and top ups don’t help immediately because allocation increases respect the operator’s allocation delay. The operational exposure remains even though the funds are technically still slashable for a while.

Using slashing as a temporary lock doesn’t help either. In EL, slashing is final: slashed shares are burned or redistributed to a recipient we choose. If we set our treasury as recipient and refund later, those funds live off EL while we hold them, aren’t staked or allocated, and any refund to the operator ignores delegators who also lost shares.

The hybrid we shipped (license on EL in ENCL, tickets in our BondingManager in USDC) technically works, but as we discussed it’s awkward in practice. Two ledgers, two slash paths, two deallocation timelines, and two different answers to "why am I inactive?" On the EL side we’re constantly translating shares → underlying → allocated with rounding and exchange rate drift, and we only learn about changes via events, there are no callbacks when someone withdraws or reallocates. On the escrow side everything is explicit and integer debit a ticket, mark status, done. The split adds complexity without improving the security story for tickets.

So it makes sense to ditch EL and stop forcing it in. For our tickets and license model, Eigenlayer isn’t a good fit.

@auryn-macmillan @ryardley @0xjei @ctrlc03 @cedoor @ozgurarmanc

[0xjei]

After a discussion with @auryn-macmillan around a potential way to fit our model into Eigenlayer i.e., make the tickets ephemeral, the Eigenlayer asset model still keeps fighting us. There are certain issues that come with it. Our nodes require tickets to be able to participate in the protocol.

Ephemeral tickets in EL translate to “selection weight = slashable allocation.” That sounds fine until we realize allocations are percentages over deposit shares, not a spendable balance. The moment an operator queues a withdrawal, their delegated shares drop immediately. Yes, the queued amount is still slashable during the delay and we can haircut it, but our ticket weight has already shrunk mid epoch. For month long E3s that means the committee we published can degrade after reveal. To make this safe we’d need a maintained collateral covenant at assignment, watchers to slash inside the delay window and small buffers. It’s all doable, but it’s a lot of machinery around a problem we don’t have if tickets are just balances in our escrow.

We also discussed capping E3 at (or below) the withdrawal delay. That gives us time to slash before an exit becomes completable, but it doesn’t stop weight from collapsing right after selection. On top of that we’re now scheduling against two clocks (withdrawal delay and allocation effect blocks), and top ups don’t help immediately because allocation increases respect the operator’s allocation delay. The operational exposure remains even though the funds are technically still slashable for a while.

Using slashing as a temporary lock doesn’t help either. In EL, slashing is final: slashed shares are burned or redistributed to a recipient we choose. If we set our treasury as recipient and refund later, those funds live off EL while we hold them, aren’t staked or allocated, and any refund to the operator ignores delegators who also lost shares.

The hybrid we shipped (license on EL in ENCL, tickets in our BondingManager in USDC) technically works, but as we discussed it’s awkward in practice. Two ledgers, two slash paths, two deallocation timelines, and two different answers to "why am I inactive?" On the EL side we’re constantly translating shares → underlying → allocated with rounding and exchange rate drift, and we only learn about changes via events, there are no callbacks when someone withdraws or reallocates. On the escrow side everything is explicit and integer debit a ticket, mark status, done. The split adds complexity without improving the security story for tickets.

So it makes sense to ditch EL and stop forcing it in. For our tickets and license model, Eigenlayer isn’t a good fit.

@auryn-macmillan @ryardley @0xjei @ctrlc03 @cedoor @ozgurarmanc

thank you @hmzakhalid for the explanation! I completely agree on the takes on the hybrid approach. I would avoid the complexity and, forcing us on something we have identified already to be a stretch, doesn't makes sense to me.

[hmzakhalid]

So, last week was mostly about ditching EigenLayer and implementing a clean ticket+license story for enclave that actually works on chain and is nice to run off chain.

I met with Armanc and Rudi, walked the sortition model e2 and we settled on ephemeral tickets instead of individual ticket ids being tracked on chain, so now ciphernodes will only track a single ticketBalance and derive ticket count as floor(ticketBalance / ticketPrice) - ciphernodeActiveJobs when they do sortition. Nodes need to track ciphernodeActiveJobs so they know which node is currently engaged by committees.

Where it got tricky is the on chain side, we need to make sure committee proposals are verifiable against the balances that existed when the E3 was requested, not after someone tops up to game a lower score.

Our sortition currently looks like this

• Each node computes tickets = floor(ticketBalance / ticketPrice) - ciphernodeActiveJobs.
• For each ticket index t ∈ [0, tickets), compute score = H(seed, e3Id, node, t).
• A node’s score is the minimum over its tickets; call the index of that minimum argminIdx.
• Globally, sort nodes by their minimum score and take the first K.
• Propose the committee on-chain and the challenge window starts.
• No Challange? Committee Published.
• Otherwise replace the committee if there's a better K with a better minimum score.

But Nodes can buy more tickets during this challenge window and land a lower score. We need a way to snapshot Ticket Balance at the exact moment the E3 was requested, not after they juiced their balance mid-challenge.

I toyed with an allocation delay first: when you top up USDC tickets, they only become usable after delay seconds. That does blunt the “buy then challenge” griefing, but the challenge window can reset on every successful challenge, so we can’t pick a delay that’s always right. It’s a partial fix, not an anchor.

So we need a Snapshot, our BondingRegistry maintains a rolling Sparse Merkle Tree (SMT) over leaf = H(node, ticketBalance).
On every balance change we:

• update the leaf and the root, and
• emit TicketBalanceUpdated(node, delta, newBalance) and TicketBalanceRootUpdated(root).
• At E3Requested, the Enclave records three snapshot fields on the E3:
  • ticketBalanceRootSnapshot (the SMT root from BondingRegistry at that block),
  • ticketPriceSnapshot,
  • seed
• From that point on, all proposals and challenges for this E3 must prove balances against the snapshot root. Any top ups after the request don’t exist for that E3.

sequenceDiagram
  participant Op as Operator
  participant BR as BondingRegistry (SMT)
  participant ENC as Enclave (E3)
  participant P as Proposer
  participant Ch as Challenger

  Op->>BR: buy tickets / withdraw
  BR-->>Op: TicketBalanceUpdated(node, delta, newBalance)
  BR-->>Op: TicketBalanceRootUpdated(root)

  Op->>ENC: (later) E3Requested(...)
  ENC->>BR: read current ticketBalanceRoot
  ENC-->>ENC: snapshot {root, price, seed} on E3
  ENC-->>All: E3Requested(e3Id, snapshot fields)

  Note over Op: Off-chain: nodes compute tickets & scores at snapshot
  P->>ENC: proposeCommittee(e3Id, winners[], argminIdx[], cutoffScore, proofs[])
  ENC-->>P: verify SMT proofs, argmins, recomputed scores, cutoff

  alt Challenge: outranker
    Ch->>ENC: challengeOutranker(e3Id, node*, t*, proof*)
    ENC-->>Ch: recompute score*; %% invalidate if score* < cutoff
  end
  alt Challenge: better-ticket
    Ch->>ENC: challengeBetterTicket(e3Id, winner, tLower, proof)
    ENC-->>Ch: recompute; %%invalidate if tLower beats argmin
  end

  ENC-->>All: If no valid challenge by deadline -> CommitteePublished

Loading