Tokenized Promise：现实世界的可编程承诺

每年，都有数十亿美元的资金基于承诺流动。投资者承诺投资给创始人。创始人承诺实现里程碑。顾问承诺进行引荐。员工承诺遵循归属计划。

但每年，这些承诺都会被打破——不是因为人们不诚实，而是因为纸质协议是静态的，执行成本高昂，且追踪方式是手动的。

Tokenized Promise 改变了这一现状。

传统协议的问题

以典型的 SAFE（未来股权简单协议）为例：

投资者汇款
创始人承诺达到里程碑
数月过去
他们是否达到了里程碑？谁来决定？如果他们没有达到会发生什么？

答案存在于电子邮件、电子表格、季度更新中，最终存在于律师那里。

对于投资者：没有自动追踪。没有客观触发器。纠纷成本高昂且会破坏关系。

对于创始人：持续的报告负担。投资者的焦虑会产生摩擦。没有办法客观地证明业绩。

对于顾问：股权承诺从未兑现。当公司“忘记”握手协议时，没有筹码。

对于员工：归属时间表发生变化。悬崖条款被选择性地执行。退出事件不知何故没有触发承诺的内容。

模式是一致的：承诺已经做出，但执行依赖于善意和昂贵的法律行动。

什么是 Tokenized Promise？

Tokenized Promise 是一种具有三个核心属性的可编程承诺：

定义的条件：触发承诺的因素（里程碑、日期、指标）
自动验证：我们如何知道条件已满足
可执行的结果：触发时会发生什么（付款、股权释放等）

Tokenized Promise 不再是“我承诺当你达到 10 万美元 MRR 时支付你 5 万美元”，而是编码为：

IF mrr_verified >= 100000
AND verification_source IN [approved_oracles]
AND timestamp <= deadline
THEN release(funds, recipient, 50000)
ELSE IF timestamp > deadline
THEN return(funds, investor)

逻辑是明确的。执行是自动的。审计跟踪是永久的。

架构：两条路径，同一标准

我们正在构建 Tokenized Promise 作为一种开放标准，任何人都可以实施。在此基础上，我们正在构建一个丰富的 UX 层，使其对非技术用户可用。

但这里有一个关键的见解：并非每个人都想要（或可以使用）区块链基础设施。监管要求各不相同。技术能力也不同。因此，我们支持两种部署模式：

企业模式（托管后端）

适用于需要合规性、可审计性和控制权，而无需区块链复杂性的组织。

// Enterprise Tokenized Promise - Server-side
interface EnterprisePromise {
  id: string;
  parties: {
    promisor: Party;      // 承诺者
    beneficiary: Party;   // 履行承诺的受益人
    arbitrator?: Party;   // 可选的争议解决者
  };
  conditions: Condition[];
  escrow: {
    amount: number;
    currency: string;
    custodian: 'athanor' | 'bank' | 'custom';
  };
  verification: {
    type: 'oracle' | 'attestation' | 'multi-sig';
    sources: VerificationSource[];
    threshold: number;    // 必须同意的来源数量
  };
  dispute: {
    window: Duration;     // 触发后提出争议的时间
    resolution: 'arbitration' | 'mediation' | 'court';
    jurisdiction: string;
  };
  compliance: {
    kyc: boolean;
    aml: boolean;
    jurisdiction: string[];
    reportingRequirements: Report[];
  };
}

运作方式：

各方签署协议（数字签名，具有法律约束力）
资金保存在受监管的托管机构（银行账户或持牌托管人）
Athanor 通过集成的数据源监控各项条件
触发时，资金自动转移（在监管范围内）
完整的审计跟踪，用于合规性报告

最适合：

受监管的实体（基金、家族办公室）
需要特定司法管辖区的跨境交易
有合规性要求的组织
交易对手方没有加密基础设施的交易

自托管模式（智能合约）

适用于那些想要无需信任的执行的人——一旦部署，任何中介都无法阻止或修改承诺。

// Self-Custody Tokenized Promise - Solidity
contract TokenizedPromise {
    struct Promise {
        address promisor;
        address beneficiary;
        uint256 amount;
        bytes32 conditionHash;
        uint256 deadline;
        PromiseState state;
    }
    
    enum PromiseState { 
        Active, 
        Fulfilled, 
        Expired, 
        Disputed 
    }
    
    mapping(bytes32 => Promise) public promises;
    mapping(bytes32 => address[]) public oracles;
    
    event PromiseCreated(bytes32 indexed id, address promisor, address beneficiary);
    event ConditionMet(bytes32 indexed id, address oracle, bytes proof);
    event PromiseFulfilled(bytes32 indexed id, uint256 amount);
    event DisputeRaised(bytes32 indexed id, address challenger, string reason);
    
    function createPromise(
        address _beneficiary,
        bytes32 _conditionHash,
        uint256 _deadline,
        address[] calldata _oracles
    ) external payable returns (bytes32) {
        bytes32 id = keccak256(abi.encodePacked(
            msg.sender, 
            _beneficiary, 
            _conditionHash, 
            block.timestamp
        ));
        
        promises[id] = Promise({
            promisor: msg.sender,
            beneficiary: _beneficiary,
            amount: msg.value,
            conditionHash: _conditionHash,
            deadline: _deadline,
            state: PromiseState.Active
        });
        
        oracles[id] = _oracles;
        
        emit PromiseCreated(id, msg.sender, _beneficiary);
        return id;
    }
    
    function submitProof(
        bytes32 _promiseId, 
        bytes calldata _proof
    ) external {
        Promise storage p = promises[_promiseId];
        require(p.state == PromiseState.Active, "Promise not active");
        require(isApprovedOracle(_promiseId, msg.sender), "Not approved oracle");
        require(block.timestamp <= p.deadline, "Past deadline");
        
        // Verify proof matches condition
        require(verifyCondition(p.conditionHash, _proof), "Invalid proof");
        
        emit ConditionMet(_promiseId, msg.sender, _proof);
        
        // Check if threshold met for release
        if (oracleThresholdMet(_promiseId)) {
            _fulfillPromise(_promiseId);
        }
    }
    
    function _fulfillPromise(bytes32 _promiseId) internal {
        Promise storage p = promises[_promiseId];
        p.state = PromiseState.Fulfilled;
        
        (bool sent, ) = p.beneficiary.call{value: p.amount}("");
        require(sent, "Transfer failed");
        
        emit PromiseFulfilled(_promiseId, p.amount);
    }
    
    // ... dispute resolution, expiry handling, etc.
}

运作方式：

在链上创建包含编码条件的承诺
资金锁定在智能合约中（任何第三方都无法访问）
经批准的预言机在满足条件时提交证明
当达到阈值时，合约会自动释放资金
争议机制允许在定义的时间窗口内提出质疑

最适合：

加密原生各方
需要无信任执行的情况
没有地域限制的全球交易
最大程度的透明度和可审计性

验证层

两种模式共享相同的验证架构。这是 Tokenized Promise 变得有趣的地方。

预言机类型

type OracleType = 
  | 'financial'      // 收入、MRR、烧钱率（通过会计集成）
  | 'product'        // DAU、留存率、功能发布（通过分析）
  | 'legal'          // 公司注册、IP 文件、合规性（通过法律 API）
  | 'human'          // 专家证明、董事会批准
  | 'composite';     // 以上的组合

interface Oracle {
  id: string;
  type: OracleType;
  trustScore: number;           // 历史准确性
  attestationMethod: 'api' | 'signature' | 'multi-sig';
  disputeHistory: Dispute[];
}

// 示例：MRR 验证预言机
const mrrOracle: Oracle = {
  id: 'stripe-mrr-oracle',
  type: 'financial',
  trustScore: 0.99,
  attestationMethod: 'api',
  dataSource: {
    provider: 'stripe',
    endpoint: '/v1/subscription_metrics',
    authentication: 'oauth',
    refreshInterval: '24h'
  }
};

多源验证

对于高风险的承诺，单源验证是不够的：

const milestoneVerification = {
  condition: 'mrr_reaches_100k',
  
  // 需要 3 个来源中的 2 个同意
  threshold: 2,
  sources: [
    { oracle: 'stripe-mrr-oracle', weight: 1 },
    { oracle: 'quickbooks-revenue', weight: 1 },
    { oracle: 'cfo-attestation', weight: 1 }
  ],
  
  // 对微小差异的容忍度
  tolerance: {
    type: 'percentage',
    value: 0.05  // 允许 5% 的差异
  },
  
  // 出现分歧时会发生什么
  disagreementResolution: 'arbitration'
};

争议解决：安全网

即使有自动验证，也会发生争议。我们的多层解决系统可以处理这些问题：

第 1 层：自动解决

interface AutomatedResolution {
  trigger: 'oracle_disagreement' | 'deadline_ambiguity' | 'partial_fulfillment';
  
  rules: [
    {
      condition: 'variance < tolerance',
      action: 'accept_median_value'
    },
    {
      condition: 'one_oracle_offline',
      action: 'extend_deadline_24h'
    },
    {
      condition: 'partial_fulfillment > 80%',
      action: 'release_proportional'
    }
  ];
}

第 2 层：人工仲裁

当自动规则无法解决问题时：

interface ArbitrationProcess {
  arbitrators: {
    pool: 'athanor_certified' | 'jams' | 'custom';
    selection: 'random' | 'mutual_agreement' | 'rotating';
    count: 1 | 3 | 5;  // 奇数代表多数
  };
  
  process: {
    submissionWindow: '7d';
    responseWindow: '7d';
    deliberationWindow: '14d';
    appealable: boolean;
  };
  
  costs: {
    filing: number;
    arbitratorFee: number;
    allocation: 'loser_pays' | 'split' | 'proportional';
  };
}

第 3 层：法律升级

对于需要法院干预的案件：

interface LegalEscalation {
  jurisdiction: string;
  governingLaw: string;
  venue: string;
  
  // 自动生成的证据包
  evidenceBundle: {
    originalAgreement: Document;
    transactionHistory: Transaction[];
    oracleAttestations: Attestation[];
    communicationLog: Message[];
    disputeRecord: DisputeRecord;
  };
}

真实世界的用例

1. 基于里程碑的投资

痛点：投资者希望分期提供资金，与里程碑挂钩。目前需要手动跟踪、季度电话会议，并信任创始人会如实报告。

const seriesAMilestones = {
  totalCommitment: 2_000_000,
  tranches: [
    {
      amount: 500_000,
      condition: 'signing',
      verification: 'legal_oracle'
    },
    {
      amount: 500_000,
      condition: 'mrr >= 50000',
      verification: ['stripe_oracle', 'cfo_attestation'],
      deadline: '2026-06-30'
    },
    {
      amount: 500_000,
      condition: 'team_size >= 10 AND product_launched',
      verification: ['hr_oracle', 'product_oracle'],
      deadline: '2026-12-31'
    },
    {
      amount: 500_000,
      condition: 'mrr >= 200000',
      verification: ['stripe_oracle', 'auditor_attestation'],
      deadline: '2027-06-30'
    }
  ]
};

结果：投资者确信里程碑会得到客观跟踪。创始人拥有明确的目标，资金会自动释放。不再有季度“我们到了吗？”的电话。

2. 有约束力的顾问股权

痛点：顾问承诺进行 0.5% 的引荐。公司发展壮大，“忘记”了交易，顾问没有筹码。

const advisorAgreement = {
  equity: {
    amount: 0.005,  // 0.5%
    type: 'options',
    vestingSchedule: 'milestone'
  },
  milestones: [
    {
      description: '3 qualified investor intros',
      verification: {
        type: 'multi_attestation',
        required: ['advisor', 'founder', 'investor']
      },
      equity_release: 0.002
    },
    {
      description: 'Series A closed with intro investor',
      verification: {
        type: 'legal_oracle',
        document: 'series_a_closing_docs'
      },
      equity_release: 0.003
    }
  ],
  dispute: {
    resolution: 'arbitration',
    evidence: 'email_trail_required'
  }
};

结果：顾问拥有协议的加密证明。里程碑由多方验证。不存在“他说，她说”。

3. 收入分成协议

痛点：内容创作者与平台达成收入分成协议。平台报告任何他们想报告的内容。创作者没有审计权。

const revenueShare = {
  parties: {
    creator: 'creator_wallet_or_account',
    platform: 'platform_entity'
  },
  terms: {
    percentage: 0.30,  // 30% 给创建者
    metric: 'net_revenue_from_content',
    paymentFrequency: 'monthly'
  },
  verification: {
    primary: 'platform_analytics_api',
    secondary: 'third_party_audit_quarterly',
    discrepancyThreshold: 0.10  // 10% 触发审计
  },
  payment: {
    automatic: true,
    currency: 'usd',
    method: 'bank_transfer'  // 或者在自托管模式下使用 'crypto'
  }
};

结果：创作者获得与经过验证的指标挂钩的自动付款。平台不能少报。争议会触发自动审计。

4. 具有客观触发器的员工股权归属

痛点：员工拥有 4 年股权归属计划和“善意离职”条款。公司在方便的时候决定“善意”的含义。

const vestingSchedule = {
  grant: {
    shares: 10000,
    type: 'iso',
    grantDate: '2026-01-15'
  },
  vesting: {
    cliff: '1y',
    schedule: 'monthly_after_cliff',
    totalPeriod: '4y'
  },
  acceleration: [
    {
      trigger: 'acquisition',
      verification: 'legal_oracle',
      acceleration: 'double_trigger'  // 也需要终止合同
    },
    {
      trigger: 'termination_without_cause',
      verification: ['hr_system', 'legal_review'],
      acceleration: '6_months'
    }
  ],
  goodLeaver: {
    definition: 'explicit',  // 不是“由董事会酌处”
    conditions: [
      'resignation_with_notice',
      'termination_without_cause',
      'disability',
      'death'
    ],
    verification: 'hr_oracle_plus_attestation'
  }
};

结果：员工清楚地知道是什么触发了什么。不再有“董事会酌处权”的意外。当条件验证时，加速是自动的。

内置合规性

Tokenized Promise 专为受监管的世界而设计：

KYC/AML 集成

const complianceLayer = {
  kyc: {
    required: true,
    provider: 'jumio' | 'onfido' | 'custom',
    level: 'basic' | 'enhanced',
    reVerification: '12_months'
  },
  aml: {
    screening: 'chainalysis' | 'elliptic' | 'custom',
    ongoingMonitoring: true,
    thresholdReporting: {
      amount: 10000,
      currency: 'usd',
      reportTo: ['fincen', 'local_regulator']
    }
  },
  accreditation: {
    required: true,  // 对于与证券相关的承诺
    verification: 'verify_investor' | 'manual',
    reVerification: '90_days'
  }
};

具有司法管辖区意识的执行

const jurisdictionRules = {
  'US': {
    securitiesLaw: 'reg_d_506c',
    escrowRequirements: 'qualified_custodian',
    reportingRequirements: ['form_d', 'blue_sky']
  },
  'EU': {
    securitiesLaw: 'mifid_ii',
    escrowRequirements: 'emi_or_bank',
    reportingRequirements: ['esma_reporting']
  },
  'CRYPTO_NATIVE': {
    securitiesLaw: 'token_not_security_opinion',
    escrowRequirements: 'smart_contract',
    reportingRequirements: ['on_chain_transparency']
  }
};

路线图

2026 年：塑造和验证

今年旨在确保基础正确：

Q1-Q2：通过 2 个正在运行的 Tokenized Promise 启动（真实的交易对手，真实的利益）
Q2-Q3：开源标准规范
Q3-Q4：根据早期采用者的反馈实施企业和自托管模式
持续：迭代验证预言机、争议解决、用户体验

我们不是在真空中构建。每个功能的发布都是因为真实用户有此需求。

2027 年：成熟和扩展

明年旨在扩大影响范围：

完善预言机网络（更多数据源、更高的信任分数）
扩展争议解决（经过认证的仲裁员网络）
扩大司法管辖区覆盖范围
启动 Tokenized Promise 模板市场
启用可组合性（触发其他承诺的承诺）

闭环

以下是愿景：Athanor 上的每一项承诺都将成为 Tokenized Promise。

创始人提交想法 → 通过 TP 承诺里程碑
投资者提供资金 → 通过 TP 释放分期付款
顾问加入 → 通过 TP 归属股权
雇佣员工→通过 TP 跟踪归属情况

每一个承诺都经过验证。每一项结果都经过跟踪。每一项争议都可以解决。

不是因为我们不信任人们——而是因为明确的承诺使信任更容易。

参与其中

我们正在积极寻找：

早期采用者：愿意将真实的交易构建为 Tokenized Promise 的投资者和创始人。我们将与您密切合作进行实施。

法律合作伙伴：有兴趣开发特定司法管辖区的模板和意见的公司。

技术贡献者：该标准将是开源的。帮助我们正确构建它。