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-0013: Peer-scoped Deal Link Hosting and Store Authority→Draft; proposes Peer-scoped seller administration, optional hosted account association, and a bounded Hosting-to-Node authority split for Deal Links.RFC-0014: Quote-bound Cross-currency Payment Attempt Authorization→Draft; specifies a buyer-proposed funding basis that the seller checks against a fresh local rate floor and authorizes by signing the exact basis hash with the attempt terms.RFC-0015: Marketplace Operator Commission→Draft; proposes an operator-set, release-snapshotted, seller-visible commission on marketplace-attributed orders, phased from a hosted estimate ledger to seller-funded settlement outputs under the RFC-0007 model.RFC-0016: Peer Handle Naming, Resolution, and Portability→Draft; proposes one human-readable network handle per Peer, direct default-store routing, signed claim and lifecycle governance, and portability without replacing Peer-scoped business authority.RFC template→Required metadata and review questions.Repository RFC guide→