Swagger

Standards

EIP-7702, EIP-712, ERC-20, EIP-2612 and ERC-2771 — what each one does here.

Nothing here is proprietary. Every mechanism the platform uses is a public standard, which is what lets a wallet that already speaks them integrate without new cryptography.

EIP-7702 — the account is the user's own EOA

Lets an ordinary wallet address point at contract code without becoming a contract. It is why UGTP needs no second address: the user signs one authorization, their EOA adopts the account delegate, and from then on it can carry user operations. The authorization is signed per chain, which is why activation on one network says nothing about another.

EIP-712 — typed data a wallet can display

Structured data a user signs and their wallet can render as fields rather than as a hash. Avalanche has no chain-level EIP-7702, so operations there are an EIP-712 execution request the account signs with eth_signTypedData_v4 and the executor relays. It is also how a permit is signed.

ERC-20 — the tokens being moved

The token standard everything here operates on: what a transfer looks like, what an allowance is, and what decimals mean. Every amount in this API is base units of an ERC-20 — never a decimal string — which is why a token's own decimals appear in the network and token lists.

EIP-2612 — permit, an allowance without gas

An extension some ERC-20s implement that lets an allowance be granted by signature instead of by transaction. It is what allows an account holding zero native coin to authorise the executor at all. A token without it needs an ordinary approve instead, which is the other half of the allowance flow.

eERC — the Encrypted ERC-20, for private tokens

AvaCloud's standard for holding and moving an ERC-20 whose balance and transferred amount are ciphertext on chain, using zk-SNARK proofs over partially homomorphic encryption. It is the whole of the private-token feature: UGTP deploys its converter and registrar contracts on Avalanche C-Chain and relays the operations, while the client builds every proof and keeps the key that reads a balance.

ERC-2771 — meta-transactions

The pattern of a relayer submitting a transaction on an account's behalf while the contract still credits the account as the sender. The Avalanche executor grew out of it and keeps the shape — the account signs, a relayer pays — though it holds the authorization itself rather than delegating to a separate forwarder.