1Do Protocol Whitepaper

1Do is a next-generation onchain account and application runtime platform. Its goal is not to create another custodial application surface, but to converge account authority, asset authorization, signature validation, and app execution boundaries back to the user's own address.

In 1Do, users can activate an ERC-7702 runtime on an EOA or use an existing smart contract account. The same address is the user's wallet, app runtime, and settlement boundary for DeFi, payments, NFTs, wills, and future applications. Apps can innovate independently, but they cannot move users out of their own account boundary.

• The account follows the user, not one app.
• Asset authority converges in the wallet runtime, not across tokens, routers, markets, and payment contracts.
• Apps execute inside the user's account runtime and settle through wallet-native authorization.
• The user experience shifts from understanding low-level contract calls to understanding the action being completed.

Early Ethereum apps assumed EOAs. An EOA has no code, no local state, and no way to express fine-grained execution policy, so DeFi pushed permission logic down into tokens, routers, markets, vaults, and app contracts.

ERC-20 approve(spender, amount) plus allowance(owner, spender) is the common DeFi interaction model. The user approves a router or app first, then the app later pulls assets with transferFrom. NFTs have the same pattern: approve, setApprovalForAll, and operator approval place user-level authority in asset or marketplace contracts.

Uniswap

Uniswap uses AMMs, liquidity pools, and routers to swap ERC-20 assets. The model is open, composable, and does not require a platform-custodied balance. In a typical first-use path that needs new authorization, however, the user sends approve and then swap; approve is the first of those two user transactions and therefore half of that path's transaction and confirmation count, not half of all Uniswap mainnet transactions. Permit2 and Universal Router improve reuse, signing, and routing, but authority is still carried by an external spender model.

OpenSea

NFT markets such as OpenSea commonly keep an NFT at the user's address until fulfillment: the user signs a listing or offer, and a marketplace contract later transfers the NFT and payment asset. A seller may first approve one NFT or grant setApprovalForAll over an entire collection; an ERC-20 payer may also need token authorization. Orders can be signed offchain, while asset-transfer authority may remain persistently in the NFT or token contract.

USDT and USDC

USDT and USDC are widely used for onchain payments and DeFi settlement. A payment flow needs to make the payer, recipient, amount, asset, network, and validity clear enough for websites, APIs, agents, or relayers to settle reliably. USDT offers broad liquidity and multichain coverage, while USDC provides extensive developer tooling and programmable-payment support for checkout, gas-sponsored payment, API billing, and business settlement.

Many USDT / USDC payments still use ERC-20 transfer or approve plus transferFrom. USDC also supports EIP-3009 transferWithAuthorization / receiveWithAuthorization, where the payer signs EIP-712 typed data for one concrete transfer and the contract uses a nonce and validity window to prevent replay without first writing USDC.allowance. x402 moves payment requests into HTTP 402 semantics, allowing APIs, content, AI agents, and automated clients to pay per request with USDC and other stablecoins. However, capabilities such as EIP-3009 are extra features implemented by specific tokens such as newer USDC contracts, not a universal part of ERC-20. Most ERC-20 tokens, along with older or bridged assets on different networks, do not expose the same interfaces. Payment applications therefore cannot assume every token supports signed transfers, validity windows, or nonces: they generally need to identify the exact contract and network and retain transfer or approve plus transferFrom paths for basic ERC-20 assets. x402 standardizes the payment request and response flow, but it does not add these contract capabilities to the underlying token.

Risks and Costs in Existing Apps and ERC-20 Models

These models supported DeFi's early development, but they spread asset authority across token allowance, NFT operators, routers, markets, payment contracts, and custody platforms. Interaction cost first appears in paths that need new authorization: approve plus execute is two transactions, and approve is half of that path's transaction count. The benchmarks below use H1 2026 median successful mainnet receipts to compare approval and settlement costs. Approval gas does not complete the intended swap, listing, or payment; it only creates authority for later execution.

Public data is already large enough to matter. In December 2023, Chainalysis estimated roughly $1.0 billion lost to approval phishing from its sample since May 2021, including about $516.8 million in 2022 and $374.6 million through November 2023; in June 2026, Chainalysis also reported that Operation Spincaster processed more than 7,000 leads tied to about $162 million in losses. Scam Sniffer's annual reporting estimated about $494 million lost to EVM wallet drainer phishing in 2024, falling to about $84 million in 2025. These losses do not belong to one project; they come from reusable, disguiseable, and long-lived authority in the existing account and asset-authorization model.

Another common model is deposit-before-use: exchanges, lending pools, vaults, orderbooks, or custody contracts receive user assets first, then handle internal accounting, matching, settlement, or liquidation. This simplifies app logic, but moves the user's asset boundary from the wallet to the platform contract. This is not an abstract risk either: Chainalysis estimated about $2.2 billion stolen from crypto platforms in 2024, with DeFi accounting for the largest share of stolen assets in Q1 and centralized services becoming the most targeted platform type in Q2 and Q3; by mid-2025, more than $2.17 billion had already been stolen from cryptocurrency services, including the roughly $1.5 billion Bybit incident. TRM Labs also estimated about $2.2 billion lost to hacks and exploits in 2024, with more than $7.7 billion lost over three years. Deposit-based models concentrate many users' assets inside the same service, contract, or key-management system, so failures in business logic, access control, private-key management, or cross-chain components can amplify losses.

Benefits and Costs

• Benefit: simple and composable, and well suited to EOA accounts with no code or local state; much of today's DeFi and NFT market infrastructure started this way.
• Cost: approval is persistent state, so allowance or operator approval can remain after a transaction; it authorizes a spender or operator rather than one concrete business action.
• Cost: approve plus execute often means two transactions and two wallet confirmations, adding user time and gas cost.
• Cost: deposit-based platforms make asset availability and exit paths depend on platform logic, while concentrating the risk of failures in business logic, access control, private-key management, or cross-chain components.

State Model Difference

In traditional DeFi, the user address is mostly the signer, while state and authority live in external protocols: token allowance, NFT operators, pools, vaults, orders, and platform balances.

1Do moves the runtime back to the user's address. `executeRuntimeApp(app, data)` delegatecalls app logic into the user-account frame; `enabledApps`, nonces, and app state use namespaced storage, while asset-pull authority exists only for one execution window.

• Traditional DeFi: the first transaction writes allowance on the token; the second transaction executes the business action, and allowance may remain.
• 1Do: one transaction writes a transient pull context, app logic enters the account execution frame, and the context is cleared afterward with no token allowance left behind.

The main diagram compares only the two common paths: the traditional approve / execute two-transaction path and the 1Do token-pull one-transaction path. The core difference is that the traditional path leaves token authorization state first, while the 1Do path creates a pull context inside the account runtime for the current transaction.

The Account Itself Is the App Runtime

1Do's central claim is that the wallet address itself is the app execution boundary. The main account can be a user EOA with an activated ERC-7702 runtime or a smart contract account that already has runtime capability. The connected address is the runtime address; users do not need to migrate assets to a second smart-wallet address or enable an asset-management middle layer before using runtime apps.

Account capabilities such as Dex, NFT Market, Flash Loan, and Will do not require users to migrate assets or enter a new platform account. They express business logic, signature validation, and settlement around the same wallet runtime. Test-asset faucets are testnet support tools, not wallet-runtime capabilities themselves.

interface IERC8280 {
    event AppEnabled(address indexed host, address indexed app);
    event AppDisabled(address indexed host, address indexed app);

    function executeRuntimeApp(address app, bytes calldata data)
        external
        payable
        returns (bytes memory result);

    function enableApp(address app) external;
    function disableApp(address app) external;
    function isAppEnabled(address app) external view returns (bool);
}

The runtime enters app execution through an ERC-8280-style executeRuntimeApp(app, data), while enableApp / disableApp records which apps an address allows inside its own wallet runtime. Global registry gating and user-local enablement are separate gates; runtime app executability can be summarized as:

wallet.isAppEnabled(app) && registry.isAppAllowed(app)

• ERC-7702 lets an EOA address gain executable contract behavior; smart contract accounts can also host the same kind of runtime boundary directly.
• ERC-8280 defines the minimum runtime app host surface. executeRuntimeApp can be triggered without the wallet owner submitting the transaction, but execution still has to pass local enablement, global registry gating, and the app's own signature or state rules.
• ERC-1271 lets runtime wallets validate EIP-712 intents, orders, payment authorizations, and will plans.
• ERC-7201 uses namespaced storage to isolate host state and app state.
• ERC-165 lets frontends, relayers, and apps discover runtime, pull, transfer-with-signature, and related capabilities.

One-Time Asset Pulls

Within 1Do runtime paths and targets compatible with the asset-pull interface, one-time asset pulls can replace separate approve transactions. Users no longer send approve or setApprovalForAll to a token, router, or market, and no allowance or operator authority is created. ERC-8284 / ERC-8285 create a one-time pull context, move the asset, and clear the context inside the same business transaction.

This is not another signature layer on top of approve or a reusable approval wrapper. It moves asset authorization out of persistent asset-contract state and into the user's account runtime. An app receives authority only for the current target, asset, amount cap, or tokenId, and cannot carry that authority into a later transaction.

interface IERC8284 {
    function executeWithTokenPull(
        address target,
        bytes calldata data,
        address asset,
        uint256 maxAmount
    ) external;

    function tokenPullToCaller(address asset, uint256 amount) external;
}

interface IERC8285 {
    function executeWithNftPull(
        address target,
        bytes calldata data,
        address asset,
        uint256 tokenId
    ) external;

    function nftPullToCaller(address asset, uint256 tokenId) external;
}

• Replaces separate approve transactions on compatible paths: ERC-20 needs no approve / allowance, while NFTs need no approve / setApprovalForAll / operator authority.
• Authorization and business execution become one transaction instead of an approve + execute sequence.
• Token pull binds target, asset, and remainingAmount; cumulative pull cannot exceed the cap.
• NFT pull binds target, asset, and tokenId; one target can pull one specific NFT during one execution.
• The context is cleared before success or revert returns, leaving no reusable asset authorization after the execution window.

Execution Flow

1. The user connects the current address to a wallet runtime; the address can be an ERC-7702-capable EOA or a smart contract account.
2. After one ERC-7702 runtime activation, an EOA can keep using the runtime until the user revokes or replaces it; a smart contract account uses its own runtime capability directly.
3. The user selects a runtime app such as DEX, NFT Market, Flash Loan, or Will.
4. The user locally enables an app with enableApp; the platform registry still controls global executability independently.
5. The user enters the app and signs an EIP-712 intent, order, will plan, or transfer authorization.
6. Normal runtime actions enter through executeRuntimeApp(app, data). For a token pull, the paying account calls executeWithTokenPull(target, data, asset, maxAmount). The target can be a runtime app or a traditional DeFi contract compatible with tokenPullToCaller; the target contract calls tokenPullToCaller(asset, amount) as needed during that call.
7. After execution, temporary pull context is cleared and the asset contract retains no allowance, operator, or other reusable authorization; the wallet runtime keeps only app-enablement state controlled by the user.

Minimal tokens do not require users to abandon ERC-20 or ERC-721. ERC-7196 / ERC-7561 retain the balance, ownership, and basic-transfer semantics of ERC-20 / ERC-721, while wallet runtimes supply authorization and composition. The 1Do app layer is designed to support existing ERC-20 / ERC-721 assets alongside these simplified standards, so a change in asset standard should not require rewriting an app or migrating user assets.

The 1Do ERC proposals in this section should currently be read as drafts. Interfaces and names may continue to change during review, and integrations should follow the corresponding proposal repository and deployed version.

This gives the 1Do app layer broad coverage across token standards: asset contracts handle balances and ownership, while the account runtime handles composition, asset pull, and clear signing.

ERC-7196 / ERC-7561 point toward smaller token / NFT contracts: ERC-7196 removes transferFrom, approve, and allowance from ERC-20; ERC-7561 removes approve, setApprovalForAll, getApproved, isApprovedForAll, and safeTransferFrom from ERC-721.

Alongside these simplified asset standards, ERC-7204 / ERC-7564 define wallet-level token / NFT transfer, allowance, and operator-management interfaces. ERC-8064 / ERC-8067 add Permit extensions based on EIP-712, ERC-1271, scoped nonces, and validity windows, allowing relayers to submit these wallet-level authorizations from offchain signatures.

How the Standards Fit Together

• Asset layer: ERC-7196 / ERC-7561 define simplified tokens and NFTs.
• Wallet asset-management layer: ERC-7204 / ERC-7564 define wallet-level transfers, allowances, and operator management.
• Signed authorization and transfer layer: ERC-8064 / ERC-8067 establish wallet-level authorization from offchain signatures; ERC-8112 / ERC-8114 use offchain signatures for one explicit token or NFT transfer.
• Runtime execution layer: ERC-8280 defines the app host; ERC-8284 / ERC-8285 let a target pull tokens or NFTs as needed within one execution window.

interface IERC7196 {
    event Transfer(address indexed from, address indexed to, uint256 value);

    function totalSupply() external view returns (uint256 total);
    function balanceOf(address owner) external view returns (uint256 balance);
    function transfer(address to, uint256 value) external returns (bool success);
}

interface IERC7561 {
    event Transfer(
        address indexed from,
        address indexed to,
        uint256 indexed tokenId
    );

    function balanceOf(address owner) external view returns (uint256);
    function ownerOf(uint256 tokenId) external view returns (address);
    function transferFrom(address from, address to, uint256 tokenId) external;
}

Payments should not depend only on token-specific permit support, and each payment app should not maintain its own long-lived allowance system. 1Do puts payment authority in the wallet runtime: one-off transfers can use wallet-level typed data.

ERC-8112 / ERC-8114 correspond to wallet-level token / NFT transfer with signature, which fits one-off or relayed transfers. The signing domain binds to the wallet address, and nonces are isolated by asset and recipient dimensions. ERC-8112 standardizes ERC-20 transfers; 1Do extends it by treating asset == address(0) as the native asset.

interface IERC8112 {
    function tokenTransferNonce(address asset, address to)
        external
        view
        returns (uint256);

    function tokenTransferWithSig(
        address asset,
        address to,
        uint256 value,
        uint256 deadline,
        bytes calldata signature
    ) external returns (bool success);
}

interface IERC8114 {
    function nftTransferNonce(address asset, uint256 tokenId)
        external
        view
        returns (uint256);

    function nftTransferWithSig(
        address asset,
        address to,
        uint256 tokenId,
        uint256 deadline,
        bytes calldata signature
    ) external returns (bool success);
}

• ERC-8112 standardizes signed ERC-20 transfer at the wallet layer; the 1Do extension also supports the native asset through asset == address(0). tokenTransferWithSig validates EIP-712 + ERC-1271 before transfer.
• ERC-8114 puts NFT transfer with signature at the wallet layer; nftTransferWithSig validates then calls safeTransferFrom.
• x402 can be an HTTP entry point: a one-off ERC-20 payment can map to ERC-8112.

Session Pay: Bounded Recurring Payments

One-off signed transfers suit individual payments, while agents, APIs, subscriptions, and frequent micropayments need clear limits without reopening the wallet for every charge. Session Pay lets the wallet sign one session grant that fixes the session key, payee, asset, cumulative spend limit, and expiry. The session key then signs increasing cumulative payment totals, and any relayer can submit settlement.

• One wallet authorization: SessionGrant binds the session key, payee, token, spendLimit, sessionExpiresAt, and salt.
• Delta settlement: SettlementAuthorization signs newTotalPaid, and the contract pays only the difference from onchain totalPaid, so an old authorization cannot charge twice.
• Persistent bounds: the cumulative total cannot decrease or exceed the limit; settlement fails after expiry or user revocation.
• Native assets and ERC-20 tokens are supported for x402 agent payments, API billing, subscriptions, and other repeated micropayment flows.

1Do runtime apps do not move user assets into a new platform account. They execute business logic inside the user's own wallet runtime. Each app keeps its business model, while settlement, signature validation, asset pull, and execution boundaries converge in the same account runtime.

Application Constraints

Runtime apps execute with delegatecall in the user's account context, so they must isolate storage, restrict nested execution, and pass code review and registry gating. An app keeps its own business state machine and settlement rules, but cannot bypass wallet-core authority or turn a one-time asset pull into reusable permission. Detailed engineering rules appear in “Technical Appendix: Runtime App Constraints.”

DEX

DEX is an order-book exchange built around offchain signed orders and wallet settlement. A maker signs price, amount, expiry, nonce, and other order terms offchain instead of maintaining a maker order onchain; once conditions are met, a taker can submit a fill transaction. The current baseline focuses on full fills, keeping order state and settlement outcomes direct.

• Compared with an AMM: price and amount are explicit in the order, and execution does not depend on a liquidity-pool pricing curve; this suits assets exchanged on agreed terms.
• Compared with a traditional onchain order book: signed orders can be shared or cancelled offchain, while only a fill or cancellation needs an onchain state change.
• Compared with a common first ERC-20 flow in Uniswap: the taker can set the amount pullable for this transaction and settle in one runtime transaction, without leaving a router with long-lived allowance first.
• Compared with custodial exchanges: assets do not become platform balances; any address that satisfies the order conditions can submit settlement, and assets move only on a fill.

NFT Market

NFT Market is an offchain signed order book for NFT trading, supporting NFT-to-NFT and NFT-to-token matching. An order expresses the assets, quantities, expiry, and other terms offchain; when matched, both wallets settle in one transaction. NFTs and payment assets remain in their respective accounts before fulfillment.

• Compared with common first-authorization flows in traditional NFT marketplaces: settlement can be scoped to the concrete NFT and payment asset in an order, without first granting setApprovalForAll over an entire collection.
• Compared with long-lived operator approval: NFT pull binds the target contract, NFT contract, and tokenId, so the market does not receive reusable authority to move an entire collection.
• Compared with NFT-to-token marketplaces: the same order book can express a direct NFT-to-NFT exchange, without first selling an NFT for tokens and then making a separate purchase.
• Compared with custodial marketplaces: the market app handles orders, matching, and fill state, while neither side needs to pre-deposit assets into a platform.

Session Pay

Session Pay is a session-based payment app for agents, APIs, and subscriptions. The user signs one bounded SessionGrant with a fixed payee and expiry. During the session, a session key can produce cumulative settlement authorizations for a website, agent, or relayer to submit, without another wallet popup for every micropayment.

• Compared with unlimited allowance: authority is scoped to one payee, asset, cumulative limit, and validity period.
• Compared with signing every payment in the wallet: an independent session key authorizes later charges without involving the wallet owner each time.
• Compared with a prepaid platform balance: funds remain in the user's wallet and move only when a valid authorization is settled.
• Compared with simple automatic debit: the runtime records the cumulative amount paid, and rejects over-limit, expired, decreasing-total, or revoked sessions.

Will

Will lets a user sign one weighted ETH / ERC-20 will plan offchain. The plan contains beneficiaries, weights, executor fee, expiry, and trigger mode; after a time or inactivity condition is satisfied, any executor can submit the plan and distribute one or more unprocessed assets directly to beneficiaries.

• Compared with a traditional legal will or custody arrangement: assets remain in the user's account before the trigger, with no need to migrate them to a platform, lawyer, multisig, or inheritance contract first.
• Compared with manual execution: beneficiaries, weights, trigger conditions, and executor fee are fixed by an EIP-712 signed plan, so an executor cannot rewrite distribution rules.
• Compared with a simple timelock: Will can use a time trigger or combine heartbeat inactivity with a grace period, matching the need for self-custody while active and execution only after loss of activity.
• Compared with one-off full distribution: the same plan version can process different assets across several transactions; settled assets are recorded to prevent duplicate distribution. Resetting a plan increments its version and invalidates old signatures.

Flash Loan

Flash Loan is based on EIP-3156. Once a user enables the app, ERC-20 balances in the wallet can serve as flash-loan liquidity; borrowing, callback, and repayment occur in the same transaction. After successful repayment, fees are allocated by rule, with the wallet's portion recorded as earnings.

• Compared with a traditional flash-loan pool: liquidity does not need to be deposited into a separate pool; wallet balances can provide liquidity after the app is enabled.
• Compared with ordinary lending: flash loans create no cross-block debt; the borrower must return principal and fee in the same transaction callback or the entire transaction reverts.
• Compared with idle balances: a wallet owner can choose to provide composable liquidity without migrating assets and retain the economic claim to fee earnings.

The shared advantage is not one isolated gas number. It is fewer migrations, fewer long-lived approvals, fewer platform balances, fewer repeated signatures, and a risk model users can understand around one account boundary.

executeRuntimeApp(app, data) uses delegatecall, so app code runs in the user's account address, balance, and storage context. Incorrect storage or call boundaries directly affect the account, and runtime apps therefore follow these constraints:

• Persistent state uses ERC-7201 namespaced storage and documents its storage root with @custom:storage-location to avoid collisions with the account or other apps.
• The app execution address points to directly auditable logic and does not use Transparent, UUPS, or Beacon proxies to construct another delegatecall chain.
• An app cannot manufacture an external self-call frame through address(this).call(...) or nest executeRuntimeApp; an execution lock rejects nested or conflicting execution.
• An app may own its state machine, events, errors, pricing, and settlement rules, but cannot reimplement wallet self-authorization, app enablement, or another wallet-core permission system.
• ERC-8284 / ERC-8285 pulls are valid only for the current call and bind target, asset, amount cap, or tokenId. Wrong-target, wrong-asset, over-cap, or nested pulls fail, and the temporary context is cleared when the call ends.

Security Boundaries

1Do's security model does not assume every app is trusted. Instead, it constrains what apps can do inside the user's own wallet runtime boundary. A relayer, counterparty, keeper, or ordinary caller may trigger execution, but triggering an enabled app does not grant wallet-owner authority.

• Owner authority and trigger authority are separate.
• Local enablement and registry gating are separate.
• Signature validation converges in the wallet runtime through ERC-1271 and EIP-712.
• Nested runtime execution is rejected so apps cannot bypass execution locks or caller discipline.

Governance and Recovery

A user can revoke local app enablement through disableApp, and an ERC-7702 EOA can revoke or replace its runtime code. The platform registry prevents unregistered or delisted apps from continuing to execute. In a production deployment, registry administrators, upgrade procedures, emergency delisting, audit records, and recovery paths need to be public so users can evaluate the trust boundary of platform-level gating.

1Do does not claim that all risk disappears. A clearer runtime boundary can reduce risks from long-lived approval, platform-custodied balances, and app-owned permission systems, but it does not replace app audits, user judgment, or clear wallet signing displays.

Cost and Efficiency

1Do optimizes the complete interaction path rather than one opcode: fewer approvals, platform deposits, repeated confirmations, and persistent permissions. External-protocol settlement, approval, and USDC payment figures below use median successful H1 2026 mainnet receipts. 1Do DEX / NFT and ERC-8112 figures show local complete-transaction medians and ranges. Complex transactions and high-gas tails make the means in this external settlement sample about 25%–74% higher than the medians, so this whitepaper uses medians to represent typical mainnet cost.

Scalability

1Do scales by separating the account runtime from app logic: the user keeps the same address and asset boundary, while apps enter as enableable, disableable, discoverable runtime logic. New apps do not need users to migrate assets, and each app does not need to recreate a long-lived approval system.

• App scalability: new apps can attach to the same account runtime instead of creating a new asset account per app.
• Asset scalability: the app layer is designed for ERC-20 / ERC-721 compatibility and can support smaller token / NFT standards over time.
• Frontend and relayer scalability: ERC-165, registry gating, and local enableApp make app capabilities easier to discover and gate.
• Ecosystem scalability: 1Do does not require external DeFi to change immediately; current asset standards, compatible pull paths, and future minimal asset standards can coexist.

1Do is not trying to turn wallets into a giant centralized app framework. It is trying to converge account capability onto the user's own address.

At the macro level, 1Do wants users to activate one account runtime and keep extending DeFi, payments, NFTs, wills, and future apps.

The engineering foundation uses existing standards: ERC-7702 provides EOA runtime capability; ERC-1271 and EIP-712 support contract-account signatures and typed intent; x402 is an HTTP payment entry point; and ERC-7201 (diamond / namespaced storage) isolates persistent account and app state.

At the application layer, ERC-8112 handles one-off signed payments, while Session Pay shows how the same runtime can support recurring sessions bounded by payee, asset, cumulative limit, expiry, and user revocation, giving agents, APIs, and subscriptions a settlement path without reopening the wallet for every charge.

The ERC drafts initiated by 1Do form four layers:

• Asset layer: ERC-7196 / ERC-7561 define simplified tokens and NFTs for contract wallets.
• Wallet asset-management layer: ERC-7204 / ERC-7564 define wallet-level token and NFT management; ERC-8064 / ERC-8067 add offchain-signature Permit flows.
• Signed-transfer layer: ERC-8112 / ERC-8114 define wallet-level signed transfers for ERC-20 tokens and NFTs; 1Do extends ERC-8112 with native-asset transfer.
• Runtime execution layer: ERC-8280 defines the app host and local-enablement interface; ERC-8284 / ERC-8285 define target-bound token and NFT pulls within one execution window.

Together, these drafts address asset representation, wallet-level management, signed authorization, one-time transfer, and runtime execution, converging user-readable authority and settlement at the wallet-runtime boundary.

• Uniswap Labs, Introducing Permit2 & Universal Router, 2022-11-17: https://blog.uniswap.org/permit2-and-universal-router
• OpenSea Developer Documentation, Seaport: https://docs.opensea.io/docs/seaport
• OpenSea Developer Documentation, Get listing creation actions: https://docs.opensea.io/reference/create_listing_actions
• Tether, Supported Protocols and Integration Guidelines: https://tether.to/en/supported-protocols/
• Tether, FAQs: https://tether.to/faqs/
• Circle, 4 Ways to Authorize USDC Smart Contract Interactions, 2025-09-04: https://www.circle.com/blog/four-ways-to-authorize-usdc-smart-contract-interactions-with-circle-sdk
• EIP-3009, Transfer With Authorization: https://eips.ethereum.org/EIPS/eip-3009
• Coinbase Developer Documentation, x402 Overview: https://docs.cdp.coinbase.com/x402/welcome
• x402 Documentation, How x402 Works: https://docs.x402.org/core-concepts/how-x402-works
• Ledger Support, Understanding Ethereum Token Approvals: https://support.ledger.com/article/Ethereum-Token-Approvals-Explained
• MetaMask Help Center, What is a token approval?: https://support.metamask.io/stay-safe/safety-in-web3/what-is-a-token-approval/
• Chainalysis, Targeted Approval Phishing Scams See Explosive Growth Over Last Two Years, 2023-12-14: https://www.chainalysis.com/blog/approval-phishing-cryptocurrency-scams-2023/
• Chainalysis, Approval Phishing: From Just One Case to Full-Scale Disruption, 2026-06-17: https://www.chainalysis.com/blog/what-is-approval-phishing/
• Scam Sniffer Reports archive, 2024 and 2025 wallet drainer annual loss estimates: https://drops.scamsniffer.io/category/reports/
• Chainalysis, $2.2 Billion Stolen from Crypto Platforms in 2024, 2024-12-19: https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2025/
• Chainalysis, 2025 Crypto Crime Mid-year Update, 2025-07-17: https://www.chainalysis.com/blog/2025-crypto-crime-mid-year-update/
• TRM Labs, $2.2 billion was stolen in crypto-related hacks in 2024, 2025-03-17: https://www.trmlabs.com/resources/blog/category-deep-dive-2-2-billion-was-stolen-in-crypto-related-hacks-in-2024

• Google Cloud Blockchain Analytics, Ethereum Mainnet dataset: https://cloud.google.com/blockchain-analytics/docs/supported-datasets
• Google BigQuery public crypto_ethereum dataset: https://console.cloud.google.com/marketplace/product/ethereum/crypto-ethereum-blockchain

• ERC-7196: Simple token, Simplified ERC-20: https://eips.ethereum.org/EIPS/eip-7196
• ERC-7561: Simple NFT, Simplified ERC-721: https://eips.ethereum.org/EIPS/eip-7561
• ERC-7204: Contract wallet management token: https://eips.ethereum.org/EIPS/eip-7204
• ERC-7564: Contract wallet management NFT: https://eips.ethereum.org/EIPS/eip-7564
• ERC-8064: Contract Wallet Management Token Permit Extension: https://github.com/1do-labs/ERCs/blob/feat/erc7204-permit/ERCS/erc-8064.md
• ERC-8067: NFT Permit Extension for Smart Wallet: https://github.com/1do-labs/ERCs/blob/feat/erc7564-permit/ERCS/erc-8067.md
• ERC-8112: Token Transfer With Signature: https://github.com/1do-labs/ERCs/blob/feat/tokentransfer-auth/ERCS/erc-8112.md
• ERC-8114: NFT Transfer With Signature: https://github.com/1do-labs/ERCs/blob/feat/nfttransfer-sig/ERCS/erc-8114.md
• ERC-8280: Contract Runtime Apps: https://github.com/1do-labs/ERCs/blob/feat/runtimeapp/ERCS/erc-8280.md
• ERC-8284: Wallet-Scoped Token Pull Execution: https://github.com/1do-labs/ERCs/blob/feat/tokenpull/ERCS/erc-8284.md
• ERC-8285: Wallet-Scoped NFT Pull Execution: https://github.com/1do-labs/ERCs/blob/feat/nftpull/ERCS/erc-8285.md
• ERC-165: Standard Interface Detection: https://eips.ethereum.org/EIPS/eip-165
• ERC-1271: Standard Signature Validation Method for Contracts: https://eips.ethereum.org/EIPS/eip-1271
• EIP-712: Typed Structured Data Hashing and Signing: https://eips.ethereum.org/EIPS/eip-712
• ERC-7201: Namespaced Storage Layout: https://eips.ethereum.org/EIPS/eip-7201
• EIP-7702: Set Code for EOAs: https://eips.ethereum.org/EIPS/eip-7702