A staking receipt token can cross chains only if the destination representation preserves a claim on the stake, rather than merely copying its ticker and balance. For an integrator, the key decision is whether to redeem before bridging or transport a backed representation; that choice determines the accounting, liquidity, and failure modes your application must handle.
Model the receipt as a claim, not as the staked asset
A receipt token is an accounting claim whose value depends on a staking contract or pool. In an exchange-rate design, a holder’s share balance stays fixed while each share becomes redeemable for more underlying assets as rewards accrue. In a rebasing design, the token balance changes instead. These models are not interchangeable in a bridge: a destination token that copies the source balance can misstate the claim if it does not also preserve the relevant share price or rebasing behavior.
For an exchange-rate token, treat shares and underlying assets as separate units. If a user holds 100 shares and the current rate is 1.08 underlying per share, the indicative claim is 108 underlying, before redemption costs or slippage. EIP-4626 formalizes this distinction for tokenized vaults: convertToAssets gives an idealized conversion, while previewRedeem includes applicable fees and is a better estimate of an actual redemption. Read the source contract’s semantics; a staking receipt may not implement EIP-4626.
That accounting decision comes before route selection. A route that swaps into a liquid underlying asset solves a different problem from one that preserves the staking position; how Biswap routes cross-chain moves is useful context when the application needs to compare those cross-chain outcomes. Biswap’s role is to move and swap crypto across networks in one flow, while your integration still needs to decide whether the receipt claim itself can safely travel.
Choose whether to redeem or transport the claim
Redeem before bridging when the user wants the underlying asset on the destination chain and the source pool can satisfy the redemption. The flow is: validate the receipt, estimate redemption output, redeem shares on the source, wait for the underlying to become transferable, then bridge and optionally swap it. This is simpler to account for because the bridge carries the underlying asset, but it inherits the pool’s withdrawal queue, available liquidity, and redemption fees.
Transport the claim when the user intends to remain exposed to staking and the destination has a supported representation. A typical design locks or burns source receipt tokens, then mints a destination representation against that escrow. The bridge’s message must bind the source chain, source token, destination chain, recipient, amount, and unique transfer identifier; the destination must reject duplicate messages. Redemption then requires a defined path back to the source claim or a local pool that independently honors the representation.
Do not assume that matching token names or decimals establish backing. Verify the canonical source contract and the bridge’s mapping, and account for whether the source tokens are locked, burned, or held in a pooled reserve. If a bridge can mint more destination claims than the source escrow holds, or if an upgrade changes the mapping, the destination token can trade as an undercollateralized asset even while transfers appear successful.
Keep share pricing and bridge accounting separate
For exchange-rate tokens, preserve the number of shares across the bridge if the destination token represents those same shares. Do not convert shares to underlying at one rate, then mint an equal numeric amount of destination shares: the units differ. If conversion is required, record the rate used, its source block, rounding direction, and any fee, then calculate the destination amount with integer arithmetic. ERC-20 amounts are raw integers; apply each token’s decimals explicitly and round down when the result must not exceed the backing claim.
For example, suppose the source holds 100.000000 shares and the redemption quote is 1.08 underlying per share. If the bridge transfers shares, the destination representation should account for 100 shares, subject to the bridge’s own precision. If it redeems first, the expected output is 108 underlying before fees and execution effects. A quote may change between estimation and redemption, so enforce a minimum output or maximum loss in basis points; a tolerance such as 50 bps is only an illustrative setting, and should reflect pool depth and the user’s risk limits.
Rebasing receipts need a different policy. A bridge that locks a rebasing token must ensure its escrow balance and destination supply stay synchronized as rebases occur. Otherwise, the bridge can become short or overcollateralized without a transfer. A non-rebasing wrapper that tracks shares can simplify cross-chain supply accounting, but adds wrapper contracts, conversion logic, and another place where exchange rates can diverge.
Handle delays, depegs, and partial failure explicitly
Redemption timing is a protocol property, not a bridge guarantee. Ethereum.org’s staking documentation explains that pooled staking withdrawals depend on pool liquidity and the consensus-layer exit queue; a receipt holder generally redeems through the pool rather than withdrawing directly from a validator. Your quote should therefore distinguish an immediately executable swap from a claim that may remain queued, and avoid promising a fixed settlement time where the pool does not provide one.
Model each leg as a state transition: source receipt accepted, redemption or escrow finalized, bridge message verified, destination mint or delivery completed. Define recovery for a source transaction that succeeds while the destination leg fails, and make retries idempotent. A timeout must not trigger a second mint. Keep the source and destination token addresses, chain identifiers, decimals, and bridge message status in the integration record so operators can reconcile supply and investigate stuck transfers.
Finally, monitor the destination representation’s market price against the underlying claim. A discount can reflect redemption delay, thin destination liquidity, bridge risk, or a loss of confidence in backing; it is not necessarily a routing quote error. Biswap can help a user move and swap assets across chains, but route execution does not remove these receipt-token risks. In my integration, I would bridge the underlying after redemption unless users explicitly need the staking exposure and I can verify a fully backed, redeemable destination representation.
Top comments (0)