SwaggerEIP-7702, EIP-712, ERC-20, EIP-2612 and ERC-2771 — what each one does here.
UGTP combines account delegation, typed signatures and token standards. These mechanisms determine how an account signs, grants allowances and interacts with the execution contracts.
Lets an EOA delegate execution to contract code while keeping its address. 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.
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.
Defines token transfers, balances, allowances and decimals. Transfer amounts are integer strings in base units; low-level call and fee fields can use hexadecimal quantities. Display fee fields can contain decimal fractions. Follow each field's schema, and use the token catalog for decimals. Native-coin transfers use the network's native asset instead.
An extension some ERC-20s implement that lets an allowance be granted by signature instead of by transaction. UGTP can relay this signature so the account grants allowance without first paying native gas. A token without it needs an ordinary approve instead, which is the other half of the allowance flow.
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.
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 uses account-signed execution requests and verifies authorization itself. Integrate with its returned EIP-712 payload; it is not a general-purpose ERC-2771 forwarder.