Stargatefinance Hydra Pool Backing and OFT Redemption

Stargatefinance Hydra connects native liquidity pools with supported chains that receive pool-backed Omnichain Fungible Tokens (OFTs). A pool-to-Hydra transfer locks native assets in a StargatePool contract and mints a corresponding representation through a StargateOFT contract. Transfers between Hydra chains burn and mint that representation; redemption burns it and releases native assets from a supported pool. Finite pathway credits limit the amount that can return to native pools. Delivery still requires LayerZero messaging, and redemption access depends on continuing chain support.

A Hydra token can retain pool backing even when insufficient pathway credits prevent a particular cross-chain transfer.

From native pool assets to a Hydra balance

A pool-to-Hydra pathway extends an existing native asset pool to a supported destination chain through a backed token representation. First, the sender selects the native asset, amount, recipient and matching Hydra deployment on a supported pathway. The source StargatePool then locks and retains the transfer assets when the source transaction commits. Next, LayerZero V2 carries the message for verification and destination execution. Finally, StargateOFT uses its mint authority during destination execution to create the recipient’s corresponding token balance. Hydra supplies access to that backing without requiring a separate native liquidity pool on every receiving chain. The receiving token remains a representation, with its own contract identity.

The transfer changes where the recipient holds the asset and how that holding relates to native liquidity. It does not physically move one token contract across blockchains. Source and destination contracts maintain separate balances, while the messaging and credit systems coordinate their state changes. Supported asset deployments determine which pool-to-Hydra relationships exist.

Backing accounts and pathway credits

Hydra representations need native backing; redemption to native pools also requires enough allocated credit on the selected pathway. Pool backing covers obligations across the system. Finite pathway credits determine how much value a connection to a native pool can carry. A large native pool balance alone does not establish that every destination pathway has available capacity.

Pool balances and outstanding representations

Hydra OFT representations draw their backing from native assets held in Stargate liquidity pools. Those assets support redemption across the connected system, subject to supported pathways. The representation and its backing are separate holdings in separate contracts; counting both as freely available native liquidity would confuse an outstanding claim with the assets supporting it.

Assets retained in native pools

Stargate maintains a pool-level accounting invariant: each pool balance must cover its local unallocated credits plus credits allocated to remote pathways. Allocating credits assigns transfer capacity against existing assets. It does not add native tokens to the pool or create another independently spendable pool balance.

Supply across connected Hydra chains

Within Stargate’s asset accounting, a system-level invariant requires total pool balances to cover OFT supplies plus total values locked. This is an accounting relationship across the relevant protocol assets. It does not make balances of unrelated tokens interchangeable or establish a dollar valuation for the system.

Dynamic credit allocation

Stargate V2’s AI Planning Module, also called the Planner, reallocates credits toward pathways with transfer demand. CreditMessaging coordinates credit updates through LayerZero messages. V1 used static pathway credits; V2 uses dynamic allocation. This changes how the protocol distributes available capacity, while the requirement for sufficient backing remains. Rebalancing does not establish that every route always has sufficient credits.

Burn-and-mint transfers between Hydra chains

A Hydra-to-Hydra transfer burns the source representation and mints its counterpart on the destination chain without drawing native assets from a pool. LayerZero V2 carries the instruction between the relevant contracts. The backing relationship continues across the change in location, so a recipient on another Hydra chain still holds a representation supported by native pool assets.

The native backing stays within the pool system. Continuing chain support still constrains the transfer. V2 pathways configured for OFT destinations use an unlimited-credit setting that does not decrease on transfers.

What changes when a Hydra OFT returns to a native pool?

Returning a Hydra OFT to a native pool burns the representation and releases the corresponding native asset from that pool to the recipient. This OFT-to-pool path changes the token form as well as its chain location. A usable redemption route needs the matching asset deployment, sufficient pathway credits and continuing support on the participating chains. Pool backing describes the relationship that makes redemption possible; these route conditions determine whether a particular return can execute.

Redemption reduces outstanding representation supply. The recipient obtains native pool assets after applicable transfer deductions. Transfer quote amounts describe the expected output.

Immediate source settlement and later delivery

Instant Guaranteed Finality concerns an accepted Stargate swap’s settlement and destination-liquidity assurance, while LayerZero still needs to deliver its cross-chain message. For transfers to native pools, allocated credits reserve destination liquidity; paths configured for OFT destinations use an unlimited-credit setting. Source settlement therefore precedes the recipient’s observable destination balance. LayerZero’s Decentralized Verifier Networks verify the relevant state changes, and Executors handle destination execution. The finality property addresses the success of the underlying Stargate transfer; destination delivery still takes time.

A source transaction confirmation establishes a different state from destination completion. Transfer tracking can distinguish a message in transit from a completed transfer, while the destination transaction and token balance show the resulting holding. An expected output in a quote remains a proposed transfer amount until execution establishes delivery.

Insufficient credits on an otherwise backed asset

A backed asset can still lack credits on a pathway to a native pool, causing PathLib to reject the source call with Path_InsufficientCredit. Backing measures assets supporting the system’s obligations; allocated credit measures a route’s available capacity. V2’s Planner can reallocate credits, although that mechanism does not establish when a rejected route will become available. The error occurs before that attempted swap successfully commits, so its occurrence does not demonstrate a completed burn or destination delivery.

Open full-size image

Which chain-support dates constrain Hydra redemption?

Stargate V2 support ends on October 23, 2026 for Gravity, Camp, GOAT and Metis, before their offchain-service deadline on October 30. The later date concerns LayerZero’s DVN and Executor services. It does not extend the earlier Stargate asset deadline. A chain can therefore have different dates for protocol asset support and the services that deliver messages.

The Stargate asset deadline covers USDC.e, Hydra USDT and WETH on Gravity and GOAT. On Camp, it covers USDC.e and WETH. Metis has separate pool-withdrawal instructions for USDT, ETH and Metis liquidity-provider positions. Those holdings require the exit action appropriate to their contract type. A pool-withdrawal instruction does not describe burning a Hydra representation.

Earlier Stargate V2 wind-down dates covered Botanix on July 30, EDU Chain on August 28 and Superposition on September 8, 2026. Aurora, Taiko, LightLink and Gnosis followed on September 23. The September 30 offchain-service dates for the latter group did not extend Stargate asset support. These chain-specific restrictions leave the Hydra mechanism available elsewhere within its supported network.

Continuing support makes pools on Ethereum, Arbitrum, Base and BSC possible redemption destinations for affected Hydra holdings. Relevant asset coverage and route capacity still govern access to those pools. Failure to act before full support deprecation means losing access to affected funds. The published schedule also allows changes to impacted chains and dates.

Taxi delivery for composed Hydra transfers

Taxi supports a Hydra transfer that also requests destination application logic, such as a vault deposit or a swap following asset delivery. Stargate switched all transaction delivery to Taxi on October 1, 2026. Bus previously bundled transfers to reduce gas costs and did not support destination composition.

The transfer message

Taxi carries a single transfer per Stargate message. In the documented contract interface, a non-empty composeMsg with an empty oftCmd selects this composable mode. Pool backing and credit accounting still govern the asset movement. Composition adds instructions to the destination workflow without replacing Hydra’s asset representation or creating additional backing.

Destination application logic

A destination vault deposit or swap adds the receiving application’s requirements to the asset transfer. The application must implement the requested logic. Hydra’s backing relationship explains the transferred asset, while the destination operation determines what the application does with it. Taxi’s composition support alone does not specify a vault return or the output of a separate swap.

Hydra contracts and the wider transfer interface

Stargate’s EVM protocol contracts define Hydra’s pool-backed asset relationships, while the transfer frontend also handles a broader set of LayerZero OFTs and other routes. Frontend coverage includes non-EVM transfers; the StargatePool and StargateOFT protocol contracts remain EVM-only. A route available through the same application can therefore use a different mechanism from Hydra. Interface coverage does not establish a Hydra deployment on that chain.

LayerZero’s Value Transfer API exposes Stargate alongside OFT, CCTP and Aori routes. StargatePool and StargateOFT implement the IOFT interface, allowing applications to integrate their respective transfer functions through a shared contract interface. That compatibility preserves their different roles: one holds native assets, while the other controls backed representation supply. Liquidity-pool accounting explains the backing; transfer quote amounts describe the terms of a particular movement. Neither expands Hydra beyond its supported assets, contracts and pathways.