Kaito is the Base wallet gate for KAITO-to-sKAITO staking

From wallet link to a submitted stake

The Kaito staking panel is a transaction builder that converts the selected account, token amount and wallet confirmation into a Base vault deposit. Its three visible stages map to distinct checks.

Link the spending account

Linking the wallet exposes the active EVM address and network to the panel. MetaMask, Coinbase Wallet, Rabby and WalletConnect separate account selection from chain selection, so read both fields. The connected address must own the Base KAITO that will move and the ETH that will fund the call. A balance on Ethereum or another Base address is outside this transaction.

Enter the KAITO amount

The amount field defines the exact KAITO asset input. The receive field then previews the sKAITO shares produced by the vault's exchange ratio, not a spot-market trade. Leave enough KAITO for any later action that matters to your own plan; the contract only receives the amount that the deposit call specifies. Recheck the preview after changing the input because rewards held by the vault alter KAITO-per-share accounting. Decimal precision extends to 18 places, although most wallet interfaces display fewer digits for readability. The hidden base units still determine the final minted balance.

Review and sign

Selecting Stake prepares either an allowance request or the deposit itself. The wallet confirmation identifies the network, destination contract, asset amount and ETH fee estimate. Sign only after those fields match the form. A signature authorizes that one message; the transaction becomes verifiable after the wallet broadcasts it and returns a hash.

The Base network gate and its failure mode

The Base network gate is a chain-ID check that keeps the staking call on the mainnet where the KAITO and sKAITO contracts reside.

Base mainnet uses chain ID 8453, while Base Sepolia uses 84532 and Ethereum mainnet uses chain ID 1. Those identifiers matter because an EVM account may display the same 20-byte address on every network while holding different balances on each one. Written with the 0x prefix, that address contains 40 hexadecimal digits and occupies 42 characters. The familiar address therefore proves the account, not the chain. ETH and token balances remain isolated by network state. Switching networks does not transfer either asset. The wallet must report 8453 before Kaito constructs the intended deposit.

A mismatch stops the intended stake before confirmation and points directly to the wallet network setting.

The permission step before the vault deposit

The KAITO permission is an ERC-20 allowance that authorizes the sKAITO vault to transfer the amount selected for staking.

A new wallet or an account with too little allowance completes two onchain transactions: one approval and one deposit. An account with sufficient allowance submits only the deposit transaction. The approval updates a number stored by the KAITO contract; it neither moves KAITO nor mints sKAITO. An exact allowance falls as transferFrom spends it, while a larger allowance leaves a remainder. Read the wallet action label because confirmation of approval means the stake still requires its second signature.

KAITO also exposes EIP-2612 permit data, but that standard does not make the ERC-4626 deposit automatic. The connected interface must build a permit-aware route. When the wallet presents an ordinary onchain approval, expect its Base receipt and ETH charge before returning to the deposit button.

What does the confirmation actually change?

The confirmed stake is an atomic ERC-4626 deposit that moves KAITO into the vault and mints sKAITO shares to the connected account.

Atomic execution joins the token transfer and share mint inside one transaction. Both contract writes succeed or both revert. The wallet's KAITO balance falls by the deposited assets, its sKAITO balance rises by the returned shares and its ETH balance falls by actual gas. That deposit advances the sender's nonce by one. If approval occurred first, that earlier transaction consumed a separate nonce.

An exact allowance also declines by the amount consumed through transferFrom. A maximum allowance may stay unchanged under the ERC-20 implementation, while any unused finite remainder stays recorded. These permission effects sit beside the share mint, so the receipt and post-transaction balances should agree.

Reading the receive amount as vault shares

Share accounting is the ERC-4626 mechanism that separates the number of sKAITO units from the KAITO assets those units represent.

Both KAITO and sKAITO use 18 decimal places, so one displayed token unit equals 10^18 base units. The vault preview converts deposited assets into shares at the onchain ratio. It is not a fixed one-for-one promise. Rewards enter vault accounting and increase the KAITO represented by each sKAITO share, so the share count does not need to rebase inside the wallet. Kaito accrues that value automatically without a separate reward-claim transaction, which is examined in Kaito working with withdrawals essentials.

The functions previewDeposit and convertToAssets express opposite views of the same position: shares received now and KAITO represented later. ERC-4626 conversion functions round down to whole base units. A one-unit difference at 18-decimal precision reflects integer arithmetic, not a second fee.

Gas budgeting on Base

Base gas is an ETH-denominated network charge with two economic parts: L2 execution and L1 data publication. One ETH contains 10^18 wei, and one gwei equals 10^9 wei. The wallet combines gas limits and fee parameters into an estimated total before signing. KAITO and sKAITO do not pay that charge. Reserve ETH for two calls when approval is needed, then compare the wallet estimate again before the deposit because network demand and transaction data change the payable amount.

A pre-signing decision checklist

The pre-signing checklist is a five-condition gate that aligns the Kaito form, wallet state and Base transaction before approval.

• Confirm that the wallet reports Base mainnet and chain ID 8453.
• Match the connected address with the account holding KAITO and ETH.
• Leave enough ETH for approval and deposit when both calls are required.
• Compare the KAITO input with the sKAITO share preview after every edit.
• Identify whether the wallet is requesting approval or the final vault deposit.

Receipt checks that prove completion

The Base transaction receipt is the canonical completion record that connects the signed stake to the resulting token balances.

Status and identity

Every Base transaction hash is 32 bytes, shown as 64 hexadecimal digits or 66 characters with the 0x prefix. Open it in BaseScan or Blockscout and confirm the sender, destination, block number and receipt status. Status 1 records successful execution; status 0 records a revert. The deposit destination is the sKAITO vault at 0x548d3b444DA39686D1a6F1544781d154e7cd1EF7.

Balance deltas

Compare three deltas after success: KAITO decreases, sKAITO increases and ETH pays gas. The KAITO token address is 0x98d0baa52b2D063E780DE12F615f963Fe8537553. A wallet that has not indexed sKAITO may hide the credit, yet its token contract balance still supplies the decisive figure.

Vault events

An ERC-4626 Deposit event records four semantic values: sender, owner, assets and shares. Related ERC-20 Transfer logs show KAITO entering the vault and sKAITO minting from the zero address to the receiver. One deposit may emit additional implementation logs, so match the four vault values to the form rather than counting every line. Together, status, addresses, balances and events form the completed record.

Recovering from a wrong-network wallet

The wrong-network state is a wallet configuration mismatch that prevents Kaito from building the intended Base mainnet transaction.

Ethereum mainnet is selected

Switch the wallet from Ethereum chain ID 1 to Base chain ID 8453. The same EVM address remains visible, but its network-specific KAITO and ETH balances change. Recheck both balances after the switch before reconnecting the staking panel.

Base Sepolia is selected

Base Sepolia is the test network identified by 84532, not the staking network identified by 8453. Testnet ETH and test tokens have separate state. Select Base mainnet and wait for the wallet label to update.

The stake button stays disabled

When the form stays disabled after a switch, reconnect the same account and let the wallet approve Kaito's Base request. MetaMask and Rabby expose chain ID in their network panels, while Coinbase Wallet identifies Base by name. A WalletConnect session may retain its earlier chain context until the session reconnects. Reload the staking panel only after the wallet itself shows 8453, then compare the connected address with the account that holds both KAITO and ETH. That sequence repairs the configuration without submitting a transaction. The switch and reconnection are offchain settings, so they cost zero ETH.

Pending, replaced and reverted stake attempts

Transaction state is the Base mempool and receipt lifecycle that explains why a submitted Kaito stake has not yet changed balances.

A pending stake is only broadcast, so sKAITO remains unchanged until Base includes the transaction. Track its hash before taking another action. A wallet speed-up replaces the pending transaction with another transaction that uses the same nonce and a higher fee setting. Only one version settles.

A replaced label points to nonce history rather than token accounting. Confirm which hash reached a block. If an approval has nonce n and the deposit has nonce n+1, the second waits behind the first. Transactions sharing one sender and nonce compete for the same position.

A reverted deposit produces status 0, consumes gas and rolls back the KAITO transfer and sKAITO mint. A separate approval with status 1 remains recorded. Recheck the available KAITO, allowance, ETH and previewed share amount before sending a fresh deposit. The receipt and ordered nonces identify the exact step that needs repetition.

Maintaining an auditable stake position

The related figures are collected in Kaito comparison. Stake maintenance is a lightweight recordkeeping routine that tracks sKAITO shares, their KAITO value and the transactions that created them.

Store the wallet address, deposit hash, block number, KAITO asset amount, sKAITO share amount and gas paid as one record. Later, read convertToAssets against the wallet's share balance to express the position in KAITO terms. Automatic reward accrual changes that asset-per-share relationship rather than adding a scheduled token transfer. A portfolio display that shows only the sKAITO unit count therefore omits part of the position's state.

Any later unstake and withdrawal produce their own Base records. Treat the original deposit receipt as the opening record and every later action as a separate transaction.