Depositing

Testnet. Signing works against a local chain and the testnet. Nothing has been deployed to mainnet.

#What a deposit does

You transfer WETH to the vault and receive vault shares. Shares are an ERC-20 representing a pro-rata claim on everything the vault holds.

The share count is computed by the contract from its own NAV. The interface never recomputes it: previews are simulateContract calls against the deployed bytecode, so a preview is the contract's own answer and cannot disagree with the chain after you sign.

#Virtual shares

The vault mints against a virtual share and asset offset of 10^6.

This is the standard defence against the donation-inflation attack, where a first depositor mints one wei of shares and then donates a large balance directly to the vault, so that the next depositor's deposit rounds to zero shares. The offset makes that attack cost more than it can extract.

#When a deposit is refused

Refusals are explicit and carry their reason:

Security. Failing closed here is a deliberate trade. Refusing a deposit costs someone an afternoon. Minting shares at a wrong price is not reversible.

#Fees

There is no deposit fee. See Fees for what is charged and when.

#Connecting a wallet

Wallets are discovered through EIP-6963, so every installed wallet announces itself and you choose. There is no WalletConnect project id and no third-party service in the path — connecting to an extension that is already in your browser should not require someone else's server.

Your wallet's chain is read, never assumed. If it is on a different chain the interface says so and offers to switch; nothing can be signed until it matches, because a transaction built for one chain and sent on another either fails or succeeds against contracts nobody reviewed.

Disconnecting clears this site's state. It cannot make your wallet forget the site — only your wallet can do that, in its own permissions — and the interface says so rather than implying a stronger guarantee.

#What happens when you deposit

flowchart TB
  A["Read your allowance"] --> B{"Already enough?"}
  B -- yes --> D
  B -- no --> C["Approve exactly this amount<br/>never unlimited"]
  C --> D["Simulate deposit against<br/>the deployed contract"]
  D --> E{"Would it succeed?"}
  E -- no --> F["Stop. Show the contract's reason.<br/>No signature requested."]
  E -- yes --> G["You sign"]
  G --> H["Wait for the receipt"]
  H --> I["Shares minted"]

Two details worth stating plainly.

The approval is for exactly the deposit. Never unlimited. An unlimited approval is a standing permission to move that token which outlives the deposit that motivated it. If your allowance already covers the amount, no approval is requested at all.

The simulation runs before the signature, and can stop it. If the contract says the deposit would revert, you are told why and never asked to sign — paying gas to discover something the contract already told us is not a reasonable thing to ask of someone.

Note. Before an allowance exists, simulating the deposit reverts on the transfer, so there is no simulated answer to show. In that window the share count comes from the vault's own convertToShares view and is labelled estimate. It is still the contract's arithmetic, but it is a different call, so it is marked as one. The authoritative simulation always runs before anything is signed.

#Browsing does not require a wallet

NAV, remaining capacity, cash held, position count and every constraint are shown before any connection is requested. A wallet is asked for at the moment of the transaction and not before.

The percentage buttons (25% / 50% / 75% / MAX) stay disabled while there is no connected balance to take a percentage of, rather than silently computing them from zero.

#After depositing

Your shares appear in Portfolio and shares. Your exit options are described in Withdrawals and in-kind exits — worth reading before you deposit, not after.