Euler.finance vaults mint shares to the receiver when a deposit completes

Updated: 2026 September 10

Euler.finance vaults record a completed positive deposit through minted shares credited to the designated receiver. To establish whether your first deposit succeeded, match the vault’s deposit event with that account’s share balance. A successful approval, a token transfer, or an unchanged wallet display alone cannot settle the question.

Missing shares after an approval or account mismatch

A missing share balance can reflect an approval without a deposit, a different receiving account, a reverted call, or delayed display data. These causes require different responses. Establishing which transaction actually ran comes before submitting another deposit.

An underlying-token approval grants spending permission. It does not execute the vault deposit or create its shares. A receipt that records only an approval therefore explains why the expected position has not appeared. The deposit remains a separate operation unless the chosen transaction deliberately bundles the necessary actions.

The paying account and share receiver can differ. Checking only the connected wallet can miss shares credited to another account. The Ethereum Vault Connector, or EVC, supports account arrangements that make this distinction relevant. The receiving address in the executed deposit identifies the balance that matters; the transaction sender alone does not establish share ownership.

Display delays need no new deposit. When the confirmed contract balance already records the expected shares, another submission would create additional exposure rather than repair the display. Conversely, a reverted deposit has no completed mint to display. A pending transaction remains unresolved until its execution status changes.

Asset input, receiving account, and share output

The deposited asset, vault contract, and receiving account determine what moves and where the resulting position appears. For an Euler Vault Kit, or EVK, vault, the deposit operation takes an underlying asset amount and a receiver. The authenticated caller supplies the assets.

An EVK deposit credits the newly minted vault shares to its receiver. The receiver’s balance on the vault contract counts shares, while its balance on the underlying token contract counts assets. Reading the underlying token contract cannot establish how many vault shares the receiver owns.

EulerEarn introduces another distinction: a depositor holds shares in the Earn vault, which allocates assets among configured strategies. Those underlying strategy positions do not imply that the depositor personally holds every strategy’s shares. For deposit verification, identify the vault that issues the position received by the account.

A share quantity also differs from an asset valuation. Interest, fees, and losses can change the assets represented by shares. Comparing token quantities without their units creates an apparent mismatch even when the deposit executed correctly. The vault’s conversion functions provide the relevant asset equivalent.

A first deposit missing from the wallet display

Suppose a depositor attempts a first deposit, but the wallet displays no vault shares. The vault, receiving account, transaction status, and balances in this example are hypothetical. The expected outcome is a positive share credit to the chosen receiver, with no subsequent share movements.

Before committing funds, the depositor identifies the accepted underlying asset and receiving account, confirms the required spending authorization, and checks the deposit preview. The amount must fit the applicable deposit limit. Simulation must also accept the actual transaction, because a preview alone does not establish that every execution condition holds.

After submission, the depositor inspects the existing transaction rather than sending another. If the deposit succeeds, its receipt contains the selected vault’s deposit event. The event records a positive share amount and the intended receiver. A contract balance read for that receiver includes the same shares. The deposit completed; the remaining mismatch concerns the wallet display.

Open full-size image

If the transaction only approves spending, its successful receipt contains the underlying-token approval. No deposit event or share credit exists. The depositor stops at that distinction, checks whether a separate deposit is already pending, and submits nothing while its status remains unresolved. Only after excluding an existing deposit should the depositor review a new deposit transaction. The confirmed outcome so far is spending authorization, not a funded vault position.

Which receipt fields prove that shares were minted?

The selected vault’s deposit event identifies the caller, receiving owner, deposited assets, and minted shares. Its emitting contract matters as much as its label. A transaction can contain events from several contracts, so an event from another vault cannot confirm the intended position.

Open full-size image

The ERC-4626 event names its recipient field owner, while the deposit function names the corresponding input receiver. Matching those addresses connects the submitted operation to the account that received shares. Keep asset and share quantities separate when decoding the event.

A balance comparison adds ownership evidence. For an account with no earlier shares and no other share movements, its resulting balance should match the minted quantity. More complicated transactions require reconciliation: transfers, additional deposits, or redemptions can change the balance after minting. A later balance therefore need not equal one earlier event’s share amount.

Use the receipt’s block when historical reads are available. Even then, an end-of-block balance can include other transactions from that block. Transaction logs establish the mint itself; balance reads establish holdings at the state being queried.

Rounding and limits behind an empty result

A positive EVK deposit that rounds down to zero shares fails with E_ZeroShares. This differs from passing a zero asset amount, for which the deposit implementation returns zero without creating a position.

EVK calculates deposit shares by rounding the asset-to-share conversion down. A small displayed amount can therefore be inadequate at the vault’s current exchange rate and token precision. This does not establish a universal minimum deposit. The actual amount and conversion determine whether a positive share output exists.

The functions previewDeposit and maxDeposit answer different questions. The preview estimates share output; the maximum reflects applicable deposit capacity. Neither replaces simulation of the intended call. Custom hooks can reject a transaction despite a positive maximum, and state changes before inclusion can invalidate an earlier result. Increasing an amount will not resolve a disabled operation or an authorization failure.

The record that closes the first-deposit check

A complete deposit record connects the network, vault, underlying asset, successful receipt, receiving account, and positive share output. Reconcile any later share movements before comparing balances. Missing or contradictory records justify stopping further submissions and retaining the transaction details for diagnosis; they do not justify another transfer. Completion establishes share issuance, while available liquidity and account constraints govern later withdrawals. The decisive record for this first action is the vault’s Deposit event.

Details worth knowing about Euler.finance vaults