CurrentUnderstand · Guide
Requests for Comment
Find or start a public proposal without presenting Draft design direction as accepted or shipped behavior.
Open the RFC registryEstimated time5 minutes
Trust, applicability, and sourcesCurrent public project policy or service surface
When an RFC is required
- A public protocol or interoperability contract changes.
- Order, payment, settlement, dispute, identity, authorization, or custody boundaries change.
- A fee, recipient, reward, public fund, or economic policy changes.
- A new optional hosted dependency changes independent-operation assumptions.
- Governance, licensing, privacy, security, or cross-repository ownership changes materially.
Status model
- Draft: authoring is incomplete.
- Review: ready for public technical and product review.
- Accepted or Rejected: the decision is recorded with rationale.
- Withdrawn: the author no longer proposes the change.
- Superseded: another RFC replaces the proposal.
- Implemented: release evidence confirms that the accepted proposal shipped within a stated scope.
Current registry
RFC-0001: Founding whitepaper publication contract→Review; defines the evidence and approvals needed to advance the whitepaper.RFC-0002: Composable Extension Platform Model→Draft; separates domain, contract role, runtime, trust, lifecycle, and packaging while defining the target multi-runtime platform.RFC-0003: Composable Frontend Product Model→Draft; separates deployment, experience, channel, code inclusion, and effective capability so public and private distributions can assemble coherent products without product-name branching.RFC-0004: Deal Link Single-Level Attribution→Superseded by RFC-0007; retained as the earlier manual-review-only proposal.RFC-0005: Core-owned Resource Collateral Lifecycle→Draft; proposes a separate Core-owned collateral aggregate without merging collateral into Order Extension or order settlement state.RFC-0006: Payment Kernel, Rails, and Trusted Distribution Modules→Draft; proposes typed payment rails, reviewed module composition, contribution-level routing, and durable payment recovery boundaries.RFC-0007: Seller-funded Affiliate Attribution and Atomic Settlement→Draft; proposes seller-funded Affiliate outputs in the canonical order release without a second payout engine or commission balance.RFC-0008: Node Key Domains and Receiving Architecture→Draft; proposes separate Identity, Wallet, and Settlement domains, generic receiving destinations, and a production gate for order authorization keys.RFC-0009: Frozen Payment Attempt Settlement Terms→Draft; proposes freezing seller payout, platform and cancellation fees, Affiliate and moderator terms, escrow timeout, and dispute policy into the immutable payment attempt before a funding target is payable.RFC-0010: Guest Checkout Trust and Custody Model→Draft; proposes seller-custodied Guest Checkout, a strict per-chain closure gate, an order-scoped access credential, and buyer disclosure rules without introducing a separate Direct payment product.RFC-0011: Order Settlement Authorization Keys→Draft; proposes deterministic hardened attempt-scoped settlement keys for all order participants, Identity-signed public-key offers without private-key exposure, and moderator selectability gated on obtaining a valid offer before payment.RFC-0012: Embedded Wallet Buyer Settlement Keys and Onramp-Funded Attempts→Draft; proposes a buyer-vendor-custodied participant key class for moderated escrow, admits embedded-wallet providers as a reviewed trusted-module class, and defines onramp-funded attempts without changing the RFC-0010 guest-custodial default or the RFC-0011 Settlement-root key hierarchy.RFC template→Required metadata and review questions.Repository RFC guide→