Sandbox app is a transaction builder for SAND and LAND signatures

Sandbox app is the wallet-connected part of The Sandbox interface that prepares SAND and LAND actions for approval in a third-party wallet. It selects a network, contract, method, token amount or token ID, and proposed gas settings; MetaMask, Coinbase Wallet, Venly, or a WalletConnect-compatible wallet supplies the account and signature. A connection approval, a message signature, and an on-chain transaction are different requests with different consequences. This page focuses on reading those prompts, matching Polygon or Ethereum state to the intended asset, signing only the expected operation, and confirming the receipt afterward. It also covers allowances, gas, rejected prompts, and permission maintenance without repeating the broader platform overview.

Separate connection, signature, and settlement

A common Sandbox app mistake is treating every wallet prompt as if it completes the SAND or LAND action. Read the request type first, then match its consequence to the step you intended.

Connection permission

A connection request asks the wallet to expose a selected public account. An EVM address contains 20 bytes and appears as 40 hexadecimal characters after the 0x prefix, making the complete string 42 characters long. The app can then read balances and ownership. It does not transfer SAND, approve a spender, or move LAND.

Message signature

A message signature proves control of the selected account or records an off-chain instruction. It does not consume gas, increment the account nonce, or create a transaction receipt by itself. Plain-text signing should display readable text; EIP-712 typed data should expose a signing domain and structured fields. A signed message can later serve a contract or relayer, so its purpose and scope still matter even though no immediate state change appears.

On-chain transaction

An on-chain request contains the destination contract, chain ID, account nonce, gas parameters, native value, and encoded call data. The wallet signs this payload and broadcasts it through its provider. A successful receipt lets a marketplace contract spend an approved SAND amount, transfer a LAND token, or update another contract state. Only this stage changes the ledger; opening the app and connecting an address merely prepare access.

What exactly should the wallet confirmation show?

The wallet confirmation should describe the same network, account, contract, asset, permission, and cost the Sandbox app displayed before it opened the prompt.

Before approval, match these five fields:

• The selected sender is the account holding the required SAND or LAND.
• The network is Polygon PoS or Ethereum, as specified by the action.
• The destination is the expected SAND, LAND, marketplace, or bridge contract.
• The method and scope match a transfer, purchase, exact allowance, token approval, or collection approval.
• The SAND amount, LAND token ID, native value, and maximum network fee match the review screen.

Wallets decode contract calls with an Application Binary Interface, or ABI. MetaMask and Coinbase Wallet sometimes show a readable method; another wallet may expose only a four-byte function selector and hexadecimal data. The selector identifies a function signature, but it does not reveal every parameter without the ABI. A mismatch means close the prompt and rebuild the intended action from its starting screen. Rebuilding produces a fresh request from the selected account and network.

Approvals define what SAND or LAND may move

SAND and LAND approvals set different permissions because SAND follows ERC-20 while LAND follows ERC-721. The confirmation must reflect the standard and scope of the asset involved.

SAND uses 18 decimal places, so one displayed SAND equals 10 ¹⁸ base units. Its maximum supply is 3,000,000,000 SAND. An ERC-20 approval records a spender and a numeric allowance; the allowance remains available until spending reduces it or the owner changes it. The largest possible uint256 allowance is 2 ²⁵⁶ −1, a value wallets commonly describe as unlimited. An exact allowance limits the contract to the amount required for the intended settlement.

LAND approval uses token identity instead of a fungible amount. The ERC-721 approve method authorizes one token ID, whereas setApprovalForAll covers every token the owner holds under that LAND contract. The Sandbox map contains 166,464 LAND parcels, and a standard 1-by-1 parcel represents 96 by 96 metres in the virtual world; neither dimension identifies a transfer. The contract address and token ID do. Token-specific approval therefore leaves a narrower permission footprint than collection-wide authorization.

Which network should a SAND or LAND transaction use?

The Sandbox app should use Polygon PoS for Marketplace transactions and Polygon LAND sales, while Ethereum remains relevant for assets held on Ethereum and bridge operations.

Ethereum mainnet uses chain ID 1, while Polygon PoS mainnet uses chain ID 137. SAND and LAND have separate contract deployments on those networks, even when the wallet exposes the same 42-character account address on both. Polygon transactions pay unsponsored gas in POL; Ethereum transactions pay gas in ETH. The Sandbox Bridge moves supported SAND or LAND between network deployments through its own transaction sequence. Merely changing the network selector changes the ledger the wallet reads. It does not bridge a balance.

Gas, value, and SAND are separate fields

Gas, native value, and SAND describe three different parts of a Sandbox app transaction. Reading them separately prevents a zero native value from looking like a zero-token purchase, as set out in Sandbox explained.

SAND amount

A SAND payment is encoded as ERC-20 contract data, commonly through an allowance and a marketplace settlement call. The transaction therefore shows zero POL or zero ETH in its native-value field while still moving SAND. The wallet must decode the token amount with SAND's 18-decimal precision. Compare the displayed SAND amount with the order, not with the native-value line.

Network fee

The network charge equals gas used multiplied by the effective gas price. EIP-1559 wallets present a base-fee component and a priority component, then cap the total with the signed maximum fee. The required gas units come from the contract path, while block demand sets the price per unit. A reverted transaction still consumes the gas used before the EVM stopped execution. Polygon charges POL, and Ethereum charges ETH.

Wallet estimate

A wallet estimate reserves enough gas for the encoded call and presents a maximum, not the final charge. The receipt records the gas actually used and the effective price. The former Pay Gas Fees in SAND option ended on January 23, 2025, so SAND no longer replaces POL as the fee token. When the interface offers a gasless Polygon transaction, a relayer sponsors the network fee while the wallet still authorizes the requested state change.

How do you verify a transaction after signing?

Verify a signed transaction by matching its receipt, token state, and Sandbox inventory to the account, network, contract, and operation you approved.

Receipt status

A transaction hash contains 32 bytes, normally rendered as 64 hexadecimal characters after 0x. Use PolygonScan for chain ID 137 and Etherscan for chain ID 1. An EVM receipt status of 1 reports success, while 0 reports a reverted execution. Each included transaction consumes one externally owned account nonce, and the next sequential transaction uses the preceding value plus 1.

Token state

SAND verification reads ERC-20 methods such as balanceOf and allowance, plus Transfer or Approval events in the receipt. LAND verification reads the ERC-721 ownerOf result for the token ID and, where relevant, getApproved or isApprovedForAll. PolygonScan, Etherscan, and OpenSea may present these records differently, but they query the same network state selected for the transaction.

Application state

The Sandbox inventory can update after the chain receipt because the interface indexes confirmed events into its own view. If the receipt succeeded and the token state is correct, refresh the account view before signing anything again. Compare the connected address, network, and token ID with the successful receipt. The on-chain record establishes custody and allowance; the application inventory supplies a convenient presentation of that record.

Rejections and disconnects have precise meanings

Wallet provider errors identify whether the user declined, the account lacks permission, the method is unsupported, or the provider lost a chain connection.

EIP-1193 assigns code 4001 to a rejected request, 4100 to an unauthorized method or account, and 4200 to an unsupported method. Code 4900 means the provider is disconnected from every chain, while 4901 means it cannot reach the requested chain. A 4001 response creates no hash, spends no gas, and changes no nonce. For 4100, request account access again; for 4901, switch or add the required network. Rebuild the Sandbox action only after the wallet reports the intended account and chain.

Permission maintenance after the transaction

Permission maintenance reviews the allowances and operator rights left after a SAND purchase, LAND listing, transfer, claim, or bridge action.

An ERC-20 allowance can be reduced to the next required amount or set to 0 when no further settlement is planned. ERC-721 token approval clears when that token transfers, while a collection-wide operator remains active until the owner calls setApprovalForAll with false. Read allowance and isApprovedForAll on the same chain used for the original transaction. Ethereum permission state does not control the separate Polygon contracts.

Keep the transaction hash, chain ID, contract address, token ID or SAND amount, and receipt status with the related order record. Ledger and Trezor devices add a hardware confirmation when used through compatible wallet software, yet the prepared contract call still deserves the same field-by-field review. Changing the wallet connected to The Sandbox changes the address used for future actions and inventory views; it does not move existing balances. Periodic, transaction-specific permissions are easier to account for than perpetual broad approvals.

Updated: 2026-08-09