Renzo is an Interface for ezETH Minting, Receipt Checks, and Network Recovery

Renzo is a network-aware ezETH minting interface: choose a supported EVM network and deposit asset, submit the wallet transaction, then confirm the receipt and resulting token balance on the same chain. If ezETH seems absent, switch the wallet back to the transaction’s chain before adding the token entry.

It is a restaking interface where users choose a network and asset, confirm a deposit, receive ezETH, check the receipt, and fix network mismatches.

The Mint Path From Network Selection to ezETH

One successful deposit moves Renzo’s interface from three inputs - network, asset, and amount - to a wallet confirmation and an ezETH balance update.

The flow begins with an EVM wallet connection, then moves to the asset selector, where chain and deposit token belong to the same choice. Ethereum exposes its supported collateral, while Base and Arbitrum One expose their own local balances and routes. Entering an amount or selecting MAX prepares the request; it doesn’t broadcast anything. The wallet prompt marks the boundary between a reversible interface choice and a state-changing call.

After broadcast, the wallet produces a transaction hash before the interface can show a mined result. On Ethereum mainnet, the RestakeManager accepts the collateral and calculates ezETH against protocol value and supply; on supported Layer 2 routes, xRenzoDeposit handles the local deposit and mints the corresponding token representation. The user-visible finish is concrete: the submitted asset balance decreases, gas is paid in the chain’s native currency, and ezETH rises at the same connected address. Chainlink feeds support pricing on Renzo’s Layer 2 deployments, while bridging and batching continue behind the immediate minting flow.

What Do I Need Before Connecting to Renzo?

Three prerequisites make a Renzo deposit possible: an EVM wallet, a supported asset on the selected network, and that network’s native gas token.

MetaMask, Rabby, and Coinbase Wallet all present EVM account and network state, while WalletConnect links compatible mobile wallets. The connected address needs the collateral balance on the chosen chain, plus ETH for gas on Ethereum, Base, or Arbitrum One. BNB Smart Chain uses BNB for gas.

Asset eligibility remains chain-specific. Renzo’s Ethereum ezETH route names native ETH and stETH; its Layer 2 native-restaking material names ETH, WETH, and wstETH on Base and Arbitrum One. The live selector narrows those combinations before amount entry. A token held on Ethereum won’t satisfy a Base balance check, even though the wallet shows the same account address. The next useful decision is where the asset and gas already coexist.

Native ETH and ERC-20 Deposits Take Different Signing Paths

One native-ETH signature contrasts with the two-step ERC-20 path a first token deposit uses when its existing allowance is still zero.

For native ETH, the deposit call carries value and pays gas from the same ETH balance. A supported ERC-20 such as stETH, WETH, or wstETH follows allowance semantics. The first signature authorizes a Renzo spender for a stated token amount; the second executes the deposit through that spender. If the existing allowance already covers the amount, the approval step disappears and only the deposit transaction remains. ERC-20 defines both Approval and Transfer events, so the two receipts reveal whether permission changed and whether collateral moved. The path therefore differs by asset type, not by the wallet brand signing it.

An approval receipt alone doesn’t mint ezETH. When the first transaction succeeds and the ezETH balance stays unchanged, return to the interface on the same network and submit the deposit call. Native ETH skips the allowance state entirely. Separating these two state changes prevents an approval hash from being mistaken for the deposit receipt.

The Review Screen Defines the Transaction You’ll Sign

Four review fields deserve a direct match before signing: chain, asset, amount, and the contract request the wallet presents onscreen.

Renzo supplies the selected network and asset context, while the wallet independently renders the chain, destination contract, transferred value, and fee estimate it will authorize. The network name must correspond to the chain chosen in the interface. The asset amount should match the entered quantity, and the connected account should be the intended ezETH recipient. A mismatch here belongs to the unsigned stage, where changing the selector remains free.

Native ETH and token deposits look different in wallet details. An ETH deposit carries the entered native value plus a separately calculated network fee. An ERC-20 deposit call may carry zero native value while its calldata instructs the contract to transfer tokens under an allowance; ETH or BNB still pays gas. MAX is an amount shortcut, not an on-chain promise about gas headroom.

Chain IDs Anchor the Selected Network

Four durable mainnet identifiers separate Renzo’s EVM contexts: Ethereum 1, Base 8453, Arbitrum One 42161, and BNB Smart Chain 56.

An EVM address occupies 20 bytes and appears as 40 hexadecimal characters after the 0x prefix. EIP-55 checksum casing helps detect mistyped characters, yet the address itself doesn’t encode a chain. Matching the connected address therefore proves the account, not the network. On Ethereum, the ezETH contract is 0xbf5495Efe5DB9ce00f80364C8B423567e58d2110, a 42-character string including its prefix; another chain maintains separate token state.

A wallet network switch changes its RPC context and costs no gas. If the selected chain isn’t configured, add it using the correct chain ID, switch to it, reconnect the same account, and reopen Renzo’s asset selector. The balance query then runs against the chain the deposit will actually use, which is the decisive recovery step after a network mismatch.

Gas, Allowance, and Output Checks Before Approval

Three quantities control Renzo’s final wallet decision: the deposit amount, any ERC-20 allowance, and the network fee quoted in native gas.

Once mined, an EVM transaction’s paid fee equals gas used multiplied by its effective gas price. A type 2 EIP-1559 transaction records 0x2 in the receipt, with base fee and priority fee contributing to the effective price. The wallet’s maximum fee is a cap, while the receipt records what execution consumed. An exact token approval limits the spender to the entered amount; a larger allowance leaves a remainder after the deposit.

Unit precision and exchange value answer different questions. ezETH uses 18 decimals, so one displayed token equals 10 ¹⁸ base units; likewise, 1 ETH equals 10 ¹⁸ wei. Those fixed conversions don’t mean 1 ETH always mints 1 ezETH. Renzo’s mint rate reflects protocol value relative to ezETH supply, and the interface translates the selected collateral into an expected token amount. Read that output beside the input amount before opening the wallet, then reserve enough native currency for every required transaction.

The Receipt Proves the State Change

One unique 32-byte transaction hash retrieves the receipt Renzo users need to distinguish submission, execution, and the resulting ezETH token mint.

A standard EVM receipt uses status 1 for success and status 0 for failure, while a pending transaction has no receipt yet. The receipt also records the block number, sender, destination, gas used, effective gas price, and emitted logs. Its transaction hash is 32 bytes, while the sender and destination addresses are 20 bytes each. A block explorer decodes these fields, but the receipt itself is the chain-native proof. On Ethereum, slots last 12 seconds and 32 slots form a 6.4-minute epoch; stronger finality arrives after further consensus, rather than at the first visible block.

Use the explorer matching the receipt’s chain: Etherscan for Ethereum, BaseScan for Base, Arbiscan for Arbitrum One, or BscScan for BNB Smart Chain. A successful deposit pairs status 1 with token logs and a higher ezETH balance for the connected address. The mint’s ERC-20 Transfer event records the zero address as sender and the wallet as recipient, making the exact balance change independently readable.

Why Isn’t ezETH Showing in My Wallet?

Two mismatches explain most invisible ezETH balances after a successful Renzo deposit: the wallet shows another network, or it lacks the token entry.

Start with the chain attached to the transaction hash, not the network currently visible in the wallet. Open the matching explorer, confirm status 1 and the recipient address, then switch MetaMask, Rabby, or the connected mobile wallet to that chain. Reconnecting Renzo refreshes its balance query in the proper RPC context. The address stays identical across these EVM networks, which makes chain selection easy to overlook.

A successful Base receipt doesn’t move a Base balance into Ethereum.

If the chain is correct but the asset remains hidden, add ezETH using the token contract deployed on that network. The token display uses 18 decimals. Importing a token changes the wallet’s local presentation; it doesn’t mint, bridge, or transfer anything. Refreshing the account or calling the token’s balanceOf view then reads the existing on-chain balance for the connected 20-byte address.

Recovery After a Rejected, Pending, or Failed Transaction

Three transaction states require different Renzo recovery steps: rejected before broadcast, pending without a receipt, and included onscreen with status 0.

Rejecting the wallet prompt before broadcast creates no transaction hash, changes no balance, and costs no gas. A pending transaction has a hash but no receipt, so the network hasn’t included it yet. Keep that hash and inspect its nonce before sending another deposit. If the wallet offers speed-up or cancellation, its replacement uses the same nonce with a revised fee; only the transaction accepted for that nonce reaches execution.

An included transaction with status 0 consumed gas but reverted its state changes, so no ezETH mint occurred. Reopen the current Renzo selector and recheck the asset route, available balance, allowance, and gas before creating a new transaction. Token deposits also fail when the approved amount no longer covers the requested transfer. A fresh submission belongs after the failed condition has changed, and it receives a new 32-byte hash.

The Pre-Sign Decision Checklist

Five checks fit into Renzo’s final review and catch the network mismatch this workflow is built to prevent before any signature.

• Match the Renzo selector to the wallet’s chain ID.
• Confirm the chosen asset balance exists on that same chain.
• Leave native ETH or BNB available for every gas charge.
• Separate an ERC-20 approval from the later deposit call.
• Save the 32-byte deposit hash with its network name.

The checklist ends at broadcast; receipt status and token logs take over afterward. Keeping chain ID, account, asset, amount, and hash together creates a compact transaction record. It also makes recovery deterministic: identify the last completed state, then continue from the next unsigned step.

The Workflow Fits Direct Minting and On-Chain Verification

Two user conditions make Renzo’s minting workflow a strong fit: the goal is direct ezETH issuance, and the wallet supports the chosen EVM network.

This path suits someone who already holds an eligible asset and its matching gas currency on Ethereum, Base, Arbitrum One, or another route displayed by the interface. It rewards precise transaction handling: select the chain, distinguish approval from deposit, store the hash, read status, and display ezETH on that same network. Moving existing ezETH between networks belongs to a bridge flow, while redeeming it starts a withdrawal flow. For a new mint, the clean next step is choosing the network where collateral and gas already sit together.