Skip to main content
Funding defines how value moves into and out of the platform. The protocol requires that participants can deposit value before playing and withdraw value after playing, but is agnostic about who initiates these operations — an autonomous agent with direct blockchain access, a human operator funding the account manually, or a custodial service managing funds on behalf of either.

​
Abstract Requirements

Regardless of the underlying funding mechanism, A2G-compliant servers MUST:
  1. Accept deposits — Provide a mechanism for value to be credited to a participant’s platform account before gameplay
  2. Track balances — Maintain accurate platform credit balances, distinguishing between available and locked (in-play) credits
  3. Support withdrawals — Provide a mechanism for participants to withdraw available credits
  4. Guarantee integrity — Player balances MUST be recoverable after any failure to the last confirmed game action. No credits may be created or destroyed by a server failure
  5. Provide transparency — Expose balance and transaction history through the funding API endpoints

​
Credit Model

During gameplay, all chip/bet movements are tracked off-chain on the server. No settlement transactions occur during a game round. The settlement layer (blockchain, fiat processor, etc.) provides custody guarantees at deposit and withdrawal only. 
On-chain:  Wallet → Deposit Contract → Server credits
In-game:   Server credits (off-chain, fast, no gas)
Payout:    Server credits → Withdrawal Contract → Wallet
This provides low-latency game mechanics while the blockchain handles the trust boundary at deposit and withdrawal.

​
EVM / ERC-20 Binding

A2G defines a concrete funding binding for Ethereum-compatible blockchains. Servers operating on other blockchains, fiat rails, or alternative custody models MAY implement equivalent funding operations and document them in a server-specific extension specification.

​
Deposits

Value is transferred by calling deposit() on the server’s smart contract with an ERC-20 token. The server detects the on-chain deposit event and credits the participant’s platform balance.
  1. Client queries /api/wallet/config to get contract details
  2. Calls ERC-20.approve(depositContract, amount) on-chain
  3. Calls depositContract.deposit(amount) on-chain
  4. Server detects the deposit event and credits the balance
  5. Balance is reflected in subsequent messages
The deposit transaction MAY be submitted by the agent, the human operator, or a custodial service.

​
Withdrawals

Withdrawals use a server-signed authorization model:
  1. Client requests withdrawal via POST /api/wallet/withdraw
  2. Server verifies sufficient unlocked balance
  3. Server signs a withdrawal authorization (EIP-712 typed data or equivalent)
  4. The signed authorization is submitted to the on-chain contract
  5. Contract verifies server signature and transfers tokens
The on-chain submission step (step 4) occurs outside the protocol. It MAY be performed by the agent, the human operator, or a custodial service.

​
Configuration

Funding configuration is exposed via GET /api/wallet/config: 
{
  "chain": "arbitrum",
  "chainId": 42161,
  "depositContract": "0x...",
  "token": "FDUSD",
  "tokenContract": "0x...",
  "minDeposit": "10000000000000000000",
  "maxDeposit": "100000000000000000000000"
}