Spark fi is a Stablecoin Deposit Interface That Mints Vault Shares

Avoid the wrong-network deposit

The most common setup mistake is choosing a vault card before matching the wallet's network and stablecoin balance.

The Spark Savings selector documents eight networks, and every one has a distinct chain identity. Ethereum Mainnet uses chain ID 1; Base uses 8453; Arbitrum One uses 42161; Gnosis uses 100; OP Mainnet uses 10; Unichain uses 130; Avalanche C-Chain uses 43114; and Robinhood Chain uses 4663. These identifiers give the wallet an exact check beyond the network name. The fee asset also changes: ETH pays gas on the Ethereum-based selections, AVAX pays on Avalanche, and xDAI pays on Gnosis.

A stablecoin ticker must also match the selected chain. Ethereum USDT and Arbitrum USDT0 represent the supported inputs for their respective spUSDT deployments, while USDC held on Base cannot fund an Ethereum Mainnet deposit. Spark fi does not move a balance across chains during a vault deposit.

Use this decision checklist before opening the wallet prompt.

• Confirm the chain name and chain ID in both the app and wallet.
• Hold the accepted input token on that same chain.
• Reserve the network's native fee asset for every required transaction.
• Read the vault card's deposit cap and available liquidity.
• Match the expected output ticker to the selected vault.

This sequence keeps the choice concrete: one chain, one accepted input, one vault, one receiver, and enough native gas to settle the Actions panel.

Vault cards as a decision screen

The vault card is a decision screen for asset compatibility, capacity, liquidity, and share-token identity.

Spark Savings labels the underlying and the receipt token separately. USDC maps to spUSDC, USDT or USDT0 maps to spUSDT on its supported deployment, PYUSD maps to spPYUSD, and USDG maps to spUSDG on Robinhood Chain. USDS presents sUSDS and stUSDS as separate choices with different rate sources and risk profiles. Those labels matter because the wallet approves the input contract, while the vault mints a different ERC-20 token. Selecting by the displayed rate alone misses the asset and contract state that the transaction actually changes. The related mechanics are detailed in Spark fi walkthrough.

The card also exposes live APY, historical rates, collateral composition, risk assessment, total value locked, deposit capacity, and available liquidity. Treat the deposit cap as a hard execution constraint at confirmation time, not as an estimate of future access. The one-year projection is a display horizon based on the shown rate; it does not alter the share calculation. For mainnet spUSDC and spUSDT, both asset amounts and shares use 6 decimal places, so the interface handles base-unit conversion before the wallet receives transaction data.

What will the wallet ask you to approve?

The wallet asks for token spending permission before the vault pulls a stablecoin from the connected address.

Set against that, Spark fi represents a fresh allowance as an approval action followed by the deposit action. That is two onchain transactions when no sufficient allowance exists, and one deposit transaction when the existing allowance already covers the amount. Approval changes an ERC-20 allowance; it neither transfers the stablecoin nor mints vault shares. USDT adds a specific constraint: changing a non-zero allowance directly to another non-zero allowance can revert, so an integration resets the allowance to 0 before setting the replacement amount.

In a worked example, 25.50 USDC becomes 25,500,000 base units because USDC uses 6 decimals. The vault's previewDeposit function quotes the share amount for those asset units, and maxDeposit checks remaining capacity for the receiver. A quote is still read-only. The state change begins only after the wallet broadcasts the deposit call and the network includes it in a block.

Before signing, compare the transaction's destination with the vault selected in the interface. An EVM address is 20 bytes, displayed as 40 hexadecimal digits after the 0x prefix; one changed digit identifies another address. The amount, active chain ID, and connected account should also match the confirmation panel.

The final confirmation readout

The final confirmation readout should reconcile the selected vault, input amount, expected shares, action count, recipient, network, and gas quote. A native pair such as USDC into spUSDC has 0% swap slippage because the interface deposits the vault's accepted asset rather than routing a market trade. Network gas remains separate and market-set. If the panel introduces an unexpected asset conversion, chain ID, or receiver, return to the vault card and rebuild the action instead of signing stale transaction data.

State changes after settlement

A successful deposit replaces part of the wallet's underlying balance with ERC-4626 shares on the same chain.

The Spark vault's deposit call transfers the stated asset amount from the caller and mints the calculated shares to the receiver. ERC-4626 defines a four-field Deposit event containing sender, owner, assets, and shares. The ERC-20 share mint also produces a Transfer event from the zero address. A confirmed receipt therefore provides three useful checks: successful status, the vault as transaction destination, and logs showing the stablecoin movement plus the share mint. The transaction hash itself is 32 bytes, commonly rendered as 64 hexadecimal characters after 0x.

The share count is not the growing-balance display. balanceOf reads the ERC-20 share quantity, while assetsOf reports its current underlying value as the Vault Savings Rate accrues per second. The app presents the asset-denominated value for readability. If a wallet omits the new token, the confirmed share transfer still exists onchain; adding the canonical vault token address restores the display. For example, an spUSDC deposit should finish with spUSDC shares on the selected network.

Finish the action after a successful approval

The common "approved but no deposit" outcome means the first action settled and the second action never executed.

The Spark Actions panel separates allowance from execution when both are required. After the approval confirms, return to the same vault, stay on the same account and network, and continue the remaining deposit action. The stablecoin remains in the wallet until that second transaction succeeds, and no vault shares exist yet. Do not infer a deposit from an approval receipt: its logs record allowance state, while a completed vault transaction records asset transfer and share minting.

If the interface still shows approval, compare the approved amount with the newly entered deposit amount. A larger re-entered amount needs additional allowance; the original amount does not. Reconnect the same account, reopen the same vault card, and let the Actions panel refresh its allowance read. Then submit exactly one deposit transaction. If that transaction is pending, track its single 32-byte hash before creating another action with the same nonce.

Under the hood, previewDeposit reads the expected output before execution, maxDeposit reads the receiver's remaining capacity, and deposit commits the state change. The standard deposit function takes two arguments - assets and receiver - while Spark Vaults also expose a three-argument overload that adds a uint16 referral code. A uint16 value spans 0 through 65,535, but ordinary users do not choose that attribution field. The share receiver remains the connected account shown by the interface unless the transaction data states otherwise. Finishing the visible second action is what turns an approved USDC amount into minted spUSDC shares.