Designing a Restaking Protocol from Zero: What I Got Wrong at NexusFi
Early 2024, I'd just co-founded NexusFi. We had a whitepaper, a testnet, and a number we needed to hit: 9% APY on Nibiru tokens through restaking.
That number wasn't arbitrary. It was roughly what we needed for the economics to make sense for the validator sets we wanted. Hit it and we had a real protocol. Miss it and we had a whitepaper.
I spent the first few months making architecture decisions I'd never made before, and I didn't fully understand the consequences of most of them until much later. Some were right, some weren't. This is me going back through them.
Why Nibiru instead of Ethereum#
The obvious question: why build restaking on a Cosmos chain when EigenLayer was right there on Ethereum, with the liquidity and the integrations?
A few reasons, and honestly they compound.
Validator economics. EigenLayer's model was: ETH stakers restake to extend security to new protocols (the AVSes), and the yield comes from those services paying operators. Problem is, you're competing for attention from validators who already run serious Ethereum infrastructure. You're a side gig for them.
On Nibiru the validator set was smaller and newer and genuinely wanted more yield. We weren't asking them to bolt extra infrastructure onto an already complex setup. We were offering to become a real part of how they made money.
EVM on Cosmos. Nibiru runs EVM-compatible contracts on top of Cosmos. Solidity contracts plus IBC for cross-chain coordination. Best of both worlds, in theory. In practice it mostly worked, but "in theory" is doing some lifting there.
Timing. Their mainnet was just launching. Being early to a new chain's validator ecosystem means your protocol gets an outsized say in how that chain's economics end up shaped. That's worth more than it sounds like.
The risk, obviously: less liquidity, less tooling, fewer people who've already hit the failure modes you're about to hit.
The architecture#
The core mechanism: users deposit liquid staking tokens representing staked Nibiru. NexusFi aggregates them and restakes across a curated validator set, earning extra yield from the security services those validators provide to other protocols.
Three decisions in there ate most of my time.
Who gets to be a validator, and what happens when they misbehave#
We ran an operator whitelist with on-chain governance for additions and removals. Operators had minimum uptime requirements, had to post collateral in our contract, and accepted a slashing condition: if their node caused a cross-chain security incident attributable to NexusFi restaking, they lost part of it.
We deliberately did not slash automatically on first evidence. Two stages instead: an alert window where the operator could dispute, then execution if undisputed. Slower, but it meant a monitoring bug couldn't burn someone's collateral.
Good call in hindsight. We had cases on testnet where our own alerting would have fired wrongly. If we'd shipped auto-slashing, that would've been real money.
The cross-chain trust model (the weak link)#
The 9% needed yield coordinated from multiple sources across Cosmos and EVM. The hard part: how does the EVM-side contract know what the Cosmos-side validators earned, and how do we attribute that back to specific depositors?
We used IBC. A Cosmos module tracked validator yield and sent periodic attestations to the EVM contract, which updated depositor balances.
The uncomfortable part: we were trusting our own module to report yields accurately. A bug there means wrong yield attribution on the EVM side. We papered over it with a secondary oracle that independently calculated expected yield ranges and paused attestations if the reports drifted too far. It worked, but it was a patch over a trust assumption.
Would I design it that way today? No. I'd use a ZK-proven attestation so the EVM contract verifies Cosmos state itself instead of trusting an intermediary module. In early 2024 that tooling wasn't really practical. It is now.
The 9% APY model (the part I'd most redo)#
To get to 9% we had to stack three things: base Nibiru staking yield (~4-5%), restaking premium (~2-3%), and our own protocol incentive tokens (~1-2%).
The math worked. The problem is that last bucket. If 2% of your 9% comes from your own token emissions, then the user's "9% APY" is really 7% plus exposure to your token price. Token drops, their actual return drops, even though the number in the UI still says 9%.
We disclosed this in the docs but not in the UI. The UI just said "9% APY". I pushed for splitting it out and we settled on a tooltip. I should have pushed harder. What the UI implies matters more than what the docs technically say.
The EigenLayer integration we threw away#
We built an EigenLayer integration so Ethereum-side depositors could restake ETH through NexusFi toward Nibiru validators. Ran it on testnet for a while. The mechanics worked. The economics didn't.
EigenLayer operators were already running heavy infra for higher-yield AVSes. Getting them to also run Nibiru validator software for our incremental yield didn't clear their engineering overhead. We'd have been paying operator costs that ate most of the yield we were generating.
So we killed it before mainnet. Killing a feature is fine, that's just product. What stings is we spent real engineering time proving it was technically possible long before we checked whether it was economically worth doing. Wrong order. Check the economics first.
What I'd change if I rebuilt it#
Prove Cosmos state to the EVM contract with ZK instead of trusting our own module to attest it. That was the weakest link in the whole design and I knew it at the time.
Split the APY by source in the UI. "9% APY (7% staking + 2% NXF rewards)" is more honest and produces calmer users, because nobody's surprised when the token moves.
Validate economics before integration. The EigenLayer work was good engineering answering a question we never needed answered.
NexusFi had real flaws and it shipped to mainnet anyway. I still think that counts for more than a cleaner protocol that never left testnet.