Skip to main content
Use the interface returned by GET /v2/gvaults/yield-sources to select the correct deployed interface. Do not assume every gVault implements the same operation lifecycle.

​
Before any deposit

  1. Resolve contractAddress from the current environment’s catalogue.
  2. Confirm the receiving address is allowlisted.
  3. Call asset() and verify the returned token and chain.
  4. Convert human-readable amounts to the asset’s native units.
  5. Estimate the result and set application-level slippage or minimum-output policy.

​
USTB-style synchronous deposit

USTB-style gVaults accept an ERC-20 approval followed by a deposit:
The receiver receives gVault shares and must be authorized for deposits. Record the actual returned share amount; previews are estimates, not receipts.

​
Immediate withdrawal

Check the owner’s current synchronous capacity before submitting:
Within those limits, the owner can call:
If a caller other than owner is used, confirm the deployed contract’s authorization rules before building that transaction.

​
Queued redemption

For an exit above current synchronous liquidity, submit:
Persist the chain, contract, transaction hash, owner, share amount, and returned requestId. Once the request is processed, the same owner claims:
Do not infer claimability from elapsed time. Read onchain request state or simulate the claim against the current block before prompting the user.

​
Centrifuge-style operations

Centrifuge-style gVaults expose explicit request and claim methods:
Centrifuge-style deposit methods are restricted to the configured Ground router. A user address cannot call them directly. For a fully direct customer deposit, select a synchronous gVault; otherwise coordinate the router flow with Ground. See gVault contract interfaces and Handle asynchronous gVault operations.