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.

After activating an ERC-7702 runtime, the same address becomes the user's wallet, app runtime, and settlement boundary for DeFi, payments, NFTs, wills, sessions, 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 enter through Core, execute through 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 is one of Ethereum's most important decentralized exchange protocols. Its core function is automated market making and swapping between ERC-20 assets. It was built in the EOA-account and ERC-20-asset environment: the user's wallet address holds tokens, a trading contract or router receives ERC-20 allowance, and the protocol moves assets into pools to complete swaps and settlement.

The strength of this model is openness, composability, and no platform-custodied balance. Almost any ERC-20 can enter the same trading path. The friction is that a user's first interaction with a given ERC-20 usually cannot be a direct swap: it is first an approve transaction, then a swap transaction. In that first-use flow, approve is commonly 1 of 2 user transactions, or 50% of the transaction and confirmation count. An EOA cannot natively express an account policy such as “only this swap, only this quote, and clear authorization after execution,” so authority has to live in token.allowance or in a spender model such as Permit2. Permit2 and Universal Router improve reuse, signing, and routing, but users still need to understand which asset, amount, duration, and external contract they are authorizing.

OpenSea

OpenSea is a major NFT marketplace, and Seaport is its open order protocol. NFT markets also come from the EOA plus ERC-721 / ERC-1155 model: NFTs remain at the user's address, the user signs an order, and the marketplace or execution contract transfers the NFT and payment asset when the order is fulfilled.

To let the market complete a sale later, users commonly cannot only sign one listing or fulfillment order; they also need approve or setApprovalForAll on the NFT collection first. This lowers later listing and fulfillment friction and makes offchain orderbooks possible, but first-time marketplace use still includes an extra transaction, extra gas, and an extra wallet confirmation. The operator-approval boundary is “can this contract transfer the collection,” not “is this one order being filled.” If a user approves a malicious operator, signs a disguised order, or leaves approval behind, the risk can cover the whole collection rather than one listing.

USDT and USDC

USDT and USDC are two of the most widely used dollar stablecoins for onchain payments. Unlike general DeFi trading, payment is less about routing through the best market and more about making payer, recipient, amount, asset, network, and validity clear enough for websites, APIs, agents, or relayers to settle reliably. USDT's strength is broad liquidity, trading-pair coverage, and multichain distribution, making it useful for transfers and settlement across many venues. USDC's strength is developer tooling, compliance interfaces, and programmable-payment support, especially for checkout, gasless 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. These paths improve payment programmability, but risk does not disappear: USDT / USDC still involve wrong-chain transfers, wrong recipients, centralized issuer and freezing policies, contract compatibility, long-lived allowance, signature phishing, facilitator verification, frontends, and agent policy. If a user or agent cannot clearly understand what resource is being paid for, how much is being paid, which chain is used, and who can settle it, payment signatures can still be phished or abused.

Risks and Costs in Existing Apps and ERC-20 Models

The shared base across these models is EOA accounts, ERC-20 / ERC-721 approvals, external spenders / operators, and user intent interpreted through frontends and signing interfaces. This base enabled early open finance, but it also spreads asset authority across token allowance, NFT operators, routers, markets, payment contracts, and custody platforms. The first cost is interaction and gas: Ledger's token-approval explainer notes that each approval is a separate onchain transaction with its own gas fee; in a typical first ERC-20 app flow, approve plus execute means 2 transactions, so approve is 50% of the transaction count. In the common gas budgets used in this whitepaper, ERC-20 approve is usually about 50k-75k gas, while NFT approve / setApprovalForAll is usually about 50k-100k gas. That gas does not complete the user's intended swap, listing, or payment; it only opens permission for later app execution.

The risk should not be reduced to one fixed probability such as “what percentage of stolen funds comes from malicious approvals,” because reports use different denominators for stolen funds, scams, phishing, wallet drainers, and approval phishing. The conservative conclusion is that approve-style long-lived authorization has become a scalable attack surface.

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.

• Benefit: simple and composable; much of today's DeFi and NFT market infrastructure started this way.
• Cost: approval is persistent state that may remain after the transaction.
• Cost: approval targets a spender or operator, not one concrete business action.
• Cost: approve plus execute often means two transactions and two wallet confirmations.
• Cost: deposit-based platforms make availability and exit paths depend on platform logic.

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 protocol is the state center; the user account is usually the signing entry point.
• 1Do: the user address is the state and runtime center; apps become pluggable logic.

The Account Itself Is the App Runtime

1Do's core claim is that the wallet address itself is the app execution boundary. The main account path is ERC-7702: the connected address is the runtime address; users do not need to migrate assets to a second smart-wallet address, mint an NFT, or enable an asset-management middle layer before using runtime apps.

1Do Core is the unified product entry for connecting the wallet, entering runtime apps, and opening account capabilities such as Dex, NFT Market, Flash Loan, Will, and Session Pay. Core is the user experience surface; runtime is the account execution boundary. 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 platform gating and user-local enablement are separate gates; current core runtime executability can be summarized as:

wallet.isAppEnabled(app) && registry.isEntitled(address(0), app)

• ERC-7702 lets an EOA address gain executable contract behavior without migrating assets to a new smart-wallet address.
• ERC-8280 defines the minimum runtime app host surface; executeRuntimeApp is the permissionless trigger entry point.
• 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.

1Do remains compatible with ERC-20 and ERC-721 because they are still the dominant asset interfaces. But in a contract-wallet environment, asset contracts do not need to carry every user-permission feature. Asset contracts should behave more like balance and ownership ledgers, while the account runtime expresses authorization, composition, sessions, pull flows, 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, moving user-level authority upward into contract wallets.

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;
}

In the current compatible path, 1Do uses ERC-8284 / ERC-8285 to replace long-lived token allowance and NFT operator approval with pull contexts scoped to one execution window.

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;
}

• 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.
• Context must be cleared before success or revert returns; after the execution window ends, pulls must fail.
• The result is no reusable allowance or operator approval left behind.

Runtime apps in 1Do Core 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 authorization, and execution boundaries converge in the same account runtime.

• Dex: makers sign EIP-712 orders offchain, and buyers settle once through their own 7702 runtime. Compared with approve -> swap, Dex does not require long-lived token allowance or pre-depositing assets into a trading platform.
• NFT Market: order and market rules live in the market app, while NFT or payment settlement uses wallet-native pull. Compared with setApprovalForAll, users do not need to grant a marketplace or aggregator long-term authority over an entire NFT collection.
• Flash Loan: enabled wallet balances become composable liquidity while remaining inside the user's account boundary.
• Will: inheritance plans remain inside the user's account semantics, and assets stay at the wallet address before the trigger; an executor can only process undistributed assets according to the plan and runtime rules.
• Session Pay: built for APIs, AI agents, subscriptions, and high-frequency micropayments. The user signs a session grant once, and later settlement authorizations execute within limits, periods, and cumulative amounts.

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.

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, while continuous or high-frequency payments can use Session Pay session grants and runtime app settlement.

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.

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 puts token/native transfer with signature at the wallet layer; tokenTransferWithSig validates EIP-712 + ERC-1271 before transfer.
• ERC-8114 puts NFT transfer with signature at the wallet layer; nftTransferWithSig validates then safeTransferFroms.
• Session Pay is an independent runtime app: session grants and cumulative settlement authorizations execute through Session Pay's own runtime settlement path, not through IERC8112.
• x402 can be an HTTP entry point: one-off payments map to ERC-8112; session payments map to Session Pay session settlement.

1. The user opens 1Do Core or 1Do Wallet and connects the current address.
2. If the address has not activated runtime yet, the user activates the ERC-7702 runtime.
3. The user opens runtime apps such as Dex, NFT Market, Flash Loan, Will, and Session Pay in 1Do Core.
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, session grant, will plan, or transfer authorization.
6. The transaction executes through executeRuntimeApp(...), executeWithTokenPull(...), tokenTransferWithSig(...), or the app's own settlement path.
7. After execution, temporary pull context is cleared; long-term authority remains inside the user's own wallet runtime boundary.

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.

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.

• 1Do does not guarantee that every runtime app's business logic is risk-free.
• Registry gating is not a substitute for user judgment.
• Wallet-native authorization reduces long-lived allowance and operator approval, but does not remove phishing signatures, wrong recipient addresses, or malicious frontend risk.
• ERC-7702 availability depends on chain, wallet, RPC, and signing-tool support.
• 1Do does not require today's ecosystem to immediately abandon ERC-20 or ERC-721.

The cost of traditional DeFi is not only raw chain gas. It also includes user interactions, persistent approval risk, and the cost of recovering from failed or stale permissions. 1Do prioritizes fewer repeated approvals, fewer account migrations, and fewer app-owned permission systems.

The 1Do numbers below come from the current core Forge gas benchmarks. Traditional paths are shown as common gas-limit budget ranges; actual values vary by router, order type, asset state, chain, and calldata.

Scenario                     Traditional gas-limit budget          Current 1Do benchmark
Dex vs Uniswap               approve 50k-75k + swap 150k-220k    token/token 222,705
                             about 200k-295k, 2 confirmations    native/token 150,923
                                                                  token/native 145,244

NFTMarket vs OpenSea/Seaport approve/setApprovalForAll 50k-100k   NFT/token 210,728
                             + fulfill 250k-450k                 NFT/NFT 200,140
                             about 300k-550k, often 2 confirmations

Payments vs USDC-native auth EIP-3009 / transferWithAuthorization ERC-8112 first transfer 70,425
                             commonly budgeted around 80k-110k   second same asset/to 16,869

So 1Do's gas optimization is not only about making one opcode cheaper. It removes steps and residue: one less approve, one less deposit, one less platform balance, and one less long-lived operator are each fewer sources of gas cost, risk, and user confusion.

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, sessions, and future apps. At the engineering level, 1Do uses standards such as ERC-7702, ERC-8280, ERC-8284, ERC-8285, ERC-8112, ERC-8114, ERC-1271, and EIP-712 to move execution boundaries, signatures, asset authority, and app enablement back into the wallet.

• 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
• Zelin Li, Qin Wang, Zhipeng Wang, Five Attacks on x402 Agentic Payment Protocol, 2026-05-12: https://arxiv.org/abs/2605.11781
• 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