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

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

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

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

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

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

Uniswap

Uniswap 通过 AMM、流动性池和路由器完成 ERC-20 兑换。它开放、可组合且不要求用户预存平台余额，但在需要新授权的典型首次交互路径中，用户通常先发送 approve，再发送 swap；approve 是这两笔用户交易中的第一笔，占该路径交易次数和确认次数的一半，而不是全部 Uniswap 主网交易的占比。Permit2 和 Universal Router 改善了授权复用、签名和路由体验，但权限仍由外部 spender 模型承载。

OpenSea

OpenSea 等 NFT 市场通常让 NFT 在成交前留在用户地址，由用户签署挂牌或报价，再由市场合约在成交时转移 NFT 和支付资产。卖家可能需要先对单个 NFT 执行 approve，或通过 setApprovalForAll 授予整个藏品范围的操作员权限；使用 ERC-20 支付的一方也可能需要代币授权。订单本身可以链下签署，但资产转移权限仍可能长期留在 NFT 或代币合约中。

USDT 与 USDC

USDT 与 USDC 广泛用于链上支付和 DeFi 结算。支付场景需要清晰表达付款方、收款方、金额、币种、网络和有效期，并允许网站、API、Agent 或中继者可靠提交结算。USDT 具有广泛的流动性和多链覆盖；USDC 则提供较完整的开发者工具和可编程支付支持，常用于结账、免 Gas 支付、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 等稳定币付款。不过，EIP-3009 等能力是新版 USDC 等特定代币额外实现的功能，并不是 ERC-20 的通用组成部分；大部分 ERC-20 代币以及不同网络上的旧版或桥接资产并不支持相同接口。支付应用因此不能假设所有代币都具备签名转账、有效期和 nonce 等能力，通常仍要识别具体合约与网络，并为只支持基础 ERC-20 的资产保留 transfer 或 approve + transferFrom 路径。x402 统一的是支付请求和响应流程，也不会自动为底层代币补充这些合约功能。

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

上述模式支撑了 DeFi 的早期发展，但也把资产权限分散在 Token allowance、NFT operator、Router、Market、支付合约和托管平台中。交互成本首先体现在需要新授权的路径：approve + execute 是两笔交易，其中 approve 占该路径交易次数的一半。白皮书后文使用 2026 年上半年主网成功交易回执中位数比较 approve 与结算成本；这些 Gas 不完成 swap、挂牌或支付本身，只为后续执行建立权限。

公开数据已经足够说明规模。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 亿美元。平台存入模型把多个用户的资产集中到同一服务、合约或密钥体系中，一旦业务逻辑、访问控制、私钥管理或跨链组件失守，损失会被集中放大。

优点与代价

• 优点：模型简单、组合性强，适配没有代码和本地状态的 EOA 账户；当前 DeFi 和 NFT 市场大量依赖它启动。
• 代价：授权是持久状态，交易结束后 allowance 或 operator 授权仍可能存在；授权对象是支出方或操作员，而不是一次具体业务动作。
• 代价：approve + execute 通常意味着两笔交易和两次钱包确认，用户需要付出更多时间成本和 Gas 成本。
• 代价：平台预存模型让资产可用性和退出路径依赖平台逻辑，并集中业务逻辑、访问控制、私钥管理或跨链组件失效带来的风险。

状态模型差异

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

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

• 传统 DeFi：第一笔交易先在 Token 上写 allowance；第二笔交易才执行业务，allowance 可能继续存在。
• 1Do：一笔交易内设置本次可拉取金额，应用逻辑进入账户执行帧；交易结束后拉取记录清除，Token 不留下 allowance。

主图只比较两种最常见路径：传统 approve / execute 两笔交易，以及 1Do Token Pull 一笔交易。核心差异是：传统路径先留下 Token 授权状态，1Do 路径只在账户运行时里创建本次交易的拉取上下文。

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

1Do 的核心判断是：钱包地址本身才是真正的应用执行边界。主线账户可以是激活 ERC-7702 运行时的用户 EOA，也可以是已经具备运行时能力的智能合约账户；用户连接的地址就是运行时工作地址，不需要把资产迁移到第二个智能钱包地址，也不需要启用资产管理中间层来使用运行时应用。

DEX、NFT Market、Flash Loan、Will 等应用能力不要求用户迁移资产或进入新的平台账户；它们围绕同一个钱包运行时表达业务逻辑、签名验证和结算。测试资产水龙头属于测试网辅助工具，不属于钱包运行时能力本身。

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 管理某个地址允许哪些应用在自己的钱包运行时中执行。全局注册表门控与用户本地启用是两个不同问题；运行时应用的可执行性可以概括为：

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

• ERC-7702：让 EOA 地址获得合约执行能力；智能合约账户也可以直接承载同一类运行时边界。
• ERC-8280：定义最小运行时应用宿主接口。executeRuntimeApp 无需钱包所有者亲自发送交易即可被触发，但执行仍必须通过用户本地启用、全局注册表门控，以及应用自身的签名或状态校验。
• ERC-1271：让运行时钱包验证 EIP-712 意图、订单、支付授权和遗产计划。
• ERC-7201：用命名空间存储隔离宿主状态与应用状态，降低存储冲突风险。
• ERC-165：让前端、中继者和应用可以发现运行时、资产拉取、签名转账等能力。

一次性资产拉取

在 1Do 运行时及兼容资产拉取接口的执行路径中，一次性资产拉取可以替代独立的 approve 交易。用户不再需要先向 Token、Router 或 Market 单独发送 approve、setApprovalForAll，也不需要建立 allowance 或 operator 权限；ERC-8284 / ERC-8285 在同一笔业务交易中创建一次性拉取上下文、完成资产转移，并在执行结束后清除。

这不是在 approve 之上增加一层签名或复用授权，而是把资产授权从资产合约的持久状态整体上移到用户账户运行时。应用只获得当前目标、当前资产和当前额度或 tokenId 的执行权，不能把本次权限留到下一笔交易。

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

• 在兼容路径中替代独立 approve 交易：ERC-20 不再需要 approve / allowance，NFT 不再需要 approve / setApprovalForAll / operator 授权。
• 授权与业务执行合并为一笔交易，不再采用 approve + execute 两笔交易路径。
• 代币拉取绑定目标合约、资产和剩余额度，累计不能超过上限。
• NFT 拉取绑定目标合约、资产和 tokenId，只允许一个目标合约在一次执行中拉取一个具体 NFT。
• 执行成功或回滚前清除上下文；执行窗口结束后不留下任何可复用资产授权。

执行流程

1. 用户用当前地址连接钱包运行时；该地址可以是支持 ERC-7702 的 EOA，也可以是智能合约账户。
2. EOA 完成一次 ERC-7702 运行时激活后即可持续使用，直至用户主动撤销或更换运行时；智能合约账户则直接使用自身运行时能力。
3. 用户选择 DEX、NFT Market、Flash Loan、Will 等运行时应用。
4. 用户对某个应用执行本地 enableApp；平台注册表仍独立控制全局可执行性。
5. 用户进入应用，签署 EIP-712 意图、订单、遗产计划或转移授权。
6. 普通运行时操作通过 executeRuntimeApp(app, data) 进入；需要代币拉取时，付款账户调用 executeWithTokenPull(target, data, asset, maxAmount)。target 可以是运行时应用，也可以是兼容 tokenPullToCaller 的传统 DeFi 合约；目标合约在该调用中按需调用 tokenPullToCaller(asset, amount)。
7. 执行结束后，临时拉取上下文被清除，资产合约中不留下 allowance、operator 或其他可复用授权；钱包运行时只保留用户自行管理的应用启用状态。

最简单的代币不是要求用户立刻放弃 ERC-20 或 ERC-721。ERC-7196 / ERC-7561 延续 ERC-20 / ERC-721 的余额、归属和基础转移语义，并由钱包运行时补足授权与组合能力。1Do 应用层按同时适配现有 ERC-20 / ERC-721 与这些简化资产标准的方向设计，资产标准变化不应要求重写应用或迁移用户资产。

本节涉及的 1Do ERC 提案目前均按草案理解；接口和命名可能在评审过程中继续调整，实际集成应以对应提案仓库和部署版本为准。

这让 1Do 应用层能够覆盖更广的 Token 标准：资产合约负责余额和归属，账户运行时负责组合、资产拉取和清晰签名。

ERC-7196 / ERC-7561 代表更小的 Token / NFT 方向：ERC-7196 移除 ERC-20 里的 transferFrom、approve、allowance；ERC-7561 移除 ERC-721 里的 approve、setApprovalForAll、getApproved、isApprovedForAll、safeTransferFrom。

与简化资产标准配套，ERC-7204 / ERC-7564 在合约钱包中定义代币 / NFT 的转移、额度和操作员管理接口；ERC-8064 / ERC-8067 进一步提供基于 EIP-712、ERC-1271、作用域 nonce 与有效期的 Permit 扩展，让这些钱包级授权可以通过链下签名由中继者提交。

标准关系

• 资产层：ERC-7196 / ERC-7561 定义简化的代币与 NFT。
• 钱包资产管理层：ERC-7204 / ERC-7564 定义钱包级转移、额度和操作员管理。
• 签名授权与转移层：ERC-8064 / ERC-8067 用链下签名建立钱包级授权；ERC-8112 / ERC-8114 用链下签名执行一次明确的代币或 NFT 转移。
• 运行时执行层：ERC-8280 定义应用宿主；ERC-8284 / ERC-8285 让目标合约在单次执行窗口内按需拉取代币或 NFT。

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

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

ERC-8112 / ERC-8114 对应钱包级代币 / NFT 签名转移，适合一次性或中继转账。签名域绑定钱包地址，nonce 按资产与目标维度隔离；代币合约无需各自实现 permit 等签名授权逻辑，统一由钱包运行时完成验签与防重放。ERC-8112 标准能力面向 ERC-20，1Do 在此基础上扩展约定 asset == address(0) 表示原生资产。

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：标准定义钱包级 ERC-20 签名转移；1Do 扩展支持以 asset == address(0) 表示原生资产。tokenTransferWithSig 校验 EIP-712 + ERC-1271 后完成转账。
• ERC-8114：NFT 的签名转移放在钱包层，nftTransferWithSig 验签后执行 safeTransferFrom。
• x402 可以作为 HTTP 接入方式：一次性 ERC-20 付款可映射到 ERC-8112。

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

应用限制

运行时应用通过 delegatecall 在用户账户上下文中执行，因此必须隔离存储、限制嵌套执行，并经过代码审计与注册表门控。应用保留自己的业务状态机和结算规则，但不能绕过钱包核心权限，也不能把单次资产拉取变成可复用授权。详细工程约束见“技术附录：运行时应用约束”。

DEX

DEX 是链下签名订单与钱包结算的订单簿交易。做市方在链下签署价格、数量、有效期和 nonce 等订单条件，不必把 maker 订单长期写入链上；满足条件后，吃单方可以提交成交交易完成结算。当前基线路径以完整成交为主，使订单状态和结算结果更直接。

• 相对 AMM：价格和数量由订单明确表达，成交不依赖流动性池的曲线定价；适合双方按确定条件交换资产。
• 相对传统链上订单簿：订单签名可在链下传播或取消，只有成交或取消需要写链，减少挂单本身的链上状态。
• 相对 Uniswap 常见首次 ERC-20 交互：吃单方可在一次运行时交易内设置本次可拉取金额并完成结算，无需预先给 router 留长期 allowance。
• 相对托管交易平台：资产不进入平台余额；任何满足订单条件的地址都可以提交结算，资产只在成交时转移。

NFT Market

NFT Market 是面向 NFT 的链下签名订单簿，支持 NFT↔NFT 和 NFT↔Token 的撮合。订单在链下表达交易双方的资产、数量、有效期和其他条件；匹配成功后，在一笔交易中从双方钱包完成结算。NFT 和支付资产在成交前始终留在各自账户中。

• 相对传统 NFT 市场的常见首次授权路径：结算可围绕订单中的具体 NFT 和支付资产进行，不需要先对整个藏品做 setApprovalForAll。
• 相对长期 operator 授权：NFT 拉取绑定目标合约、NFT 合约和 tokenId，市场不能取得可复用的整套藏品转移权。
• 相对 NFT↔Token 市场：同一订单簿也可表达 NFT↔NFT 的直接交换，不必先把 NFT 换成代币再完成另一笔购买。
• 相对托管市场：订单、匹配和成交状态由市场应用处理，但双方资产不需要预先存入平台。

Session Pay

Session Pay 是面向 Agent、API 和订阅的会话式支付应用。用户只需用钱包签署一次有上限、有收款方和有效期的 SessionGrant；会话期间，session key 可以生成累计结算授权，由网站、Agent 或中继者提交，钱包无需为每笔小额付款重复弹出签名确认。

• 相对无限 allowance：权限只适用于指定收款方、资产、累计额度和有效期。
• 相对逐笔钱包签名：后续付款由独立 session key 授权，钱包所有者不必参与每次结算。
• 相对预充值账户：资金继续留在用户钱包中，只有有效授权被结算时才转给收款方。
• 相对简单自动扣款：链上记录累计已付金额，超限、过期、倒退累计值和已撤销会话都会失败。

遗产

Will 让用户在链下签署一份 ETH / ERC-20 加权遗嘱计划。计划包含受益人、权重、执行费、到期时间和触发方式；满足时间或失活条件后，任意执行者都可以提交计划，并把一个或多个尚未处理的资产直接分发给受益人。

• 相对传统实体遗嘱或托管方案：资产在触发前继续留在用户账户，不需要预先迁移给平台、律师、多签或遗产合约。
• 相对人工执行：受益人、权重、触发条件和执行费用由 EIP-712 签名计划固定，执行者不能自行改写分配规则。
• 相对简单时间锁：Will 可以使用时间触发，也可以结合心跳失活与宽限期，更贴近“用户活跃时继续自管、失联后才执行”的需求。
• 相对一次性全量分配：同一版本计划可以在多次交易中处理不同资产；已处理资产被记录，避免重复分发。重置计划会递增版本并使旧签名失效。

Flash Loan

Flash Loan 基于 EIP-3156。用户启用应用后，钱包中的 ERC-20 余额可以作为闪电贷流动性；借款、回调和归还在同一笔交易内完成，成功归还后费用按规则分配，其中属于钱包的部分记录为收益。

• 相对传统闪电贷池：流动性不必先存入一个独立资金池，钱包余额本身即可在应用启用后参与提供流动性。
• 相对普通借贷：闪电贷没有跨区块债务；借款人必须在同一交易的回调中归还本金和费用，否则整笔交易回滚。
• 相对单纯闲置余额：钱包所有者可在不迁移资产的前提下选择提供可组合流动性，并保留费用收益的归属。

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

executeRuntimeApp(app, data) 通过 delegatecall 让应用代码运行在用户账户的地址、余额和存储上下文中。错误的存储写入或调用边界会直接影响用户账户，因此运行时应用需要遵守以下约束：

• 持久状态使用 ERC-7201 命名空间存储，并通过 @custom:storage-location 标注存储根，避免与账户或其他应用发生存储冲突。
• 应用执行地址应指向可审计的直接逻辑实现，不以 Transparent、UUPS 或 Beacon 代理构造额外 delegatecall 链。
• 应用不得通过 address(this).call(...) 重新制造外部自调用帧，也不得嵌套 executeRuntimeApp；运行时使用执行锁拒绝嵌套或冲突执行。
• 应用可以拥有自己的状态机、事件、错误、定价和结算规则，但不得重复实现钱包自授权、应用启用状态或另一套钱包核心权限。
• ERC-8284 / ERC-8285 的资产拉取仅在当前调用有效，并绑定 target、asset、额度或 tokenId；错误目标、错误资产、超额或嵌套拉取都会失败，调用结束后临时上下文被清除。

安全边界

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

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

治理与恢复

用户可以通过 disableApp 撤销本地应用启用状态；ERC-7702 EOA 也可以主动撤销或替换运行时代码。平台级注册表用于阻止未登记或已下线的应用继续执行。在实际部署中，注册表管理员、升级方式、紧急下线流程、审计记录和恢复方案需要公开，使用户能够判断平台门控的信任边界。

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

费用与效率

1Do 优化的不是单个操作码，而是完整交互路径：减少 approve、平台存入、重复确认和长期授权残留。下面保留三类代表性费用基准；外部协议结算、approve 与 USDC 支付数据采用 2026 年上半年主网成功交易回执中位数，1Do DEX / NFT 与 ERC-8112 展示本地完整交易中位数及范围。受复杂交易和高 Gas 长尾样本影响，本组外部协议结算样本的平均数比中位数高约 25%–74%，因此本文使用中位数描述典型主网交易成本。

可扩展性

1Do 的扩展性来自账户运行时和应用逻辑的分离：账户保持同一个地址和资产边界，应用作为可启用、可禁用、可发现的运行时逻辑进入账户执行帧。新应用不需要要求用户迁移资产，也不需要每个应用都重新建立一套长期授权系统。

• 应用扩展：新增应用可以围绕同一个账户运行时接入，而不是为每个应用创建新的资产账户。
• 资产扩展：应用层按兼容 ERC-20 / ERC-721 的方向设计，并可继续接入更小的 Token / NFT 标准。
• 前端和中继扩展：ERC-165、注册表和本地 enableApp 让应用能力更容易发现和门控。
• 生态扩展：1Do 不要求外部 DeFi 立即改造；现有资产标准、兼容 Pull 路径和未来更小资产标准可以并行。

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

宏观上，1Do 希望用户激活一次账户运行时，就能持续扩展 DeFi、支付、NFT、遗产与未来应用。

工程基础采用既有标准：ERC-7702 提供 EOA 账户运行时能力，ERC-1271 与 EIP-712 用于合约账户签名和结构化意图，x402 作为 HTTP 支付接入方式，ERC-7201（钻石/命名空间存储）隔离账户与应用的持久状态。

在应用层，ERC-8112 处理一次性签名支付，Session Pay 则展示同一运行时如何承载有收款方、有资产、有累计上限、有期限且可撤销的持续支付会话，为 Agent、API 与订阅提供无需逐笔唤起钱包的结算方式。

1Do 发起的 ERC 草案按四层形成完整体系：

• 资产层：ERC-7196 / ERC-7561 定义面向合约钱包的简化代币与 NFT。
• 钱包资产管理层：ERC-7204 / ERC-7564 定义钱包级代币与 NFT 管理；ERC-8064 / ERC-8067 增加链下签名 Permit。
• 签名转移层：ERC-8112 / ERC-8114 定义钱包级 ERC-20 代币与 NFT 签名转移；1Do 在 ERC-8112 标准能力上扩展原生资产转移。
• 运行时执行层：ERC-8280 定义应用宿主与本地启用接口；ERC-8284 / ERC-8285 定义单次执行窗口内、目标绑定的代币与 NFT 拉取。

这些草案分别处理资产表达、钱包级管理、签名授权、一次性转移和运行时执行，并把用户可理解的权限与结算边界收敛到钱包运行时。

• 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 数据集：https://cloud.google.com/blockchain-analytics/docs/supported-datasets
• Google BigQuery crypto_ethereum 公共数据集：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