One Identity, One Address —
on Every Network

Abstract

1. The Fragmented Identity Problem

Today's multi-chain landscape forces users into one of two compromises. Traditional EOAs provide a single address across networks but lack smart account features: no batch execution, no gas sponsorship, no session keys. Smart account solutions (ERC-4337, counterfactual wallets) provide those features but introduce a second address — a CREATE2-deployed contract that differs from the user's signing key address.

This bifurcation creates practical problems: assets sent to the EOA address don't appear in the smart wallet; users must track two addresses per network; dApp integrations must decide which address represents the user. Cross-chain interactions compound this: the smart account address may differ across networks depending on factory contracts, salt values, and deployment timing.

UGTP eliminates this compromise by using EIP-7702 to bring smart account capabilities directly to the EOA address.

2. EIP-7702 Set-Code Delegation

EIP-7702 (introduced in Ethereum's Pectra upgrade, May 2025) allows an EOA to set a delegation designator in its code field, pointing to a smart contract implementation. When a transaction targets the EOA, the EVM executes the designated contract's code in the context of the EOA — using the EOA's storage, balance, and address.

UGTP deploys a single UGTPAccount implementation contract at a deterministic CREATE2 address across all supported networks. Users sign a type 0x04 authorization to delegate their EOA to this contract. The delegation is:

• Non-destructive — the EOA retains its private key and can still sign regular transactions
• Revocable — the user can clear the delegation at any time
• Re-delegatable — upgrading to a new implementation version requires only a new authorization signature
• Address-preserving — the EOA address never changes; it gains code, not a new identity

The UGTPAccount contract uses ERC-7201 namespaced storage to isolate its state from any other delegation target the EOA might adopt in the future. This ensures safe re-delegation without storage slot collisions.

Auto-Delegation

The wallet activates delegation transparently on the user's first outbound transaction. No separate “activate” step is required — the authorizationList is included in the first send transaction. After delegation, the EOA's on-chain code prefix is 0xef0100<UGTP_ACCOUNT_ADDRESS>, which can be checked by any app to verify delegation status.

Graceful Degradation

On Avalanche C-Chain (which does not yet support EIP-7702 — ACP-209 is still Proposed), the same address works as a plain EOA. Public tokens are held and transferred directly, while private (encrypted) tokens use the privacy module keyed to the same address. When ACP-209 activates, the address will auto-upgrade to full 7702 delegation.

3. Universal Crypto Account

A Universal Crypto Account (UCA) is the protocol's identity primitive. It represents a single user across all networks with one address. The UCA is not a new account type — it is the user's EOA, enhanced by delegation on networks that support EIP-7702.

Each UCA is identified by a Universal Crypto Identifier (UCI), formatted as uci{hex-address}. The UCI provides a human-readable, chain-agnostic reference to the user's identity.

The UCA encompasses three execution surfaces from a single key pair:

• Public execution — standard token transfers and contract interactions on all networks
• Smart execution — batch calls, session keys, and sponsored transactions via delegation
• Private execution — encrypted asset operations on the Avalanche coordination chain

4. Execution Model

UGTP implements an Execution Optimizer that selects the best execution path for each transaction based on the target chain's capabilities:

The optimizer is transparent to the user. Regardless of which execution mode is selected, the transaction originates from and is attributed to the same UCA address.

5. Transaction Flows

Send Transaction

When sending a transaction, the wallet checks the delegation status on the target chain. If the account is not yet delegated, the authorization is included automatically (auto-activate). Native token transfers send directly to the recipient. ERC-20 transfers call the token contract's transfer function.

Swap & Send (Batch Transaction)

When the user wants to send a token they don't hold but has sufficient value in another asset, the wallet detects the insufficient balance, finds swap sources, and obtains a quote from the Li.Fi DEX aggregator. The resulting batch call is executed atomically via executeBatch:

1. Approve the swap router for the source token amount
2. Execute the swap (source token to target token) via Li.Fi
3. Transfer the target amount to the recipient

All three operations are encoded as a single self-call to executeBatch(calls), ensuring atomicity.

Gas Sponsorship

The API provides endpoints for sponsored execution. The /api/delegate endpoint accepts a signed EIP-7702 authorization and submits the delegation transaction using a system relayer. The /api/sponsor endpoint accepts batch calls and executes them using a system sponsor, paying gas on behalf of the user. Both endpoints validate inputs, enforce rate limits, and verify active delegation before execution.

6. Privacy Module

UGTP derives a private-account key pair from the user's mnemonic using EIP-712 structured signing. The derivation uses a fixed, immutable purpose string to ensure deterministic key generation. The private account operates on the Avalanche coordination chain (chain 43114), where encrypted token contracts hold shielded balances.

Privacy key derivation uses EIP-712 signing with domain { name: "UGTP External Gateway", version: "1", chainId: 43114 } to produce deterministic view/spend keys from the EOA signature.

Wallet encryption uses PBKDF2 with 600,000 iterations and AES-256-GCM, with random salt and IV per encryption operation. The encrypted vault is stored locally in IndexedDB; no private key material is ever transmitted to servers.

7. Fee Structure

Sponsored transactions incur a system fee deducted from the transfer amount (fee-from-amount model), ensuring users never need to hold gas tokens separately:

• Proportional fee: 25 basis points (0.25%) of the transfer amount
• Flat fee: 0.001 ETH equivalent per transaction
• Total: proportional fee + flat fee combined

Direct EOA transactions (where the user pays gas themselves) incur no system fee.

8. Smart Contracts

UGTPAccount (EIP-7702 Delegate)

The core smart contract deployed at a deterministic CREATE2 address on all supported chains. Design principles: no initializer or stored owner (address(this) IS the EOA after delegation), ERC-7201 namespaced storage, reentrancy guards on all execute paths, and ERC-4337 v0.8 compatibility.

Coordination Contracts (Avalanche C-Chain)

Protocol coordination is anchored on Avalanche with dedicated registry contracts for UCI resolution, UCA management, linked accounts, intents, and adapter routing.

Privacy Token Contracts (Avalanche C-Chain)

Four encrypted ERC-20 tokens (esAVAX, esETH, esUSDT, esUSDC) are deployed on Avalanche C-Chain, each backed 1:1 by the underlying asset. A Privacy Registry contract manages the mapping between public and private token addresses.

9. Architecture

The protocol is implemented as a modular monorepo:

10. API

The HTTP API provides read endpoints for account resolution and asset aggregation, and write endpoints for delegation relay and sponsored execution:

11. Supported Networks

UGTP operates across six networks at launch:

All five EIP-7702 chains share the same UGTPAccount contract at a deterministic CREATE2 address. Avalanche serves as the coordination chain for privacy operations and will gain delegation support when ACP-209 is adopted.

12. Security

• EIP-7702 authorization is chain-specific (chainId-bound) to prevent replay attacks
• UGTPAccount uses ERC-7201 namespaced storage to avoid slot collisions
• Session keys have per-transaction value limits, daily caps, expiry timestamps, and target whitelists
• Policy hooks provide extensible transaction validation
• All execute paths are reentrancy-guarded
• The onlyAuthorized modifier restricts execution to address(this) (the EOA) or the ERC-4337 EntryPoint

13. Legacy Compatibility

UGTP3's CREATE2 Advanced Wallets and imported EOAs receive a guided migration flow. The explorer detects legacy AW deployments and displays a migration banner. The wallet provides a “migrate funds” flow to transfer assets from the old AW to the EOA. Legacy AW addresses remain resolvable via the API.

14. Future Work

• Additional network support (BNB Chain planned)
• Avalanche ACP-209 integration for 7702 delegation on the coordination chain
• Cross-chain intent coordination via the Avalanche coordination layer
• Enhanced privacy features with zero-knowledge proofs
• DAO governance for protocol parameter updates