Skip to main content
Each lending pool controls a separate receipt-token deployment. The frontend configures four receipts: vXLM, vBLEND_USDC, vAQUARIUS_USDC, and vSOROSWAP_USDC. Use configured addresses and token metadata for exact tickers and decimals.

Pool shares

A receipt represents a claim on pool assets, including outstanding borrow interest. The exact conversion includes a virtual offset and native decimal rounding; use pool conversion getters rather than assuming one receipt always equals one underlying token. Pool methods take WAD quantities; token balance, transfer, mint, and burn use native i128 quantities. Underlying and receipt decimals must each be read independently.

Authorization and controls

Construction sets an admin; initialization supplies metadata and authenticates the configured admin. The lending pool normally controls mint/burn. Holder transfers and allowance-based transfers require their respective authorizations. Admin controls include maximum supply and account authorization/freeze state. Transfers can be blocked by freeze state; unconditional transferability is not guaranteed. Pool-directed burn is permitted for exit even when receipt receiving/transfers are frozen. Holding vTokens does not itself add collateral to a margin account. Earn positions and margin custody are separate.

Function signatures

These signatures are copied from the reviewed Rust implementation. env is supplied by Soroban and is not a transaction argument. Result errors and panics must be handled by the caller; simulation does not guarantee later execution. Public methods include privileged and internal-contract callbacks, not just user entrypoints.

__constructor

initialize

admin

set_admin

set_max_supply

max_supply

decimals

name

symbol

balance

total_supply

allowance

approve

transfer

transfer_from

mint

burn

burn_from

set_authorized

authorized

set_frozen

frozen

upgrade

Source reference

  • Protocol_V1_Soroban_testnet/contracts/v-token/src/token.rs