Designing a Restaking Protocol from Zero: Architecture Decisions at NexusFi
ShareDesigning a Restaking Protocol from Zero: Architecture Decisions at NexusFi
January 2024. I'd just co-founded NexusFi. We had a whitepaper, a Cosmos testnet, and a target: 9% APY on Nibiru tokens through restaking incentives.
The 9% target wasn't arbitrary. It was the number we needed to make the economics work for the validator sets we were targeting. Hit it, and we'd have product-market fit. Miss it and we'd be another restaking protocol with a whitepaper.
I spent the first three months making architecture decisions that I'd never made before, with consequences I wouldn't fully understand until months later. Some of them were right. Some were wrong. All of them were defensible at the time.
This is the honest account of those decisions.
Why Nibiru Chain Instead of Ethereum
The first question anyone asks: why build restaking on a Cosmos chain instead of Ethereum? EigenLayer was live on mainnet. The market was there. The integrations were there. Why go off the beaten path?
Three reasons, and they compound.
First: validator economics. EigenLayer's model in early 2024 was: ETH stakers restake their stake to extend cryptoeconomic security to new protocols. The yield comes from the Actively Validated Services (AVSes) paying operators. The problem is that the yield is additive but the validator set is fixed — you're competing for attention from validators who are already running Ethereum infrastructure.
On Nibiru, the validator set was smaller, newer, and actively looking for ways to increase returns. We weren't asking validators to run additional infrastructure on top of an already complex Ethereum setup. We were offering to become a significant part of their yield model.
Second: EVM-Cosmos interop. Nibiru runs an EVM-compatible environment on top of Cosmos. This meant we could deploy Solidity contracts while having access to IBC for cross-chain coordination. We got the Ethereum developer ecosystem and the Cosmos infrastructure layer. In theory.
Third: timing. Nibiru's mainnet was launching. Being early to a new chain's validator ecosystem means your protocol has outsized influence on the economic structure of that chain. That matters for protocol design.
The risk we were taking on: less liquidity, less tooling, less known failure modes.
The Restaking Architecture
The core mechanism: users deposit liquid staking tokens (LSTs) representing staked Nibiru. NexusFi aggregates these deposits and restakes them across a curated set of 5+ validators, earning additional yield from the security services those validators provide to downstream protocols.
The three main design decisions in the architecture:
1. Operator Selection and Slashing Conditions
Who gets to be a validator in our set, and what happens if they misbehave?
We defined an operator whitelist with an on-chain governance process for additions and removals. Operators had to meet minimum uptime requirements, stake a collateral deposit in our contract, and accept a slashing condition: if their node caused a cross-chain security incident attributable to NexusFi restaking, they'd lose a portion of their collateral.
The slashing design was conservative. We chose not to automatically slash on the first evidence of fault — instead we required a two-stage process: an alert period where the operator could dispute, then execution if undisputed. This added latency to slashing but reduced the risk of a governance bug causing an unjust slash.
In hindsight, this was the right call. We discovered two cases during testnet where our slashing alert logic would have triggered incorrectly due to a monitoring bug. If we'd had automatic slashing, real collateral would have been lost.
2. Cross-Chain Trust Model
The 9% APY required coordinating yield from multiple sources across Cosmos and EVM. The coordination problem: how does the EVM-side NexusFi contract know what the Cosmos-side validators earned, and how do we attribute yield back to specific depositors?
We used IBC for this. The Cosmos module tracked validator yield and sent periodic IBC messages to the EVM contract with yield attestations. The EVM contract updated depositor balances based on attested yields.
The trust assumption here: we trusted our own Cosmos module to report yields accurately. This is a strong assumption — it means a bug in the Cosmos module could cause the EVM contract to attribute incorrect yields. We mitigated this with a secondary oracle that independently calculated expected yield ranges and would pause the yield attestation flow if reports deviated significantly.
Would I use this same design today? Probably not. I'd use a ZK-proven attestation so the EVM contract could verify the Cosmos state without trusting an intermediary module. In early 2024, the tooling for this wasn't practical.
3. The 9% APY Model
This is the thing I spent the most time on and the thing I'd most change today.
To hit 9%, we needed to stack:
- Base Nibiru staking yield (~4-5%)
- Restaking premium from security services (~2-3%)
- Protocol incentive tokens (~1-2%)
The stacking math worked. The problem was that "protocol incentive tokens" at 1-2% meant we were partially funding yield with our own token emissions. This is common in early DeFi protocols and it's not inherently bad, but you have to be honest about what you're promising.
A user getting 9% APY where 2% comes from token emissions is actually getting 7% "real" yield plus exposure to token price. If the token drops, their actual dollar return drops even if the APY number stays the same.
We disclosed this in the docs but not in the UI. In the UI it just said "9% APY." I pushed back on this internally and we compromised with a tooltip. Probably should have pushed harder — the UI impression matters more than the docs.
EigenLayer Integration: What We Built and What We Didn't Use
We built an EigenLayer integration for the Ethereum side of NexusFi — the idea being that depositors on Ethereum could restake their ETH through NexusFi to support Nibiru validators.
We ran this in testnet for two months. The mechanics worked. But the economics didn't make sense for our validator set.
EigenLayer operators were already running significant infrastructure for high-yield AVSes. Getting them to also run Nibiru validator software for incremental yield wasn't worth their engineering overhead. We'd have been paying operator overhead costs that consumed most of the yield we were generating.
We sunset the EigenLayer integration before mainnet. The Cosmos-native restaking model generated better unit economics for our specific validator set and user base.
I mention this not because it was a failure — killing a feature that doesn't work is good product management. But it was two months of engineering work. The lesson: validate the economics before the technology. We validated that EigenLayer integration was technically possible well before we validated that it was economically worthwhile.
What Happened on Nibiru Mainnet
We shipped. We hit the 9% APY target across 5 validators on Nibiru mainnet. The staking incentive mechanics worked as designed.
The things that worked: the slashing design, the conservative oracle setup, the IBC yield attestation flow.
The things that didn't: token price volatility made the "real" yield meaningfully different from the displayed APY during volatile periods. The secondary oracle triggered several false-positive pauses in the early weeks that we had to manually override. The UI incentive token disclosure was insufficient — we updated it eventually but after several confused user questions.
The validator set performed well. The uptime requirements we'd set were achievable — we'd calibrated them against real-world data from similar chains. No slashing events occurred.
Three Things I'd Do Differently
Replace the IBC attestation with ZK-proven state. Trusting our own module is the weakest link in the design. Now that ZK light clients for Cosmos are more practical, I'd prove the Cosmos state cryptographically rather than attesting it with an intermediary.
Separate displayed APY by yield source in the UI. "9% APY (7% staking + 2% NXF rewards)" is more honest and creates better-informed users. Users who understand the token emission component are more stable liquidity — they're not surprised when token price moves.
Do the economics validation before the integration work. Two months on EigenLayer integration that we ultimately killed would have been better spent deepening the Nibiru-native mechanics. The lesson is general: validate that a component is economically necessary before building it.
NexusFi was the first protocol I architected as CTO. It had real flaws and it shipped to mainnet. I'm counting both parts as wins.