Venusprotocol records your first supply in vTokens

An available market sets the starting conditions

A first supply belongs to a specific account, network, and lending market, so matching the token symbol alone does not establish where the position will exist. The underlying-token address identifies the asset a token market accepts. The vToken address identifies the market recording your supply. Match both addresses with the selected network and pool before approving a transfer.

Standalone isolated pools were deprecated and removed from the application. Core Pools remain separate from those legacy positions, including deployments sharing the BeaconProxy contract architecture. A historical isolated-pool address does not establish an available destination for a new supply. Existing positions there require market-specific recovery checks.

Token approval does not complete a supply

For ERC-20 or BEP-20 underlying assets, approval permits the selected market to transfer tokens up to its allowance; the supply action creates the lending position. An approval identifies the spender and the permitted amount. For a direct token-market supply, the spender is the vToken market proxy. The approval call goes to the underlying-token contract. Keep the network's native asset available for approval and supply gas.

A limited allowance bounds the amount the market may pull. Increasing it grants more permission, without reserving supply capacity or minting vTokens. Some underlying tokens require clearing an existing allowance before setting a replacement. Complete any required reset before the new approval. The allowance must cover the requested supply when the market attempts the transfer.

You can abandon an unsubmitted supply request after approval. Doing so leaves the existing token permission in place.

Supply capacity determines whether to proceed

A sufficient token balance and allowance do not establish supply availability, because the Comptroller also applies market listing, supply-cap, and pause checks when minting executes.

The supply cap limits the market's total supply measured in underlying-token units. It is not a personal allowance or an account-specific deposit ceiling. The proposed supply must fit within the market's remaining capacity, under its applicable implementation.

Approval does not reserve that capacity. Other activity or a configuration change can alter availability before your supply executes.

A paused supply action or an unlisted market calls for stopping the deposit attempt. Insufficient allowance calls for addressing that permission before proceeding. Waiting for a confirmed approval resolves only the allowance issue; it does not remove a market restriction.

The exchange rate connects receipt units to underlying units

The vToken quantity and the supplied-token quantity describe different units, with the market exchange rate connecting them after both balances have the correct decimal scaling. Multiplying a vToken balance by its normalized exchange rate gives the corresponding underlying-token amount. A smaller displayed receipt balance therefore does not, by itself, show a smaller underlying position.

In human-readable units, the relationship is underlying amount = vToken balance * underlying units per vToken . For minting, dividing the underlying amount actually received by that exchange rate gives the receipt amount, subject to integer rounding. The rate describes conversion into the market's underlying asset, not a dollar price or an annual percentage yield.

Contract responses use integer base units and scaled exchange-rate values. Read the actual token decimals and normalize the rate before applying human-readable arithmetic. Treating a raw exchange-rate integer as an ordinary decimal price can produce a large apparent mismatch.

Mint records identify the completed supply

A completed direct supply has a mint record identifying the supplying account, the underlying amount received, and the vTokens credited. Compare the credited vTokens with the account's vToken balance change. Decode the event using the selected market's deployed interface. Keep the transaction hash and block with those amounts so a later comparison refers to the same operation. BNB Chain Core token methods can report a protocol failure despite a successful EVM transaction. The relevant mint record and balance change distinguish a completed supply from a transaction that only executed successfully at the network level.

Token transfer fees, where applicable, can make the market receive less underlying than the wallet requested to supply. Receipt accounting follows the amount received.

---

A limited allowance can delay an otherwise valid supply

In this hypothetical example, a BNB Chain Core token-market account has no vTokens and requests a supply of 4.74 underlying tokens. Its allowance covers less than that amount. The wallet covers the requested token amount and retains BNB for gas. Assume supply is permitted, cap headroom covers the request, and the underlying token charges no transfer fee. The normalized exchange rate is 0.0237 underlying tokens per vToken.

Venusprotocol vTokens: Verify your first supply

• The exchange rate connects receipt units to underlying units
• Mint records identify the completed supply
• A limited allowance can delay an otherwise valid supply

View full-size image

The insufficient allowance prevents proceeding with that request unchanged. The account can authorize enough underlying tokens for the chosen amount, completing any required allowance reset before the replacement approval. It then waits for confirmation. It can also stop before submitting the supply. Increasing the allowance changes the permitted transfer amount; it does not create the deposit. An existing approval remains separate from the unsent supply.

Once the allowance covers the request and the market checks still pass, submission sends the supply request for execution. Assume it completes at the stated rate. Underlying received: 4.74 tokens. Normalized exchange rate: 0.0237 underlying tokens per vToken. Before base-unit rounding, the calculation minted = received / rate gives 200 vTokens.

The mint record should show those received and credited amounts. With no other receipt-token movement, the account balance becomes 200 vTokens. Multiplying that balance by the same rate gives 4.74 underlying tokens. A missing mint record or different received amount calls for reconciliation before another supply attempt.

Fresh and stored reads can describe different accounting states

The stored exchange rate uses the market's last accrued accounting state, whereas an accruing read updates interest calculations before returning the value used to represent your supply. In the BNB Chain Core interface, exchangeRateStored() does not accrue interest first. exchangeRateCurrent() and balanceOfUnderlying() do, so they are not ordinary view functions.

A client can obtain an accruing result through a simulated call without broadcasting a transaction. That simulation does not persist its state changes on-chain. For reconciling the first mint, use values from its execution context. A later accrued underlying balance answers a different question: what the receipt position represents at that later accounting state.

A direct supply does not create a borrowing obligation

A direct mint exchanges underlying assets for receipt tokens, while borrowing records a separate debt against the account under the pool's collateral and liquidity rules. A displayed borrowing limit describes available capacity. It does not show an amount already borrowed. Supplied assets can support later collateral-backed borrowing, subject to eligibility and configuration. Leveraged operations can combine borrowing, swapping, and supplying within one transaction. A transaction containing a supply leg therefore needs its full action context; the vToken credit alone does not describe the transaction's borrowing obligations.

Native BNB and token markets require different inputs

The supply entry point changes with the selected market: BNB Chain Core token markets pull an approved underlying token, while native BNB supplies carry transaction value.

BNB Chain Core markets

ERC-20 and BEP-20 supply

The direct token-market method is mint(uint256 mintAmount) . Its amount uses underlying-token base units. Calls go to the market proxy, whose current implementation determines the interface and execution rules.

Native BNB supply

The standalone VBNB contract accepts a payable mint() call, and its receive function also supports supplying BNB. Native BNB supply does not require an underlying-token allowance. Transaction value is the BNB supplied; gas fees pay for execution.

BeaconProxy markets

Core Pools outside BNB Chain use BeaconProxy VTokens with their own implementation family. Their direct token supplies operate on the selected underlying asset. Do not copy the native BNB call convention into those token markets. The shared vToken role does not establish interchangeable transaction inputs.

Redemption remains a separate, conditional operation

After a supply completes, returning the assets requires redemption under the market's current rules; cancelling the earlier wallet request can no longer reverse the completed operation. redeem specifies receipt-token units, while redeemUnderlying specifies underlying units. The market burns the corresponding vTokens when redemption succeeds.

Available cash and Comptroller policy constrain withdrawal, including account liquidity and action pause state. Later borrowing can change the collateral the account must retain. Where a BNB Core market applies a configured treasury redemption charge, it deducts a percentage of the gross underlying redemption amount before paying the recipient. Underlying-token transfer behavior can also affect wallet proceeds. Even an account without borrowing can encounter a paused redemption or insufficient market cash.