新一代链上账户与应用运行平台

1Do 是新一代链上账户与应用运行平台。它的目标不是再造一个托管式应用入口，而是把账户、资产授权、签名验证和应用执行边界收敛到用户自己的地址。

在 1Do 中，用户激活一次 ERC-7702 运行时后，同一个地址既是钱包，也是应用运行环境，也是 DeFi、支付、NFT、遗产和会话化应用的结算边界。应用可以独立创新，但不能把用户从自己的账户边界里搬走。

• 账户跟随用户，而不是跟随某个应用。
• 资产权限收敛在钱包运行时，而不是散落在代币、路由器、市场和支付合约里。
• 应用通过 Core 进入，通过运行时执行，通过钱包原生授权结算。
• 用户体验从理解底层合约调用，转向理解自己正在完成的动作。

以太坊早期默认用户使用 EOA。EOA 没有代码、没有本地状态，也不能表达细粒度执行策略，所以 DeFi 把大量权限逻辑下沉到代币、路由器、市场、金库或应用合约里。

ERC-20 approve(spender, amount) / allowance(owner, spender) 是当前 DeFi 最典型的交互模型。用户先批准路由器或应用使用某个代币，再由应用在交易、支付、订阅或结算时通过 transferFrom 拉取资产。NFT 也有类似问题：approve、setApprovalForAll 和操作员授权把用户级权限长期放在资产合约或市场合约里。

Uniswap

Uniswap 是以太坊上最重要的去中心化交易协议之一，核心功能是让用户在 ERC-20 资产之间做自动化做市和兑换。它诞生并成长于 EOA 账户和 ERC-20 标准资产的基础之上：用户的钱包地址持有代币，交易合约或路由器通过 ERC-20 allowance 获得支出权，再把资产送入池子、完成兑换和结算。

这种模式的优点是开放、可组合、无需平台托管余额，任何 ERC-20 都可以接入同一套交易路径。麻烦在于，用户首次用某个 ERC-20 交易时通常不能直接 swap，而是要先发一笔 approve，再发一笔 swap；在这个首次交互流程里，approve 通常占 2 笔用户交易中的 1 笔，也就是 50% 的交易次数和确认次数。EOA 本身不能表达“只允许这一次 swap、只允许这个报价、执行完自动清理授权”的账户策略，所以授权必须落在 token.allowance 或 Permit2 这类 spender 模型里。Permit2 和 Universal Router 改善了授权复用、签名和路由体验，但用户仍要理解自己把哪种资产、多少额度、多久期限交给了哪个外部合约。

OpenSea

OpenSea 是主流 NFT 市场，Seaport 是其开放订单协议。NFT 市场同样建立在 EOA 和 ERC-721 / ERC-1155 的基础上：NFT 留在用户地址中，用户签署订单，市场或执行合约在成交时根据订单规则转移 NFT 和支付资产。

为了让市场在未来某个时间完成成交，用户通常不能只签一笔 listing 或成交订单，还要先对 NFT 集合执行 approve 或 setApprovalForAll。它降低了后续 listing 和成交的交互成本，也让链下订单簿成为可能；但首次挂牌或首次使用市场时，授权动作本身就是额外交易、额外 gas 和额外钱包确认。operator 授权的边界是“某个合约能否转移整套集合”，而不是“某一笔订单是否成交”。如果用户误授权恶意 operator、签署伪装订单，或授权长期遗留在资产合约里，风险会覆盖整个 collection，而不只是某一次挂牌。

USDT 与 USDC

USDT 与 USDC 是链上支付场景中最常用的美元稳定币。和通用 DeFi 交易不同，支付的核心不是撮合最优路径，而是让付款方、收款方、金额、币种、网络和有效期足够清晰，并让支付可以被网站、API、agent 或中继者可靠结算。USDT 的优势是流动性、交易对和多链覆盖极强，适合广泛的转账和结算场景；USDC 的优势是开发者工具、合规接口和可编程支付支持更完整，尤其适合 checkout、gasless payment、API 计费和企业结算。

在授权模型上，很多 USDT / USDC 支付仍走 ERC-20 transfer 或 approve + transferFrom；USDC 还支持 EIP-3009 transferWithAuthorization / receiveWithAuthorization，让付款方用 EIP-712 签名授权一次具体转账，合约通过 nonce 和有效期防止重放，不需要先写入 USDC.allowance。x402 则把支付请求放到 HTTP 402 语义中，让 API、内容、AI agent 和自动化客户端可以按请求用 USDC 等稳定币付款。这些路径提升了支付可编程性，但风险不会消失：USDT / USDC 仍有链选择错误、收款地址错误、中心化发行方和冻结策略、合约兼容性、长期 allowance、签名钓鱼、facilitator 校验、前端和 agent 策略等风险。如果用户或 agent 无法看懂自己正在为哪个资源付款、付款多少、在哪条链上付款、可被谁结算，支付签名仍可能被钓鱼或滥用。

现有 APP 和 ERC-20 模式的风险与成本

上述模式的共同基础是 EOA、ERC-20 / ERC-721 授权、外部 spender / operator、以及大量由前端和签名界面解释的用户意图。它们支撑了开放金融的早期繁荣，但也把资产权限分散在 token allowance、NFT operator、router、market、支付合约和托管平台中。成本首先体现在交互和 gas：Ledger 对 token approval 的解释也指出，approval 会作为单独交易上链并产生 gas 费用；在典型首次 ERC-20 APP 交互里，approve + execute 是 2 笔交易，approve 占首次流程交易次数的 50%。按白皮书中的常见预算，ERC-20 approve 通常约 50k-75k gas，NFT approve / setApprovalForAll 通常约 50k-100k gas；这些 gas 并不完成用户真正想要的 swap、listing 或支付，只是为后续应用执行打开权限。

风险不能严谨地简化成一个固定的“被盗资金中有多少概率来自恶意授权”，因为不同报告把 stolen funds、scams、phishing、wallet drainer 和 approval phishing 分在不同口径里；更稳妥的结论是：approve 这类长期授权本身已经成为可规模化利用的攻击面。

公开数据已经足够说明规模。Chainalysis 在 2023 年 12 月估算，样本地址自 2021 年 5 月以来通过 approval phishing 造成约 10 亿美元损失，其中 2022 年约 5.168 亿美元、2023 年截至 11 月约 3.746 亿美元；Chainalysis 2026 年 6 月又披露 Operation Spincaster 在多个国家处理超过 7,000 条线索，关联约 1.62 亿美元损失。Scam Sniffer 的年度报告显示，EVM 钱包 drainer 钓鱼在 2024 年造成约 4.94 亿美元损失，2025 年回落至约 8,400 万美元。这些损失并不只来自某一个项目，而是来自现有账户和资产授权范式中可复用、可伪装、可长期残留的权限。

另一类常见体验是先存入平台再使用：交易平台、借贷池、金库、订单簿或托管合约先接收用户资产，然后在平台内部记账、撮合、结算或清算。这简化了应用逻辑，但用户的资产边界从自己的钱包转移到了平台合约。这同样不是抽象风险：Chainalysis 统计 2024 年 crypto platforms 被盗约 22 亿美元，DeFi 在一季度仍是最大被盗资产来源，中心化服务在二、三季度成为主要目标；2025 年上半年，cryptocurrency services 被盗已超过 21.7 亿美元，其中 Bybit 单一事件约 15 亿美元。TRM Labs 也估算 2024 年 hacks and exploits 造成约 22 亿美元损失，三年合计超过 77 亿美元。平台存入模型把多个用户的资产集中到同一服务、合约或密钥体系中，一旦业务逻辑、访问控制、私钥管理或跨链组件失守，损失会被集中放大。

• 优点：模型简单，组合性强，当前 DeFi 和 NFT 市场大量依赖它启动。
• 代价：授权是持久状态，交易结束后授权额度或操作员授权仍可能存在。
• 代价：授权对象是支出方或操作员，不是一次具体业务动作。
• 代价：approve + execute 通常是两笔交易和两次钱包确认。
• 代价：平台存入模型让资产可用性和退出路径依赖平台逻辑。

传统 DeFi 中，用户地址主要是签名主体，状态和权限通常留在外部协议里：token allowance、NFT operator、池子、金库、订单和平台余额。

1Do 把运行时放回用户地址。`executeRuntimeApp(app, data)` 通过 delegatecall 让应用逻辑进入用户账户执行帧；`enabledApps`、nonce 和应用状态使用命名空间存储，临时资产拉取则只存在于一次执行窗口。

• 传统 DeFi：协议是状态中心，用户账户多是签名入口。
• 1Do：用户地址是状态和运行时中心，应用更像可插拔逻辑。

账户本身就是应用的运行时

1Do 的核心判断是：钱包地址本身才是真正的应用执行边界。主线账户模型基于 ERC-7702，用户连接的地址就是运行时工作地址；用户不需要把资产迁移到第二个智能钱包地址，也不需要通过铸造 NFT 或启用资产管理中间层来使用运行时应用。

1Do Core 是当前统一产品入口，用来连接钱包、进入运行时应用，并打开 Dex、NFT Market、Flash Loan、Will、Session Pay 等账户能力。Core 是用户体验入口，运行时是账户执行边界；测试资产水龙头属于测试网辅助工具，不属于钱包运行时能力本身。

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

运行时通过 ERC-8280 风格的 executeRuntimeApp(app, data) 进入应用执行，并通过本地 enableApp / disableApp 管理某个地址允许哪些应用在自己的钱包运行时中执行。全局平台门控与用户本地启用是两个不同问题；当前 Core 运行时的可执行性可以概括为：

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

• ERC-7702：让 EOA 地址获得合约执行能力，用户不需要把资产迁移到新的智能钱包地址。
• ERC-8280：定义最小运行时应用宿主接口，executeRuntimeApp 是无需许可的触发入口。
• ERC-1271：让运行时钱包验证 EIP-712 意图、订单、支付授权和遗产计划。
• ERC-7201：用命名空间存储隔离宿主状态与应用状态，降低存储冲突风险。
• ERC-165：让前端、中继者和应用可以发现运行时、资产拉取、签名转账等能力。

1Do 当前兼容 ERC-20 / ERC-721，因为它们仍是主流资产接口。但在合约钱包环境中，资产合约不需要承载所有用户权限。资产合约应该更像余额和归属账本，账户运行时表达用户授权、组合、会话、资产拉取和清晰签名。

ERC-7196 / ERC-7561 代表更小的 token / NFT 方向：ERC-7196 移除 ERC-20 里的 transferFrom、approve、allowance；ERC-7561 移除 ERC-721 里的 approve、setApprovalForAll、getApproved、isApprovedForAll、safeTransferFrom，把用户级权限从资产合约上移到合约钱包。

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

在当前兼容路径里，1Do 用 ERC-8284 / ERC-8285 替代长期代币授权额度和 NFT 操作员授权，把资产拉取约束在一次执行窗口中。

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

• 代币拉取绑定目标合约、资产和剩余额度，累计不能超过上限。
• NFT 拉取绑定目标合约、资产和 tokenId，只授权一个目标合约在一次执行中拉取一个具体 NFT。
• 执行成功或回滚前必须清除上下文，执行窗口结束后任何拉取都必须失败。
• 结果是不留下可复用授权额度或操作员授权。

1Do Core 中的运行时应用不是把用户资产搬到新的平台账户里，而是在用户自己的钱包运行时中完成业务执行。每个应用保留自己的业务模型，但结算、签名验证、资产授权和执行边界回到同一个账户运行时。

• Dex：挂单方链下签署 EIP-712 订单，吃单方在自己的 7702 运行时中一次成交；相比 approve -> swap，Dex 不要求长期代币授权额度，也不要求用户把资产预存到交易平台。
• NFT Market：订单和市场规则由市场应用表达，NFT 或支付资产结算走钱包原生拉取；相比 setApprovalForAll，用户不需要把整个 NFT 集合长期授权给市场或聚合器。
• Flash Loan：把钱包中已启用的余额变成可组合流动性；流动性仍处在用户账户边界内，执行由运行时约束。
• Will：遗产计划保存在用户自己的账户语义内，资产在触发前仍留在钱包地址；执行人只能按计划和运行时规则处理尚未分发的资产。
• Session Pay：适合 API、AI agent、订阅和高频微支付；用户先签会话授权，后续结算授权按限额、周期和累计金额执行，不需要每次请求都重新签完整付款。

这些应用的共同优势不是某个单点 gas 数字，而是减少迁移、减少长期授权、减少平台余额、减少重复签名，并让用户始终围绕同一个账户边界理解风险。

支付不应该只依赖代币合约自己实现 permit，也不应该要求每个支付应用维护一套长期授权额度。1Do 把支付能力放在钱包运行时：一次性转账可以走钱包级结构化数据签名，持续或高频支付可以走 Session Pay 的会话授权与运行时应用结算。

ERC-8112 / ERC-8114 对应钱包级代币 / NFT 签名转移，适合一次性或中继转账。签名域绑定钱包地址，nonce 按资产与目标维度隔离，避免把每个代币合约改造成免 gas 授权系统。

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：代币和原生资产的签名转账放在钱包层，tokenTransferWithSig 校验 EIP-712 + ERC-1271 后转账。
• ERC-8114：NFT 的签名转移放在钱包层，nftTransferWithSig 验签后执行 safeTransferFrom。
• Session Pay 是独立运行时应用：用户签会话授权，会话密钥产生累计结算授权，并通过 Session Pay 自身运行时结算路径执行，不依赖 IERC8112。
• x402 可以作为 HTTP 接入方式：一次性付款映射到 ERC-8112；会话化付款映射到 Session Pay 会话结算。

1. 用户打开 1Do Core 或 1Do Wallet，连接当前地址。
2. 如果地址尚未激活运行时，先完成 ERC-7702 运行时激活。
3. 用户在 1Do Core 中打开 Dex、NFT Market、Flash Loan、Will、Session Pay 等运行时应用。
4. 用户对某个应用执行本地 enableApp；平台注册表仍独立控制全局可执行性。
5. 用户进入应用，签署 EIP-712 意图、订单、会话授权、遗产计划或转移授权。
6. 交易通过 executeRuntimeApp(...)、executeWithTokenPull(...)、tokenTransferWithSig(...) 或应用自身结算路径执行。
7. 执行结束后，临时拉取上下文被清除；长期权限仍留在用户自己的钱包运行时边界内。

1Do 的安全模型不是假设所有应用都可信，而是把应用能做什么限制在用户自己的钱包运行时边界内。触发执行的人可以是中继者、交易对手、维护者或普通调用者，但触发者不会因此获得钱包所有者权限。

• 所有者权限与触发权限分离：任何人可以触发已启用应用，但不能冒充所有者签名或修改所有者权限。
• 本地启用与注册表门控分离：用户本地启用表达账户意愿，注册表表达平台全局可执行性。
• 签名验证收敛到钱包运行时：EIP-712 结构化数据通过 ERC-1271 在用户账户边界内验证。
• 嵌套运行时执行会被拒绝：应用不能制造新的运行时自调用帧来绕过执行锁和调用者纪律。

1Do 不声称所有风险都会消失。更清晰的运行时边界可以减少长期授权、平台托管余额和应用自建权限系统带来的风险，但不能替代应用审计、用户判断和清晰的钱包签名展示。

• 1Do 不保证每个运行时应用的业务逻辑无风险。
• 注册表门控不是用户判断的替代品。
• 钱包原生授权减少长期授权额度和操作员授权，但不消除钓鱼签名、错误收款地址或恶意前端风险。
• ERC-7702 可用性依赖链、钱包、RPC 和签名工具支持。
• 1Do 不要求今天的生态立即放弃 ERC-20 / ERC-721；长期资产标准方向与当前兼容路径可以并行。

传统 DeFi 的成本不只是链上 gas 数字，还包括用户交互次数、长期授权风险和失败恢复成本。1Do 优先减少重复授权、减少账户迁移、减少应用自建权限系统。

下面的 1Do 数字来自当前 Core 的 Forge gas 基准测试；传统路径侧为常见 gas limit 预算区间，实际值会随路由器、订单类型、资产冷热状态、链和调用数据变化。

场景                         传统路径 gas limit 预算              1Do 当前基准
Dex vs Uniswap               approve 50k-75k + swap 150k-220k    token/token 222,705
                             合计约 200k-295k，2 次确认          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
                             合计约 300k-550k，常见为 2 次确认

支付 vs USDC 自带授权        EIP-3009 / transferWithAuthorization ERC-8112 首笔 70,425
                             常见预算约 80k-110k                 同 asset/to 第二笔 16,869

因此 1Do 的 gas 优化不是单点追求某个操作码更省，而是减少需要上链的步骤和残留状态：少一次 approve，少一次平台存入，少一个平台余额，少一个长期操作员授权，就少一个 gas、风险和用户理解成本的来源。

1Do 不是要把钱包做成一个庞大的中心化应用框架，而是要把账户能力稳定地收敛到用户地址本身。

宏观上，1Do 希望用户激活一次账户运行时，就能持续扩展 DeFi、支付、NFT、遗产、会话与未来应用。工程上，1Do 用 ERC-7702、ERC-8280、ERC-8284、ERC-8285、ERC-8112、ERC-8114、ERC-1271、EIP-712 等标准，把执行边界、签名、资产授权和应用启用状态放回钱包。

• 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