Blog — RIVR

Product May 2, 2026 • 4 min read

Introducing stRIVR: liquid staking without the lockup

A derivative token that earns base yield while remaining tradeable, composable, and useful as collateral. Here's how it works.

For most of crypto's history, staking has meant a tradeoff: you either earn yield on your assets or you keep them liquid — almost never both. Validators required long unbonding windows, and your capital sat idle waiting for the next epoch.

stRIVR is our answer to that tradeoff. When you stake RIVR through the protocol, you receive stRIVR in return — a fully transferrable ERC-20 token that represents your underlying stake plus all accrued rewards. Because rewards are reflected in the exchange rate rather than rebased into your wallet, stRIVR behaves like any other asset: you can trade it on Lattice DEX, deposit it into Nimbus Vaults, or pledge it as collateral on lending markets.

Under the hood, stRIVR is backed 1:1 by RIVR locked with a distributed set of validators. When you redeem, the protocol routes the unbonding process across multiple operators in parallel, completing in 7 days post-RIP-042. For users who need immediate liquidity, secondary markets quote stRIVR at a tight spread to its net asset value — the result of arbitrageurs continuously closing any gap.

The token is now live on mainnet. Documentation and audit reports are linked from the developer portal.

— Mira Chen, Protocol Engineering

Engineering Apr 18, 2026 • 5 min read

Bridging RIVR to Solana via Orbit

Cross-chain settlement, finalized in under two seconds. We walk through the messaging primitives that made it possible.

Bridging assets between heterogenous chains is the hardest problem in DeFi infrastructure. The standard approach — lock on one side, mint a wrapped version on the other — concentrates billions of dollars behind a single bridge contract and a handful of multisig signers. We chose to do this differently.

RIVR's integration with Orbit treats cross-chain transfers as message passing rather than asset wrapping. When you bridge stRIVR from Ethereum to Solana, the source chain emits a cryptographic attestation: "this address has burned X stRIVR." A decentralized set of relayers picks up that attestation, signs it under a threshold scheme, and submits proof on the destination chain. Solana then mints native stRIVR-SOL only after verifying the proof against Orbit's on-chain light client of Ethereum state.

The result is a settlement loop that completes in 1.7 seconds on average, with no single party holding custody. Slashing rules on Orbit's validator set make collusion economically irrational at any meaningful scale.

For users, none of that complexity is visible. You select a destination chain, sign once, and the protocol handles routing. For builders, the same primitives are exposed through the SDK — bridge any tokenized asset, not just stRIVR.

— Dev Patel, Bridge Engineering

Metrics Apr 4, 2026 • 3 min read

Q1 2026 protocol report

TVL crossed $2.4B, realized yield averaged 8.5%, and 38M RIVR was burned. The numbers, with commentary.

The first quarter of 2026 was a milestone period for RIVR. Total value locked grew from $1.6B to $2.4B — a 50% increase that came almost entirely from existing users adding to their positions, rather than mercenary capital chasing emissions. We see that as a vote of confidence in the protocol's design.

Realized yield for stakers averaged 8.5% annualized over the quarter, up from 7.8% in Q4. The lift came from increased fee generation on Lattice and three new vault strategies launched on Nimbus. Yield was paid in real-time, blockwise, with no claim transactions required from users.

On the supply side, 38M RIVR was bought back and burned through the 15% fee-to-burn mechanism. That puts circulating supply down 0.95% quarter-over-quarter, even after factoring in staker emissions. We view this deflationary footprint as a structural strength: as the protocol scales, every additional dollar of fees compresses supply.

The full report includes a breakdown of fee sources, validator performance, and our progress against the 2026 roadmap. Download it from the resources page.

— Alex Rivera, Treasury

Research Mar 21, 2026 • 6 min read

Why we burn 15% of protocol fees

A defense of the fee-to-burn ratio against three common critiques, with simulations covering every major fee regime.

When we designed RIVR's fee model, we wrestled with a question every protocol eventually faces: where should fees go? Three options were on the table — return everything to stakers, keep everything in the treasury, or split the difference and burn a portion. We landed on the third, with 15% of all protocol fees programmatically used to buy and burn RIVR on open markets.

The critique we hear most often is that burns are accounting theatre — they don't change cash flows, just the count of outstanding tokens. That's true in a narrow sense. But it ignores the second-order effect: burns convert variable yield from one token (whatever fees were paid in) into a deflationary pressure on a single, governance-aligned asset. For long-term holders, that's not theatre. It's structurally relevant.

The second critique is that 15% is too low — that more should be burned to maximize price appreciation. We modeled this across every plausible fee regime and the answer is consistent: above ~22% burn, staker yields fall below the threshold where validators can sustainably operate. The protocol's security budget collapses before any deflationary benefit materializes.

The third critique is that 15% is too high — that fees should compound for stakers. Our simulations show that path eventually centralizes the network around large stakers, because compounding favors size. The current split keeps the smaller stakers competitive over multi-year horizons.

15% is not arbitrary. It's the number that maximized long-run network security in our simulations. We're prepared to revisit it through governance if the data changes.

— Sasha Lin, Research

Explainer Mar 7, 2026 • 5 min read

Restaking, explained

A from-scratch primer on what restaking actually is, why it's powerful, and where the real risks live.

If you've spent any time around DeFi recently, you've heard the word "restaking." It's one of those terms that sounds technical enough to gloss over, which is exactly when you should slow down and understand it. This post is for everyone who has nodded politely through a restaking explanation and walked away no clearer than before.

Start with regular staking. When you stake RIVR, you're putting capital at risk to secure the network. Validators run nodes, propose blocks, and get slashed if they misbehave. In exchange, the protocol pays them — and by extension, you — for keeping the network honest.

Restaking extends that economic security to other systems. Instead of unstaking your RIVR to use it elsewhere, you keep it staked and opt in to also securing a secondary service: an oracle network, a bridge, a data availability layer. That service pays you additional yield, and in return your stake becomes slashable if you misbehave on its rules too.

The appeal is obvious: more yield, same capital. The risk is also obvious, but easy to underestimate. Every additional service you opt into is another potential slashing surface. A bug in any single service can take down stake that was supposed to be securing the base layer.

RIVR exposes restaking through Aether Layer with conservative defaults: capped exposure per service, mandatory audits, and an opt-in flow that requires explicit per-service consent. The goal isn't to maximize yield — it's to make the tradeoff visible.

— Mira Chen, Protocol Engineering

Governance Feb 22, 2026 • 4 min read

RIP-042 retrospective: lowering the redemption window

The DAO voted to shorten unbonding from 14 days to 7. Here's what we learned, and what we'd do differently.

RIP-042 passed with 88% support and 12.4% turnout — the highest turnout we've seen on any proposal. The change cuts the stRIVR redemption window from 14 days to 7, bringing it in line with comparable LSTs while preserving enough delay to absorb a coordinated slashing event.

Three things went well. First, the temp-check process surfaced concerns from validators early, which let the final proposal include a clause raising the validator self-bond minimum to compensate for the shorter unbonding window. Second, the on-chain vote ran smoothly, with no contract-level issues across the 7-day voting period. Third, execution through the timelock was uneventful: the change went live exactly 48 hours after passing, on schedule.

Two things didn't go as well. The forum discussion was dominated by a handful of large delegates, with most smaller holders not weighing in until the on-chain vote itself. We're considering structured polling earlier in the process to capture broader input. Second, we underestimated how much off-chain analysis would be needed to evaluate the proposal's economic effects — the research team produced the simulations, but only after community pressure. That work should happen by default for any proposal touching parameters.

The post-mortem doc is open for comment on the forum. We'll fold lessons learned into the next governance framework update.