RWAIX proposes a universal trust and transaction protocol built on NFTs and blockchain for digital
commerce involving people, institutions, AI Agents, digital assets and physical devices. The protocol
connects participant qualifications, transaction intent, contractual rights, performance evidence,
acceptance, authorized settlement and dispute handling into a reviewable collaboration process, allowing
different organizations to exchange records with explicit meaning for the same transaction. The
company’s disclosed NFT business is the first planned implementation use case, connecting work and token
bindings, rights and licences, orders, delivery acceptance and authorized payment. Compute facilities
and other industry applications are subsequent extensions. This implementation sequence does not mean
that the protocol is already deployed in production on the company’s platform.
This whitepaper proposes a transaction reference specification for industry adoption, defining shared
semantics, core constraints, role‑specific conformance and a validation path. Sections 4 to 5 set out
proposed normative requirements; the other sections explain technical implementation, dual‑token
collaboration and application designs. Section 24 proposes a process for open evolution. Its current
status is a proposed reference specification for implementation and review, rather than an industry
standard adopted by a standards organization or validated across institutions. Existing company
components and new development are disclosed separately in Section 23. Frozen machine‑readable schemas,
test packages and interoperability results are conditions for subsequent releases.
The dual‑token design provides an economic profile with distinct functions for the transaction network.
DCNFT records series‑specific interests defined by contract for an identified facility SPV; $RWAIX is
proposed for approved network fees, operator performance bonding, service incentives and limited
parameter governance. Ordinary transaction objects, identity credentials, facility investment interests
and the network token are modeled separately and connected through business identifiers and independent
ledgers. General participants can verify or use services without being required to hold investment
interests merely because they adopt this specification. Each economic module is enabled only when its
own conditions are met. An ordinary NFT or TrustObject does not by default confer investment, copyright
or income rights. The proposed first NFT pilot may use approved fiat arrangements and existing records
without issuing or buying any new token.
Section 25 provides sourced industry context and an adjustable technical‑service billing model. Section
17 establishes the proposed initial implementation sequence through the company NFT transaction path.
Section 26 provides an eight‑scenario browser reference prototype with NFT transactions as the default
entry point. The prototype makes transaction commitments, evidence checks, separate acceptance and
settlement across distinct ledgers observable. Implemented scope, recorded tests and outstanding
production requirements are disclosed separately; they do not establish production deployment on the
company’s platform, industry‑standard status or full conformance certification.
1 The Technical Proposition for Future Digital Collaboration
The protocol addresses an evolving scenario in which digital systems progressively take on resource
discovery, qualification checks, negotiation of terms, service invocation and task execution.
Participants include people, businesses, devices and software agents with varying degrees of autonomy.
As collaboration expands, systems need to establish who may make a commitment, whether evidence remains
valid, whether an operation exceeds its authority and who handles errors. RWAIX designs shared
interfaces around these questions.
The principle that everyone can establish trust and participate means that everyone has the opportunity,
under public rules, to establish identity relationships, demonstrate specific qualifications or conduct,
and collaborate while protecting privacy. Trust conclusions are limited to a proposition, purpose, time
and set of dependencies; participants have routes to correction and appeal. The protocol does not
generate a universal score of character or social value, nor does it treat NFT ownership as permanent
proof of trustworthiness.
The universal trust core operates around four relationships: control between subjects and objects,
provenance between claims and evidence, authorization between rights and operations, and correspondence
between commitments and actual performance. NFTs provide typed object anchors; credentials and evidence
express verifiable content; contextual policies determine whether a particular request meets its
conditions; and independent executors constrain actual operations. Applications share these
relationships while retaining their own sources of facts and accountability rules.
The future value of the technology depends on whether this capacity for collaboration remains consistent
across applications: individuals carry qualifications, businesses verify suppliers, creators grant
licences, Agents invoke services within limits, and devices provide evidence of maintenance and use.
Technical advancement is validated through independent reviewability, security, privacy,
interoperability and practical efficiency together. The company’s NFT transaction business provides the
first planned complete implementation path; compute and other use cases subsequently test the scope of
the same core.
The two instruments express specific project interests and network collaboration across applications
separately. DCNFT holders derive their rights from the applicable series documents; permissions to use
$RWAIX derive from approved network rules; qualifications and facts still require evidence verification.
Participants may choose to provide services, verify credentials or use applications without becoming
investors merely by participating in the universal trust network.
The commercial logic for industry use is to connect transaction commitments, performance facts and
transfers of value in ways that different systems can understand: who commits, to whom performance is
owed, what is delivered, when acceptance occurs, who may authorize payment and how errors are corrected
must all be explicit. The protocol's value is demonstrated through replaceable service providers,
portable evidence, accountable operations and measurable collaboration costs. A reference specification
can form the basis for shared industry rules only when independent parties can implement the same
version and recognize one another's results.
2 Proposed Technical Contributions and Existing Technologies
NFTs, digital signatures, decentralized identifiers, verifiable credentials, smart contracts and
cryptographic proofs already provide a substantial technical foundation. Using these components does not
itself establish originality. RWAIX's proposed contribution is to organize object identity, evidence
dependencies, contextual policies, state changes and authorized execution into a protocol whose
components can be verified together, and to test through different applications whether the same core is
genuinely reusable.
The protocol proposes five research hypotheses: typed NFT trust objects can reduce semantic ambiguity
across applications; a TrustReceipt carrying context and version information can be checked by
independent implementations; an evidence dependency graph can identify circular endorsements and
repeated counting of supporting evidence; credential lifecycle management and checks before execution
can limit erroneous authorization after revocation; and open application adapters can reduce the need to
modify core contracts when adding an industry. Section 22 sets out experimental design and
counterexample testing requirements for these hypotheses.
W3C DID and VC standards provide models for identifier control and verifiable claims; ERC‑721 and related
standards provide on‑chain object interfaces. EAS already provides schemas, on‑chain and off‑chain
attestations, references, revocation and optional resolver rules; Sign Protocol's public documentation
also positions it as a universal evidence layer. Building on these capabilities, RWAIX proposes explicit
contracts for contextual evaluation and execution. Any significant advantage must be tested against a
baseline that directly combines the existing components. Universal trust and evidence layers are
established areas of work; this whitepaper does not treat a combination of components or a name as
evidence of a global first. [S1–S5, S10–S11]
RWAIX uses the division of functions between DCNFT and $RWAIX as its proposed economic architecture,
without requiring a new public blockchain or newly invented cryptographic algorithms. Protocol
development first establishes evidence and permission mechanisms, then separately validates rights
registration, network charging and incentive modules. Where token issuance conditions have not been met,
service pilots can use other approved settlement methods. Any new cryptographic construction or
consensus mechanism should separately publish its security model, analysis and review materials.
The incremental hypothesis of the dual‑token design is that it can reduce the commingling of interests
and operating funds while allowing industry adapters to reuse common fee and incentive interfaces.
Validation should compare it with a single mixed‑purpose token, separately accounted systems and a
service baseline without token issuance, including the additional costs of contracts, quotes, liquidity
and administration. The number of tokens is not itself evidence of technical advancement.
The protocol proposes a hypothesis of consistent transaction semantics: given the same transaction terms,
authorizations, evidence snapshot and versions, independent implementations can produce compatible
states and reason codes and trace differences to explicit external dependencies. Validation covers
normal delivery, partial performance, revocation, disputes, unknown payment outcomes and subsequent
compensation. The objective is to reduce the cost of reinterpreting transaction meaning across
institutions.
Section 26 turns selected research propositions into an interactive browser reference prototype for
examining the relationships among fixed terms, signed evidence, authority and payment states. Executable
examples provide a reviewable starting point. Advantages over existing approaches remain subject to the
controlled comparisons and independent‑implementation validation specified in Section 22.
Existing Foundation
Existing Capabilities
Increment RWAIX Proposes to Test
NFT standards [S4–S7]
Object identification, holding and transfer; some configurations restrict transfer
Explicit typed relationships among subjects, control, rights and lifecycles
DID and VC [S1–S3]
Identifier control, claims, presentations and status representation
Consistent constraints on contextual policies, dependency snapshots and replayable
evaluation
EAS and Sign [S10–S11]
Addressable attestations, evidence schemas and related lifecycle capabilities
Adaptation across representations, explicit rejection of semantic loss and linkage to
independent execution authorization
Signatures and smart accounts [S8–S9, S12]
Contract signature verification, structured signatures and programmable account validation
Context‑specific permissions, shared budgets and state checks between verification and
execution
Industry systems and signed logs
Business processes, permissions, logs and industry sources of facts
Comparison of reuse across applications, verification portability, privacy and total cost
3 Protocol Architecture and Trust Domains
RWAIX consists of a universal trust core, shared services and industry adapters. The core defines
objects, credential references, evidence dependencies, policy versions, verification results and
lifecycles. Shared services provide key recovery, evidence storage, indexing, verification and dispute
handling. Industry adapters map specific business facts and contractual conditions into the core. Each
industry adapter must disclose the external facts that the core cannot determine.
The identity and control layer manages control keys and delegated authority for people, organizations,
devices and Agents. The NFT object layer provides stable anchors and explicit binding semantics for
managed objects. The evidence layer organizes credentials, observations and provenance. The policy layer
produces verification conclusions in a given context. The collaboration and execution layer advances
commitments or payments using valid authorizations. Governance and interoperability span these layers,
constraining versions, upgrades and messages across networks.
Figure 1. Shared trust core, NFT as the first planned application and seven extension domains
The chain stores only the minimum necessary object identifiers, version commitments, state roots and
execution events. Sensitive source documents, raw telemetry and large evidence sets are generally held
in controlled off‑chain storage. A hash demonstrates consistency between particular bytes and a
commitment; it does not establish that the content is true, that the data remains available or that an
issuer has legal authority. Network finality, evidence authenticity and resolution of commercial
disputes belong to different trust domains.
Verifiers may be operated by customers, partners or independent services. A common interface permits
replacement of a verification service, but the relying party remains responsible for selecting trust
roots, policies and dependencies. The core should support multiple implementations and exportable
evidence packages, avoiding merely wrapping a single centralized account database in a blockchain
interface.
The architecture adds a configurable dual‑token adapter layer. DCNFT connects issuance series, rights
documents and registers; $RWAIX connects fees, performance bonds, service incentives and limited
governance. Separate ledgers maintain objects and evidence, facility interests and cash, and network
fees and rewards, with linking identifiers for reconciliation. Adapters register an asset's network,
contract address, precision, controlling roles and version. Tokens with the same name or cross‑chain
representations must not be assumed to convey the same legal rights.
The commercial transaction layer uses common transaction identifiers, obligation identifiers and event
envelopes on top of this architecture, with industry adapters adding measurement, acceptance and legal
conditions. One business transaction may involve multiple objects, performing parties and payment
obligations. Evidence, contractual state and funds execution each retain their authoritative sources and
are reconciled through consistency rules. Platforms can be replaced, but established obligations and
historical evidence must not disappear when a system is migrated.
4 A Cross‑Industry Reference Specification for Commercial Transactions
This section defines a proposed transaction core for procurement, licensing, service delivery and other
collaboration with identifiable parties and obligations. It establishes common semantics for recording
and verification while preserving each industry's sources of facts, contractual arrangements and dispute
processes. Proof‑only processes and zero‑price services may declare that no payment obligation exists.
Financing, investment and electronic transferable documents still require separately defined rights and
applicable conditions.
In Sections 4 to 5, the uppercase terms MUST, MUST NOT, SHOULD and MAY express BCP 14 requirement levels:
mandatory, prohibited, recommended subject to a justified exception, and optional, respectively. The
uppercase keyword accompanying the Chinese text determines the requirement strength of this proposal;
ordinary explanatory text does not thereby become a conformance assertion. The rules constrain only
implementations claiming the corresponding version and role and do not give this proposal binding legal
or industry‑wide authority. [S22–S23]
4.1 Transaction Objects and Shared Semantics
N01 Versions and semantics. An implementation MUST pin protocolVersion, profileId,
profileVersion, schemaDigest, tradeId and termsDigest for a transaction. TradeEnvelope references the
parties and their roles, objects and units, obligations, acceptance rules, timing conditions, fee and
payment arrangements, applicable documents and dispute routes. Each obligation has a stable
obligationId. Changing the payment asset, chain or adapter for the same debt must not create an
additional right to payment. Amounts use explicit currency or asset identifiers, precision and rounding
rules; implicit units are prohibited.
N02 Parties and authority. An implementation MUST separately verify the basis for the
roles of transaction parties, signatories, service beneficiaries, payers, payees and verifiers, binding
authorityRef, scope of authority, validity period and revocation status. Wallet control, a platform
account, an Agent signature or token holdings alone cannot replace the required commercial authority. A
missing mandatory condition returns a denial or indeterminate result.
N03 Formation and amendment of terms. The system MUST record evidence that authorized
parties have consented to a specific termsDigest, together with the applicable conditions for
effectiveness. Quotes, orders, invoices and delivery acknowledgments retain their distinct business
meanings; an invoice alone does not establish that goods have been accepted. An amendment creates a new
version and obtains the required consent under the specified rules, preserving the prior version and its
outstanding obligations. The technical state COMMITTED means only that the commitment conditions
specified by the profile have been recorded. Contract formation and legal effect remain dependent on the
applicable facts and law. The UNCITRAL Model Law on Automated Contracting, adopted in 2024,
distinguishes attribution of a system's outputs or actions from their legal consequences. It provides a
model for legislation, rather than globally applicable contract rules. [S26]
4.2 Transaction Lifecycle and Multiple State Dimensions
N04 States and events. An implementation MUST bind each TradeEvent to eventId, tradeId,
obligationId, eventType, actor, authorityRef, streamId, sourceId, prevEventDigest, sequence, causalRefs,
effectiveAt, recordedAt, evidenceRefs and a signature domain. The schema must explicitly specify when an
obligation identifier is inapplicable. effectiveAt is the asserted effective time; recordedAt is the
time the system receives and records the event. They are not interchangeable. State reconciliation uses
the ordering, conflict rules and authority conditions fixed by the profile; the last message to arrive
must not overwrite a previously valid state merely because it arrived last. sequence and prevEventDigest
are scoped to the same signed event stream; causalRefs expresses dependencies across streams. State
reconciliation must validate event authority, expected versions and causality. The sequence numbers or
timestamps of individual parties must not be treated as a global event order.
Transactions maintain at least five separate dimensions: commitment, performance, payment execution,
receipt and discharge, and disputes. Repeated events are processed idempotently by business identifier,
out‑of‑order events remain pending reconciliation, and conflicts follow an explicit pause or review
path. Financing‑interest registration and network rewards are recorded separately. A successful chain
transaction updates only the corresponding execution fact; it must not simultaneously imply acceptance,
receipt of funds and resolution of a dispute.
State Dimension
Reference States
Facts Required for Transition
Commitment
PROPOSED COMMITTED AMENDED TERMINATED
Valid consent, authority and version; termination preserves existing outstanding obligations
CONFIRMED refers only to a reconciled execution effect on the specified payment rail; it
does not imply discharge
Receipt and discharge
UNRECONCILED PARTIALLY_APPLIED APPLIED
Receipt evidence, availability and reversal conditions, basis for discharge and attribution
to each obligation are recorded separately
Dispute
NONE OPEN RESOLVED REOPENED
Initiating party, scope, interim measures, basis of decision and routes to remedy
4.3 Delivery Acceptance and Separately Authorized Settlement
N05 Delivery and acceptance. An implementation MUST separately retain the delivery
claim, supporting evidence, verification receipt and the AcceptanceRecord of an authorized acceptance
party, fixing the object version, quantity, quality metrics, acceptance deadline and objection rules.
TrustReceipt establishes only the result of verification against specified rules. Automatic acceptance
requires prior agreement on its trigger conditions and authority; neither a lack of response nor a
successful on‑chain write may by itself constitute acceptance. Delivery in batches and partial
acceptance use separate obligations or explicitly defined subscopes. Partial acceptance uses a unique
portionId to bind its subscope, quantity and allocation to a payable. Repeated acceptance records for
the same delivery scope must not count quantities or create payables more than once.
N06 Separate funds execution. Payment MUST be triggered by effective payment terms and
current authority. Advance payments, installments and final payments due on acceptance each identify
their trigger conditions. For the same obligationId, discharged amounts, executed payments awaiting
attribution, and other pending payments that could still take effect are deduplicated under a unique
paymentAttemptId and assigned to mutually exclusive categories. Their total must not exceed the approved
payable amount. OUTCOME_UNKNOWN retains the reservation for reconciliation. Refunds, compensation and
reversals create new obligations or adjustment records referencing the original record and execute under
appropriate authority; they do not delete the original payment fact. Within the funds dimension, an
implementation MUST record paymentInstructionState, fundsReceiptState and obligationDischargeState
separately and retain the basis for each confirmation. CONFIRMED refers only to the confirmed execution
record. Receipt of funds, the amount discharged and reversibility are reconciled separately under the
contract, payment channel and applicable rules; chain confirmation must not replace those
determinations. Amounts confirmed on the payment rail but awaiting attribution of the received funds or
reconciliation of discharge continue to count against the original obligation's payment limit. Each
amount is assigned to one mutually exclusive state category under a unique paymentAttemptId; execution
confirmation must not release allowance before discharge is recorded. The amount counted against the
limit includes discharged amounts, executed payments awaiting attribution and other payments that could
still take effect. Their total must not exceed the approved payable amount.
DCNFT connects facility‑series rights documents and actual distributable cash; $RWAIX connects approved
network fees, bonds and rewards. Customer purchase payments, facility financing, network fees and node
rewards each have their own creditors and funding basis. The core transaction interface permits other
payment methods under lawful configurations. Asset transfers may be described as atomic exchanges only
within the same executable atomic boundary. Processes spanning chains, banks and physical delivery must
state their timing gaps, failure handling and compensation mechanisms rather than advertise end‑to‑end
risk‑free atomic settlement.
4.4 Dispute Remedies and Preservation of Records
N07 Disputes and remedies. An implementation MUST record in DisputeRecord the initiating
party, affected obligations and amounts, reasons, evidence deadlines and supplementation rules,
decision‑making authority, notices and routes to remedy. Pausing, releasing bonds, imposing penalties
and adjusting payments each require verification of authority. Separable undisputed obligations continue
under their own rules. Timeout handling requires an explicit basis agreed in advance; silence must not
automatically be interpreted as an admission of breach.
On‑chain technical finality, settlement confirmation and legal finality are recorded separately. RESOLVED
means only that the designated process has addressed the matter within its authority and scope; it does
not necessarily preclude objections, review or remedies under applicable law. A terminated or settled
transaction can still receive appended records arising from a valid dispute, correction of an error or a
decision of a competent authority. Corrections preserve the original evidence and complete reference
relationships. Electronic transferable records involve additional requirements concerning reliability,
integrity and control. An NFT identifier or on‑chain holding alone cannot establish their legal effect;
the relevant profile should be determined separately for the local legislation and specific document.
[S25] MLETR is a model law; its 2017 text excludes securities such as shares and bonds, and other
investment instruments. This protocol does not use it as a basis for DCNFT issuance, transfer or
legality.
N08 Data and recoverability. An implementation MUST limit collection and disclosure and
define evidence access, retention periods, handling of legally required deletion or preservation, and
recovery procedures. Public logs use necessary commitments and controlled references; avoidable
sensitive source content must not be written to them. A signature or hash does not ensure data
availability. When evidence needed for verification cannot be recovered, the system should report an
indeterminate or unverifiable result rather than represent it as valid proof.
5 Interoperability and Conformance Testing
Conformance claims are limited to a specific version, profile, role and module. Verifiers, executors,
industry adapters and economic modules have different responsibilities. Selecting an optional module
does not remove its dependent core requirements. DCNFT and $RWAIX form RWAIX's economic design; basic
transaction and evidence interoperability must not require token holdings or investment subscriptions by
default.
5.1 Role Scope and Version Negotiation
N09 Interoperability with Explicit Semantics. A receiving party MUST check both parties'
capability manifests, versions, critical extensions and semantic mappings. Unsupported required fields
or conditions must be explicitly rejected rather than silently discarded or automatically downgraded.
The behavior of optional extensions may be ignored, while the original signed content is retained under
the signature rules. Exchanges across industries must preserve roles, rights types, currencies and
units, acceptance conditions, dispute states and original provenance.
Verifiers are responsible for evidence, status and policy results; executors for current authority, funds
or operational boundaries, and reconciliation; industry adapters for mapping external facts and
identifying what they cannot guarantee; and economic modules for the relevant rights, fee, bond and
reward rules. An implementation may perform only one of these roles, but must declare functionality it
does not implement. A verification service's conformance report cannot substitute for conclusions about
an executor or asset issuer.
5.2 Rule Vectors and Reviewable Tests
N10 Evidence of conformance. An implementation claiming conformance to a frozen profile
of this proposal MUST provide a ConformanceManifest identifying specification and profile versions, a
code or build digest, roles, enabled modules, dependencies and trust roots, the test‑package version,
results and known limitations. MUST requirements cannot be recorded as passed through an exemption.
Deviations from SHOULD requirements must explain their reasons and interoperability impact. Modules not
yet implemented or tested are marked as unevaluated.
Test vectors fix inputs, authority and state snapshots, expected events and results, permitted side
effects and prohibited changes. The matrix below gives the minimum categories of negative tests. A
complete test package must also cover valid paths, interactions at boundaries, concurrency and recovery.
A conformance claim for a specified scope requires every applicable mandatory assertion in the same
frozen test set to pass; this does not establish the absence of unknown attacks. On‑site claims with
valid signatures but false content require industry sampling to assess false‑acceptance rates; format
tests alone cannot guarantee their detection.
Rule
Negative Test or Injected Failure
Required Observable Result
N01
Unauthorized change of currency, unit or terms digest
Ambiguous input rejected; no new obligation or debit created
N02
Agent exceeds authority or delegated authority has been revoked
Action with side effects rejected; reason code retained
N03
Old consent reused for changed transaction terms
New terms do not take effect; existing obligations and evidence of consent remain
N04
Duplicate, out‑of‑order or conflicting events
No duplicate state side effects; reconciliation or pause remains traceable
N05
Mismatched signature or digest, missing evidence or acceptance without authority
Invalid proof and unauthorized acceptance rejected; missing evidence returns an
indeterminate result
N06
Cross‑asset resubmission after an unknown payment outcome or an executed payment awaiting
attribution
Relevant amounts remain counted against the payment limit; no duplicate payment or premature
release
N07
Penalty without authority or a dispute affecting only part of the amount
Unauthorized disposition rejected; interim measures recorded for the affected scope
N08
Required evidence unavailable or disclosure requested for an unauthorized recipient
No affirmative conclusion without required evidence; unauthorized disclosure through
controlled interfaces blocked and logged
N09
Unknown critical extension or semantic loss
Explicit rejection; no fabricated compatibility through default values
N10
Untested module or false claim of comprehensive certification
Scope and gaps reported; no conformance claim beyond the tested scope
5.3 Exchange Across Implementations and Release Conditions
An interoperability candidate release SHOULD involve at least two independent implementation teams, each
completing transaction creation, evidence exchange, verification, state replay and recovery from
exceptions for the same transaction. Calling a shared backend does not constitute independent
implementation. Initial interoperability testing covers three profiles: NFT transactions; work
provenance and licensing; and institutional qualifications and Agent delegation, with fixed examples
involving mixed fees and partial failure. NFT transactions lead the sequence; compute and other
scenarios follow when their domain requirements are met. Three pilots cannot establish that every
scenario has been validated.
Release materials include implementable schemas and interfaces, profile and extension registries,
complete vectors, exportable event and evidence packages, known issues, discrepancy reports and
migration rules. Interface publication, specification licences, code licences and patent commitments are
disclosed separately. Unresolved ownership rights must not be described as an open licence.
Self‑declaration, independent assessment and adoption by a standards organization are different levels
of evidence; their reports cannot substitute for one another.
6 NFT Trust Objects and Binding Semantics
An NFT is an on‑chain anchor for a programmable trust object. Its object reference is determined jointly
by chainId, contractAddress, tokenId and bindingVersion; its description specifies meaning through
schemaId, contentDigest, controller, subjectBinding, rightsDescriptorRef and lifecyclePolicy. NFT
metadata updates create a new version and event; they must not silently change, within the same version,
the semantics on which past verification relied. Update rules are constrained by the selected standard:
metadata of an issued ERC‑5484 token must not be changed. Changes must instead follow the specified
burn‑and‑reissue process or use newly referenced credentials; bindingVersion cannot circumvent the
restriction. [S7]
Token holders, control keys, claim subjects, service beneficiaries and legal rights holders must be
distinguished. The holder record under ERC‑721 describes token‑level state; it does not automatically
establish a natural person's identity, copyright in a work or ownership of a physical asset. The
creation and transfer of legal rights depend on applicable documents, registrations and authority. The
protocol explicitly references these foundations rather than compressing different relationships into a
single owner field. [S4] A unique tokenId within one contract also cannot prevent another contract or
chain from describing the same physical object. Registration rules must identify known duplicates and
conflicts and specify authoritative sources and dispute handling.
Objects bound to a subject should use a configuration that prohibits ordinary transfers or permits only a
strictly controlled recovery process. Asset objects may be transferable under the applicable conditions;
transfer of a service commitment or substitution of its obligations requires the relevant parties'
consent. Historical evidence attached to a transferable asset does not establish the new holder's
personal qualifications. Every transfer requires reassessment of current dependencies and authority;
historical versions and their subject relationships at the time remain traceable.
A subject anchor should expose only necessary identifiers. Sensitive identities can use different
identifiers in different relationships, controlled mappings and selective disclosure. Public identity
NFTs may enable correlation across platforms, so no person should be required to mint a permanent public
real‑name record. A person may manage multiple identifiers for authorized purposes, and devices and
organizations may have independent objects. Counts of wallets or NFTs alone cannot establish the
uniqueness of natural persons.
TrustObject is a general object abstraction, while ordinary NFTs and credentials carry records according
to their respective meanings. DCNFT is a specialized category proposed for specified facility
contractual interests. Not every TrustObject, NFT or credential is DCNFT, and ordinary object records do
not by themselves create investment rights. Facility identity NFTs, personal qualifications, work
licences and device records continue to operate under their own types. Only rights created through
effective documents can change through a compliant transfer. The DCNFT issuer, seriesId,
rightsDocumentDigest, register reference, transfer conditions and registration time must be bound to the
object version, with separate audit trails for key recovery and corrections to rights records.
Object Profile
NFT Content
Transfer and Authority Constraints
Subject and control anchor
Binding and version for an organization, device or privacy‑protected subject
Ordinary transfer disabled or controlled; recovery validates the subject and authority and
cannot sell personal qualifications
Asset and work object
Object provenance, version and references to rights documents
Transfer within an explicit rights scope; token holding does not automatically transfer
copyright, title or income rights
Collaboration and service commitment
Parties, obligations, acceptance policies and evidence references
Transfer, subdelegation and substitution of obligations each receive the required
authorization
Optional regulated interest
References to applicable transaction documents and an authorized rights register
Separate issuance, transfer and holding conditions; isolated from general participation
accounts
7 Dual‑Token Collaboration and Economic Operations
The dual‑token design expresses interests in a specific facility separately from network collaboration
across applications, connecting them through the same evidence and authorization core. DCNFT is a
non‑fungible or series‑based representation of interests, proposed for contractual participation rights
in subsequent facility‑SPV deployments. $RWAIX is a proposed fungible network token for approved fees,
performance bonding, service incentives and limited governance. Dual‑token refers to two economic
functions; it does not mean that every service must use both instruments or that every NFT carries
investment rights.
The collaboration path runs from effective rights and service commitments through verifiable evidence,
approved fees or rewards, independent execution and ledger reconciliation. DCNFT and $RWAIX have no
default conversion, redemption, mutual guarantee or claim on each other's cash flows. Returns on
investment interests depend on the corresponding effective documents and funds actually available.
Network‑service continuity depends on deliverable services and customer demand; token appreciation must
not be treated as a foundational source of payment capacity.
Figure 2. Distinct dual‑token functions, rights documents and funds boundaries
Object or Asset
Function
Basis and Boundaries
General NFTs and credentials
Verifiable representations of subjects, objects, qualifications and licences
Verified by object type and valid evidence; not a third network payment token
DCNFT
Registration interface for series interests in an identified facility SPV
Series documents define the issuer, cash participation and transfer conditions; no automatic
ownership of physical assets or group equity
$RWAIX
Approved fees, performance bonds, service incentives and limited governance
Issuance and operating rules are determined separately; no attached DCNFT cash‑flow or
company‑equity rights
External settlement assets
Service payments and authorized funds settlement
Fiat or approved digital payment assets follow their respective rules; not additional
self‑issued tokens
7.1 Rights Binding and Authorized Transfers
Each DCNFT series binds the actual issuing SPV, rights‑document version, register, holder eligibility,
economic priority, term, default remedies and applicable transfer restrictions. The working assumption
remains contractual participation linked to facility distributable cash. The final choice of equity,
debt or another instrument must be reflected consistently in the schema and signed documents. An NFT
transfer produces the corresponding legal effect only when the applicable contractual, registration and
eligibility conditions are satisfied.
Token quantities held and distribution weights need not coincide. The distribution engine calculates
amounts using the record date, eligible register, weights, deductions and approved amount specified in
the series documents, retaining bank or custody receipt records, debt constraints and payment receipts.
The platform establishes no joint payment obligation across facilities, default group guarantee or
distribution ratio that can be rewritten by a $RWAIX vote. New allocations use eligible cash that has
not yet been allocated as their base. Amounts already allocated to investors and residual rights holders
in a prior period or the current period are excluded. If the base already excludes these amounts, they
are not deducted again; actual payments only discharge the corresponding payable entitlements.
7.2 Fee Quotes and Separately Accounted Settlement
Service charges and network fees are defined separately. FeeQuote binds quoteId, quoteUnit, feeAsset,
maxDebit, the payee, rateSource, rateTime, expiry and refundRule. A fee asset is uniquely identified by
network, contract and precision; fiat uses an explicit currency. When payment in $RWAIX is selected, the
quote specifies the conversion direction, responsibility for fees and permitted deviation. A stale,
abnormal or unavailable price source pauses that payment path rather than permitting an unapproved
increase in the debit or substitution of another asset. Acceptance of a quote fixes the settlement
quantity or specifies the conversion rule and maximum debit. Exceeding an approved deviation requires a
new quote and new authorization; previously consumed allowance must not be recalculated and released
because prices change.
Fee execution follows quote acceptance, allowance reservation, authorized submission, outcome
reconciliation and settlement or refund. OUTCOME_UNKNOWN retains the reservation while the original
transaction is queried. Facility funds, platform service fees, the network treasury, bonds and reward
budgets are accounted for separately. Service‑revenue deductions, debt and reserves are verified against
series documents and financial records before distributable cash is determined. Token market value,
unsold allocations and unconfirmed receivables are not cash received. The same service obligation shares
a unique obligationId across payment assets and is reconciled using a fixed basis for measuring
discharge. Discharged amounts, executed payments awaiting attribution, and other pending payments that
may still take effect are deduplicated under a unique paymentAttemptId and assigned to mutually
exclusive categories; their total must not exceed the approved payable amount. Execution confirmation
does not release coverage early. Changing the asset or transaction identifier does not create a new
payment right.
7.3 Performance Bonds and Service Incentives
Performance bonds use BondRecord to record the responsible party, obligation, bond asset, locked amount,
dispute window and authority to release or deduct funds. A bond supports performance obligations; it
does not establish factual truth or automatically bear facility debt. If the bond asset is $RWAIX, its
price and liquidity changes require stress testing. A shortfall limits new obligations or triggers
additional protection under predefined rules; it must not be shifted to existing rights holders without
authority.
RewardClaim binds a unique service, provider, verification result, amount and asset, and budget period.
It enters claimable and claimed states only after deduplication, conflict checks, the approved dispute
process and budget approval. Locking a bond does not itself produce a fixed return. Service compensation
and separately approved staking incentives are disclosed separately. Unapproved rewards, buybacks, burns
or APR are not presented as return commitments, and funds from new participants must not pay previously
guaranteed returns. Reward sources are identified separately as earned service fees, approved subsidies
or approved emissions. Amounts allocated but unclaimed, and amounts whose payment outcome is unknown,
continue to consume the cumulative budget. A timeout, address change or cross‑chain movement must not
release that budget or credit the reward again. Internal approval does not determine legal character or
establish issuance eligibility. Any reward, buyback, burn or staking arrangement still requires separate
review of its actual rights, funding sources, marketing and applicable rules.
7.4 Supply Governance and Sustainable Operations
The $RWAIX cap of 1,000,000,000 tokens and the allocation below are solely a candidate design budget, not
approved issuance or allocation. Amounts in the table are design ceilings. Sales, vesting and releases
do not begin until the issuer, legal holders, recipient conditions, distribution routes, release
schedules and final treatment of unearned allocations have been determined and approved. Team
allocations, liquidity‑wallet balances, unlocked amounts and actual circulating supply are disclosed
separately. Cross‑chain representations must not increase the unified economic supply. Ecosystem and
verification‑service rewards may cover contributions from NFT and other applications, including later
compute verification, under separately approved rules. The 40% category ceiling assigns no amount to a
particular scenario, node or participant, and repeated event counts do not substitute for eligible
services.
$RWAIX governance operates only within authorized parameter scopes, with rules for proposals,
eligibility, voting participation thresholds, conflicts, delayed execution and emergency protection.
Voting does not directly control SPV funds or unilaterally change DCNFT weights, priority, security or
remedies. Changes to supply, fee and reward parameters are constrained by the relevant legal entity and
technical permissions together, with version and execution records retained.
Long‑term economic sustainability should be driven by real service demand: customers pay agreed charges,
eligible services receive compensation, and approved network fees support reconcilable operating
expenditure. Reward budgets may support service development, but their sources, consumption rates and
subsidy dependence must be disclosed. Acceptance testing also models cash needs and service costs
without token appreciation or new financing and with reduced rewards, avoiding artificial demand created
through circular incentives.
Candidate Use
Share and Ceiling
Conditions for Effectiveness
Ecosystem and verification‑service rewards
40% 400,000,000
Verified services, budgets, deduplication, distribution and treatment of unearned
allocations
Team and advisers
15% 150,000,000
Recipient eligibility, vesting conditions and complete release schedules
Protocol reserve
15% 150,000,000
Legal holder, unlocking, expenditure approval and use restrictions
Potential private allocation
15% 150,000,000
Issuance route, recipients, consideration and transfer restrictions
Potential public allocation
10% 100,000,000
Applicable issuance and communication routes; no commitment to a public sale or IDO
Initial liquidity budget
5% 50,000,000
Lawful venue, deployment conditions, market‑making agreement and wallet reconciliation
8 Identity, Qualifications and Open Participation
The identity layer supports natural persons, organizations, devices and software agents, but does not
equate proof of key control with proof of a subject's identity. A device signature can demonstrate
possession of a device key, and an organizational statement can demonstrate that an issuer made a claim.
Real‑world identity, institutional registration, qualifications and device ownership require their own
evidence and verification processes. A DID is a method of identification and control; it does not
automatically provide identity vetting, Sybil resistance or a trustless authority. [S1–S2]
Open participation is differentiated by activity. Browsing public specifications, developing adapters,
verifying public proofs and submitting authorized evidence should not generally require investment
eligibility. Issuing professional qualifications, receiving restricted data, controlling devices,
handling funds or participating in regulated transactions requires the separate permissions and
conditions appropriate to that activity. Participation by anyone does not mean that everyone may perform
every operation.
Access can include ordinary wallets, smart accounts, access through institutional intermediaries and
interfaces designed to lower technical barriers. Fee sponsorship, mobile workflows, multiple languages
and recoverable accounts can reduce participation costs; sponsorship limits, rate limits, abuse controls
and intermediaries' authority must be transparent. Depending on the product configuration, participants
should be able to verify public objects and offline evidence without a native token or paid staking.
Recovery, session permissions and budgets for smart accounts still require implementation by the
specific account; adopting ERC‑4337 alone does not establish those capabilities. [S9]
Credential issuers' authority must have a scope and validity period. The protocol can record an issuer's
institutional affiliation, permitted scope and status, but deciding which issuer to accept remains a
policy choice tied to the intended use. For participants unable to supply a particular credential,
applications should explain alternative evidence routes, functional limits and appeal procedures, rather
than interpreting missing evidence as personal untrustworthiness.
Role eligibility and token holdings are verified separately. Ordinary users may establish identities and
submit proofs under the applicable rules. Node roles with economic responsibilities may be subject to
approved performance‑bond requirements, while DCNFT purchasers undergo separate offering and transfer
eligibility checks. $RWAIX holdings, voting power or staked amounts cannot replace qualification
evidence or generate a personal trustworthiness score.
9 Claims, Evidence and Dependency Graphs
CredentialEnvelope stores issuer, subjectRef, claimsDigest, schemaId, validFrom, validUntil, statusRef
and proofSuite. Its source document may be a verifiable credential, a signed attestation or an adapted
industry‑specific proof. EvidenceBundle associates observationRef, source, captureTime, integrityProof,
availabilityPolicy and relevant credentials. Adapters must distinguish observed facts, issuer claims,
third‑party opinions and algorithmic inferences. A custom Envelope is a container; it may be described
as a conforming VC only when the complete profile of the selected standard is satisfied. Adaptation must
not discard the original signature, subject or status semantics. [S2]
Typed edges in the evidence graph express who issued a statement, which observation it relies on, which
action it authorizes, which version it supersedes and who reviewed it. Nodes should carry identifiers
for provenance and controlling parties. The same original evidence repackaged by several intermediaries
must not automatically count as multiple independent sources. A cycle of mutual endorsements cannot
generate its own root of trust; verification rules should include cycle detection, limits on dependency
depth and clustering of parties under common control. Provenance relationships may record historical
cycles, but the dependency subgraph used to derive a verification conclusion must be acyclic and subject
to limits on node count, edge count and evaluation depth. Violations return explicit errors.
Facts about the physical world depend on their input paths. Asset existence, delivery of goods, device
location and human conduct may require on‑site inspection, independent observations or dispute
procedures. The protocol preserves observation methods, device identities, signature times and anomaly
flags so that verifiers can see the trust assumptions. Consensus can consistently record an incorrect
input; multiple sensors controlled by the same party do not constitute independent evidence.
An evidence package must include the formats, algorithm identifiers, versions and retrieval conditions
needed to replay verification. If data is unavailable, beyond its retention period or inaccessible to
the verifier, the result should identify the resulting capability gap. On‑chain anchoring does not
replace availability safeguards. Retention periods, redundancy, access permissions, backups and deletion
responsibilities form part of the deployment contract.
Economic events must state their evidentiary scope when added to the evidence graph: a DCNFT register
event supports a series holding relationship, a fee receipt supports a confirmed payment event, and
reward verification supports a specific service contribution. Wash trading, circular calls or mutual
endorsements among affiliated nodes must not earn rewards directly on the basis of transaction volume.
Evidence for the same service is deduplicated using a unique business identifier, with known
common‑control relationships identified.
10 Contextual Policies and Portable Trust Receipts
RWAIX uses TrustContext to specify the audience, purpose, object, requested action, jurisdiction or
business domain, challenge nonce, deadline and policy version for a verification request. TrustPolicy is
a fixed‑version rule set defining permitted issuers, required predicates, evidence freshness, necessary
independent sources and failure handling. Instead of blending all evidence into a global score, the
protocol preserves individual evaluations and their dependencies.
Verification first checks structure and signatures, then subject bindings, issuer authority, status,
time, context and evidence dependencies, before running a deterministic policy. For the same normalized
input, policy version and state snapshot, conforming implementations should produce the same result.
Live network queries must be converted into input snapshots with provenance and timestamps; otherwise,
different machines cannot be expected to reproduce the original decision fully. The verifier first
creates a separate PolicyDecision that fixes ruleSetDigest, engineVersion, engineBuildDigest,
inputSnapshotDigest, dependencyGraphDigest, predicateResults and reasonCodes, then includes its
decisionRef in the receipt. Rule changes, additional inputs and human adjudication each produce a new
decision rather than overwriting the previous result. Evaluation must not implicitly read the live
clock, random values or model outputs; any necessary external values are supplied as fixed inputs.
Successful historical replay does not establish that execution is still permitted now.
TrustReceipt records contextDigest, policyDigest, decisionRef, evidenceRoot, objectVersion,
statusSnapshotRef, stateReference, evaluatedAt, validUntil, predicateResults, decision, reasonCodes,
verifierRef and a signature. ALLOW means that the request satisfies the rules under the specified
dependencies; DENY means that a failure to satisfy a requirement has been established; INDETERMINATE
means that essential facts or evidence are insufficient. States such as EXPIRED, REVOKED and DISPUTED
are recorded as explicit reasons and dependency states and must not be treated as ALLOW.
A portable receipt can be used in two ways: the relying party can accept the verifier's signed
conclusion, or independently replay verification if authorized to obtain the necessary evidence. The
former still trusts the verifier; the latter still trusts the accepted evidence roots and observation
methods. A zero‑knowledge proof can establish that specified predicates or computations satisfy
constraints. Its applicable circuit, public inputs, trusted setup and privacy leakage must be explicit.
A valid proof does not establish facts outside the circuit's coverage.
Dual‑token adapters bind applicable fields such as tokenRef, seriesId, rightsDocumentDigest, quoteId and
rewardClaimId to the context, version and evidence snapshot, explicitly omitting fields that do not
apply. A TrustReceipt may state which rules a particular rights‑transfer or fee request satisfies, but
does not itself change the register, debit funds, establish reward entitlement or allocate cash. Those
actions still require separate authorization and confirmation of final state.
Connects the verification conclusion to independent execution authorization
11 Privacy, Minimal Disclosure and Revocable Status
Privacy design begins with data minimization: identity documents, contact details, original contracts,
sensitive business data and plaintext that directly reveals identity do not belong on a public chain.
Hashing is not anonymization. Low‑entropy fields may be enumerated through dictionary attacks, while
public timestamps, addresses and relationship graphs may also reidentify subjects. Commitments require
appropriate randomness; indexes and access logs also belong in the privacy threat model.
Selective disclosure reveals only the fields needed for the current purpose. With an appropriate proof
suite, predicate proofs can replace complete records for propositions such as age or qualification
thresholds. Proof methods differ in linkability, computational cost and support for revocation. Each
protocol profile fixes its security suite and verification procedure; it cannot assume that every
credential inherently supports hiding arbitrary fields or generating zero‑knowledge proofs.
Status checks must balance freshness and privacy. Batch status lists, caching or proven status snapshots
can reduce the risk of revealing a subject's activity through individual queries. List update times,
permitted staleness windows and handling of status‑service failures must still be defined. High‑risk
operations should pause or move to human review when status is uncertain, rather than silently falling
back to acceptance. When using a Bitstring Status List, the list's signature, purpose, index, validity
period and issuer authority must be verified. Irreversible revocation and reversible suspension are
handled separately. [S3]
Revocation, suspension or expiry requires future dependency evaluations to be updated; it does not erase
history. Earlier receipts retain the rules and status snapshots used at the time, while new operations
recheck current status. Off‑chain deletion must also address copies and access permissions. Complete
deletion of existing commitments on a public chain cannot be promised, so sensitive data should remain
off‑chain from the outset.
DCNFT investor eligibility, holdings and distribution data, together with node bond and reward data, are
subject to role‑based minimal disclosure. Revoking a qualification can block subsequent operations
relying on it; it does not automatically confiscate tokens, erase valid claims or cancel earned
compensation. Freezes, deductions, recovery and dispute handling each require their own basis and
authority. Correlation risks from public‑chain holdings and fee records should be included in privacy
testing.
12 Lifecycle, State Safety and Account Recovery
The object lifecycle uses DRAFT, ACTIVE, SUSPENDED, REVOKED and RETIRED. SUSPENDED may return to an
active state under the rules. REVOKED and RETIRED do not reactivate the original version; reestablishing
a relationship requires a new version or object while preserving history. When the credential layer maps
to a Bitstring Status List, revocation is irreversible and suspension is reversible; renewed
qualifications require credential reissuance under the issuer's rules. Minting, transferring or burning
an NFT is a token event and does not automatically constitute credential issuance, contract
effectiveness or extinguishment of rights. [S3]
Verification and execution occur at different times. Before execution, the executor must recheck the
receipt's purpose, validity period, nonce, object version, current permissions and required status
freshness, preventing erroneous authorization where revocation occurs after verification but goes
unchecked before execution. On the same chain, an atomic operation can check critical versions and check
and consume the nonce. Dependencies on off‑chain state require a stated maximum delay and pause
conditions; the time window cannot be described as entirely eliminated.
Account recovery should combine mechanisms such as multiple factors, approval by several parties, delayed
effectiveness, notifications and dispute freezes. Recovering control keys does not automatically restore
revoked qualifications, transfer personal identity or transfer another person's assets. Separate version
relationships are created before and after recovery so that verifiers can identify key rotation,
controller changes and any need to reissue credentials. Procedures should allow withdrawal or freezing
in response to misconduct by an authorized recovery party. For ERC‑1271 contract accounts, records must
also identify the historical signature‑verification block, account implementation and permission
version. Current signature‑verification success or failure alone cannot reconstruct past validity. [S8]
Chain reorganizations, duplicate cross‑chain messages and service retries require unique event keys, a
nonce, prior‑state conditions, idempotent handling and finality confirmation. Cross‑chain and off‑chain
operations use explicit pending‑confirmation states, timeouts and compensation procedures. Even if all
components are eventually consistent, unconditional atomic settlement across multiple independent
networks and banks cannot be claimed. Chain‑event records distinguish submission, inclusion in a block,
satisfaction of configured finality conditions and removal by reorganization; blockHash and a
confirmation policy fix the snapshot. Critical authorizations do not rely on events that have not met
finality conditions, and pending operations affected by a reorganization are reconciled again.
A single business process records object state, rights‑registration state, token‑transfer state and funds
state separately. Transfer submission, on‑chain confirmation, an update to a statutory or contractual
register and receipt of cash are different events. Court orders, key recovery or registration
corrections append records through authorized processes rather than delete the original history.
Cross‑chain representations maintain a unified economic supply through locking or burning, minting and
replay protection.
13 Verification Networks and Collusion Resistance
The verification network is open through replaceable specifications and implementations. Applications may
verify for themselves or select recognized independent verifiers. Node registration establishes only
that a node has satisfied the registration process; professional capability, accountability and
independence still require explicit qualifications and oversight. The protocol should disclose major
dependencies, service availability and concentration rather than presenting multiple nodes under common
control as decentralization.
Verification by multiple parties improves reliability only when its threat‑model assumptions hold.
Critical facts may require different controlling parties, different observation paths and separation of
roles. Random assignment, cross‑review, conflict disclosures and signed records provide supporting
controls. Reaching a signature threshold does not demonstrate economic or organizational independence,
nor does it rule out contamination of a shared input.
Staking, challenge bonds or insurance can create economic constraints for certain adjudicable violations,
but capital cannot purchase truth. Slashing conditions should be explicit, verifiable and open to
appeal; subjective disputes that cannot be objectively determined should not trigger automatic
penalties. Verification of public facts, restricted professional judgments and legal adjudication
require different accountability arrangements. No universal vote can replace every professional and
judicial process.
The evidence graph can identify known common control and circular dependencies, but cannot guarantee
discovery of hidden collusion. Evaluation must cover malicious issuers, bribed verifiers, compromised
keys, colluding participants and honest but malfunctioning nodes, reporting false acceptance, false
rejection, processing latency and the cost of human intervention.
$RWAIX performance bonds constrain defined node responsibilities; a larger stake does not make evidence
more truthful. Verifier selection should combine independence, task capability, sampling and conflict
checks, none of which can be replaced by bond size. Service rewards should depend on deduplicated
eligible contributions and approved budgets, with tests for Sybil accounts, affiliated‑party collusion
and reward capture. Unearned allocations do not create automatic income rights.
14 Constrained Agents and Executable Collaboration
An Agent is a software participant with delegated authority. Every request should identify its principal,
target object, authorized purpose, permitted tools, monetary or resource limits, validity period and
audit reference. Natural language generated by a model does not directly confer transaction authority. A
deterministic executor validates structured intents and, where necessary, requires review or approval by
the responsible party. Subdelegation may only narrow actions, duration and limits; it must not expand
authority, renew itself or reset the principal's shared budget. The delegation chain and its revocations
are also execution dependencies.
Budgets and permissions cannot be checked only per request. Concurrent Agents, retries and split
transactions must share a limit ledger that can be updated atomically, constraining cumulative amounts,
rates and resource use. External documents, webpages, credential attachments and tool outputs are
untrusted inputs; instructions within them cannot increase an Agent's authority or change a payee.
Within the same authorization scope, asset and measurement period, reservations include the agreed fee
upper bound. Consumed allowance plus pending reservations must not exceed the total allowance. Durable
records link reservations, execution confirmations and releases to the same operation.
Collaborative commitments may use business states such as PROPOSED, ACCEPTED, IN_PROGRESS,
EVIDENCE_SUBMITTED, FULFILLED, DISPUTED and CANCELLED, with transition conditions defined by a profile
accepted by the parties. An ALLOW receipt provides evidence only that the rules have been satisfied; the
actual executing party must still possess the necessary authority. Acceptance, recognition of a payable,
payment approval and confirmation of receipt of funds are recorded separately.
Operations involving funds, digital objects or devices use their respective execution adapters, which
enforce checks on prior state, nonce, beneficiary, limits, version and expiry. Results reference the
original intent and receipt. Failures, rollbacks and reversals append records rather than overwrite
history. Applications need not involve payment, and the protocol does not require all trusted
collaboration to be financialized. A timed‑out external request enters OUTCOME_UNKNOWN and awaits status
queries and reconciliation, retaining its reserved allowance while its status is queried under the
original operation identifier. The corresponding allowance is released only after non‑execution is
confirmed or verifiable compensation is completed. A timeout must not be treated as non‑execution
followed by direct submission of a new request. Before execution, persist the intent and a pending‑send
record; retries or queries use the same idempotency identifier. If the downstream system does not
support idempotency and status queries, apply limits, manual reconciliation or a more conservative
execution method rather than promise end‑to‑end exactly‑once execution. The same idempotency identifier
must bind to the same request digest; reuse of a key with different content is rejected.
Agent delegation separately limits permitted payment assets, maximum debits, quote validity, payees and
whether any interaction with DCNFT is allowed. Ordinary service calls do not implicitly authorize the
purchase, transfer or pledging of investment interests. The executor checks consumed allowance plus
pending reservations for the same asset and budget period, and separately enforces any approved
base‑currency exposure limit. An expired quote or abnormal price source requires renewed authorization.
An unknown payment outcome retains the reservation in the original asset; switching to another token
must not trigger resubmission.
Figure3. Verification and execution boundaries
15 Open Interfaces and Interoperability Boundaries
Protocol interfaces should cover registerObject, publishVersion, resolveBinding, submitEvidence,
evaluatePolicy, verifyReceipt, checkStatus, prepareIntent and executeIntent. These names describe
responsibilities in the reference implementation, not deployed APIs. Each interface fixes its input
schema, error codes, signature domain, idempotency keys and time semantics by version, and provides the
test vectors needed for independent implementation.
ERC‑721 and ERC‑1155 are candidate interfaces for the NFT layer, with each profile fixing object types,
quantities and transfer semantics. The locked state in ERC‑5192 restricts transfer but does not
guarantee a permanent lock. ERC‑5484 requires consent before issuance, fixed burn authorization and no
metadata modification after issuance, so a configuration with dynamic metadata cannot claim conformance
with that constraint. DID methods, VC securing mechanisms, status lists and account implementations must
likewise specify their versions, extensions and testing scope. [S1–S9]
Evidence‑package content commitments use fixed canonicalization rules and hash algorithms. JSON may use
RFC 8785 JCS, with its numeric range, character semantics and array semantics made explicit; schemas
prescribe string representations for high‑precision amounts and long integers. VC and other proof suites
continue to use their prescribed transformations. JCS must not be substituted arbitrarily for the
signature‑verification procedures of every standard. Business signatures also bind the protocol version,
chain or domain, object, action, audience, nonce and deadline; EIP‑712 itself provides no replay
protection. [S12–S13]
Cross‑chain references preserve the original network, contract, object and basis for final confirmation.
Mapped NFTs, bridge messages and mirrored state do not independently create a second native entitlement.
The receiving side specifies bridge verifiers, finality waits, expiry policies and pause procedures.
Interoperability across industries means sharing object and evidence syntax while preserving each
application's distinct requirements for facts and authority. When converting between VC, NFT or
attestation representations, the adapter outputs the original representation, conversion rules and a
semantic‑loss report. Inputs whose essential semantics cannot be preserved are rejected, rather than
masking provenance through reissuance.
Dual‑token interoperability must preserve object category, issuer, series rights, transfer eligibility,
quote and payment assets, reward conditions and governance scope. Bridging $RWAIX or mapping DCNFT
requires disclosure of custody and final‑registration dependencies. Conversion is rejected if the target
system cannot express these conditions. Wrapping a token or moving it to another network neither expands
the original rights nor removes existing restrictions.
When external business documents are integrated, adapters should publish their field and semantic
mappings, versions and test results. OASIS UBL provides models for business documents such as orders and
invoices and may serve as a mapping foundation for a specific profile. Adopting some of its fields does
not establish conformance to the entire standard. Differences between systems in units, taxes and fees,
charges, acceptance and legal effect require explicit handling; matching field names alone do not
justify automatic mutual recognition. [S24]
16 Security Model and Governance Constraints
The protocol assumes that attackers can create large numbers of accounts, submit false materials, replay
messages, control some issuers or verifiers, steal keys, corrupt external data and manipulate Agents.
Correct cryptographic primitives do not establish end‑to‑end security; wallets, recovery services,
frontends, indexers, administrators and the software supply chain are all within scope. The reference
implementation requires permission separation, key rotation, rate limits, monitoring and incident
response.
Protocol upgrades should include public version proposals, compatibility descriptions, test results,
delayed effectiveness and constrained execution. Earlier receipts are checked under their original
versions; new policies should not rewrite historical conclusions. Emergency pauses must specify scope,
triggering conditions, maximum duration and recovery procedures. They must not become an interface for
administrators to take indefinite control of objects or funds.
Governance maintains specifications, permission scopes and service rules; it has no authority to rewrite
facts arbitrarily or retrospectively alter personal qualifications. Disputed claims record the claimant,
grounds, affected scope, adjudication roles and outcome. Matters requiring professional judgment outside
the protocol are referred to the appropriate procedures. A governance vote does not automatically amend
existing contracts, intellectual‑property rights or investor rights.
Implementations should disclose critical points of concentration and trust assumptions, such as default
issuer registries, status services, bridges and recovery committees. Security metrics must include
outcomes when these external dependencies fail, rather than measuring only the execution success rate of
on‑chain contracts.
Dual‑token modules introduce threats including price‑source manipulation, reward farming through
artificial activity, declining bond value, administrative minting, duplicate bridge supply and
governance capture. Minting, transfer controls, fee spending, reward budgets, bond deductions and
governance execution use distinct permissions. Upgrades must verify that these boundaries continue to
hold. Emergency‑pause scope and recovery conditions are explicit, protecting accrued rights, pending
payments and appeal records.
Attack or Failure
Required Controls
Remaining Boundary
False claims and corrupted physical inputs
Issuer authority, provenance, independent observations and dispute paths
Signatures or on‑chain recording alone cannot prove physical facts
Sybil identities and circular endorsements
Rate limits, context‑appropriate identity costs, dependency graphs and common‑control
detection
Hidden relationships and new identities cannot be ruled out completely
Revocation delays and cross‑domain replay
Status freshness, context‑bound signatures, nonce and checks before execution
Off‑chain updates have latency; high‑risk operations need a pause policy
Key theft and recovery abuse
Separation of permissions, delayed recovery, multiple approvals and freezes
Recovery parties and thresholds themselves require explicit trust assumptions
Privacy correlation and data leakage
Minimal disclosure, purpose limits, separation of relationship identifiers and access audits
Public transactions and metadata may still enable correlation
Agent prompt injection and excess execution
Deterministic executors, shared budgets, tool allowlists and approvals
Model output quality cannot replace permission controls
Compromised bridges or governance
Scope limits, finality verification, delayed upgrades and emergency pauses
Multiple chains do not automatically improve security and may enlarge the attack surface
17 The Company’s NFT Business as the First Planned Application
The initial plan is to connect the company’s disclosed NFT business to the universal trust and
transaction core. NFT Limited’s public materials dated October 6, 2026 describe NFT artwork listing,
trading and related consulting. Its management discussion for the first half of 2026 identifies
Metaverse HK as the operator of the existing NFT platform and describes commissions on NFT transactions.
This business foundation does not mean that RWAIX has been integrated with the platform or that
provenance, licence‑verification or authorized‑settlement modules operate in production. A pilot must
first identify the platform operator, seller or licensor, customer, technology provider and receiving
entity. Agent Link’s proposed technology role requires separate corporate authority and contracts.
[S34–S35] That management discussion also refers to artwork ownership shares. Each existing product’s
fractional interests, licences, income rights or return arrangements require product‑specific review.
Neither an NFT label nor the synthetic example in this whitepaper establishes that all such products are
indivisible assets, non‑investment transactions or outside securities rules. [S35]
The proposed first pilot would select one specific NFT object and a controlled order path after verifying
its rights, product character and sale or licensing authority. Whether it is one non‑fractional object
must be confirmed from the actual product documents; this does not describe the entire existing
business. The minimum flow checks participant authority and work‑provenance claims, fixes work and
metadata versions, binds a mint record or existing token, defines transfer and licence scope, signs
order terms, submits delivery evidence and obtains acceptance from the authorized recipient. Separate
funds authorization and reconciliation follow the contractual trigger conditions. Payment after
acceptance is one possible sequence; advances, installments and final payments each bind their own
obligations, triggers, funds restrictions and refund rules. The creator, minter, current controller,
seller and copyright owner may be different parties. Their claims and supporting grounds are recorded
separately; wallet possession does not automatically confer listing, transfer or licensing authority.
Figure 4. Object, rights, delivery and separately authorized payment in the proposed NFT pilot
The object record fixes objectId, workVersion, contentDigest, metadataDigest and the binding version,
with links to provenance claims, mint‑request authority and observation time. An existing token is
additionally bound to chainId, contractAddress and tokenId. An unminted object remains a candidate,
without fabricating an existing tokenId or completed chain binding. A profile marks minting or binding
as confirmed only after the corresponding chain record and prescribed confirmation evidence are
available. Failed or unknown mint outcomes and metadata changes preserve the original record and require
reconciliation before recovery or a new version; resubmission is not the default recovery action.
Digests and mint timestamps establish defined record relationships, not originality or lawful title.
The rights layer states whether the buyer receives token control, specified access or use rights, or
other separately executed interests. RightsBinding references rights documents, the authorization chain,
territory, purpose, term, sublicensing and revocation or termination conditions; both parties confirm
the same termsDigest. Transferring an NFT does not automatically transfer copyright, reproduction
rights, investment interests or income claims. Missing or conflicting rights evidence produces an
indeterminate result or denial and human review. The legal character of an ordinary NFT transaction
still depends on its actual arrangements. Rights‑source verification assesses submitted evidence and the
authorization chain; it guarantees neither originality nor the absence of third‑party claims.
TradeEnvelope fixes the tradeId, seller and buyer, specified token and version, delivery conditions,
fees, refund rules, expiry and acceptanceAuthority. For an NFT confirmed to be indivisible, one complete
transfer uses one explicit delivery portion identifier; partial acceptance does not fabricate a partial
transfer. A batch order accepts each object or clearly defined portion separately without counting the
same token twice. Listing or resource locks constrain only the integrated participants that observe the
mechanism; they cannot guarantee the absence of duplicate sales on every external market. Control status
and transfer authority must therefore be checked again before submission.
Delivery evidence separately records the destination account, transaction and log identifiers, chain
observation point and confirmation conditions for the token transfer, together with any documents,
access or licence delivery required by contract. A seller’s signature or a transfer event does not
establish that the customer lawfully received all agreed rights. The verifier creates a PolicyDecision
and TrustReceipt, and the authorized accepter creates an AcceptanceRecord under the order conditions.
Chain reorganizations, recipient mismatches, unavailable attachments or acceptance disputes enter the
relevant reconciliation state. Token transfer, commercial acceptance, receipt of funds and legal
finality are assessed separately; atomic delivery across different systems is not presumed.
Payment authority separately binds the order, obligationId, portionId, payee, asset and limit. Service
consideration, platform commissions and optional network charges have separate quotes, contractual
grounds and ledgers. The first phase may use approved fiat or existing payment routes without issuing or
holding $RWAIX. Unknown payments and executed but unapplied amounts continue to consume coverage, and
repeated clicks reuse the original paymentAttemptId. A dispute over NFT delivery does not itself
authorize a refund, remint or reverse transfer. Customer funds do not become the platform’s own
operating budget or flow into later facility financing or the network treasury unless the actual
contracts and applicable rules permit that use and the necessary authority is established.
Before release, fixed orders and versions are tested against provenance gaps, unauthorized minting or
transfers, metadata substitution, out‑of‑scope licences, duplicate delivery, chain reorganizations,
unknown payments and partial disputes. Report false acceptances divided by known‑invalid test cases and
false rejections divided by valid test cases, while reporting missing‑evidence outcomes separately. Also
measure duplicate side effects by unique order and payment attempt, evidence‑replay consistency, manual
reconciliation time and unresolved discrepancies. Samples, thresholds and baselines are registered in
advance. Transfer facts, licence evidence and receipt of funds require reconciliation against their
respective independent sources. Passing synthetic browser cases does not establish real platform
integration, rights diligence or production security acceptance.
This proposed first application uses ordinary NFT transaction objects and licence credentials, without
importing facility DCNFT financing or distribution rights. $RWAIX serves network functions only where
separately approved and useful; buying tokens is not a default condition for listing, acceptance or
proving truth. Subsequent compute services, facility assets and DCNFT series follow the entity, funds
and verification requirements in Section 18.6. Order consideration, commissions and copyright‑licence
payments in this section are not automatically shared with DCNFT or $RWAIX holders.
18 Applications Across Domains and Domain Adaptation
NFT transactions in Section 17 are the first planned application. This section retains the other seven
domains as subsequent adaptation and validation directions, not claims of deployment. The matrix places
the initial application and extensions together: they share objects, evidence, contextual policies,
receipts and separately authorized execution. Industry extensions add schemas and evidence rules while
prioritizing core reuse, without presenting industry facts as blockchain consensus.
Each pilot preregisters samples, baselines, thresholds and metric denominators, distinguishing correct
rejection, erroneous allowance and insufficient evidence. The acceptance tests below assess only their
tested scope and cannot establish universal reliability. Porting effort, core changes and safety
exceptions should also be disclosed.
The applicability of the two instruments in each application depends on its specific rights and services.
DCNFT retains its facility‑interest meaning. Other industries studying new asset or income‑participation
instruments should establish distinct types and legal documents. Ordinary identity, licensing, data,
supply‑chain and machine services do not require prior subscription for facility DCNFT. The
network‑token module is enabled only in approved configurations with a practical purpose.
NFT transactions and the seven extensions share the transaction events and conformance rules in Sections
4 to 5. Each profile fixes acceptable evidence, delivery units, acceptance authorities, dispute handling
and settlement conditions. Processes such as identity verification that involve no purchase payment
declare the absence of the corresponding payment obligation. Data and copyright applications specify
licence scope, while physical‑goods and device applications retain their on‑site sources of facts and
safety controls. Modules can be reused, while domain meaning must remain explicit.
Section 17 develops the initial NFT transaction design; this section covers seven extension domains.
Section 25 identifies potential payers, billing units and initial commercial‑validation milestones for
each. Section 26 separately identifies the actual browser‑demo version and coverage; the number of
demonstrations does not substitute for pilot acceptance. Reusing state and ledger rules does not imply
connections to real institutions, industry data, assets or customers, and adoption does not require
token issuance in every application.
Scenario
Proposition to Establish
Shared Core
Domain Dependencies
NFT trades (initial)
Transfer and licence evidence for the specified object meets order conditions
Object binding, order, acceptance, separate payment
Platform authority, rights chain, chain records and receiving entity
Identity and qualifications
The specified subject currently meets admission conditions
Subject binding, credential status, receipts
Institutional authority, identity and recovery
Content licensing
The licensee is authorized for a specified use of a version
Object versions, rights references, policies
Copyright evidence and dispute resolution
Data collaboration
This access meets the agreed purpose and scope
Purpose binding, minimum disclosure, authority
Custodian and constraints at the user
Physical performance
The specified parties confirmed the agreed handover
Evidence dependencies, lifecycles, disputes
Physical inspection, tags and sensors
Agent workflows
The action is within a valid delegation and aggregate budget
Intents, authority, budgets, idempotency
Tool semantics and organizational approvals
Compute services
Delivery evidence meets a specific acceptance policy
Commitments, evidence, decisions, execution
Metering, task verification and customer acceptance
Machine services
An authorized device performs a task within a defined scope
Device binding, permissions, execution records
Local safety, calibration and on‑site control
18.1 Identity, Qualifications and Collaboration Across Institutions
An applicant presents purpose‑limited qualification evidence to a receiving institution; the issuer,
applicant and relying party retain distinct responsibilities. A TrustObject binds the subject, while the
evidence graph links qualifications, authority and status. The policy checks issuer authority, purpose
and validity and produces a receipt. The receiving institution separately authorizes account opening,
admission or collaboration. Qualifications cannot be sold with a transferable asset NFT.
Key control does not establish real‑world identity, and multiple accounts do not establish multiple
independent people. Acceptance across institutions depends on recognized issuers and recovery rules.
Acceptance testing reports erroneous admissions after revocation in the test set, decision agreement
across implementations, and the fields disclosed and time required for legitimate applications.
Rejection and insufficient evidence are recorded separately, with an appeal path.
This application primarily uses qualification and subject‑binding objects and does not require DCNFT
investment interests. $RWAIX may be an approved option for verification‑service fees or performance
bonds. Fees are borne by the applicant, institution or agreed sponsor; purchasing tokens does not become
a condition for obtaining genuine qualifications.
18.2 Content, Copyright and Licensing
A creator registers a version of a work, a licensor states the basis of its rights, and a user requests a
particular use. The TrustObject references the content digest and licence documents; the evidence graph
retains creation claims, the authorization chain and disputes. The policy checks territory, duration,
purpose and sublicensing scope. A receipt supports review; only a separately authorized adapter can
grant access or execute an agreed payment.
A timestamp, signature or provenance record does not prove that content is true or original, or that the
licensor owns its copyright. Disputes require the agreed dispute‑resolution institution. Tests cover
expired licences, out‑of‑scope uses, conflicting claims about the same work and invalid sublicensing,
reporting erroneous‑allow rates, detection of gaps in the rights chain and version‑replay agreement.
Revoking a credential cannot automatically recall downloaded copies.
Work NFTs and licence credentials define specific uses and do not become facility DCNFT merely because
they take NFT form. Approved network fees may use $RWAIX, while creator licence compensation is settled
separately under the licence agreement. Instruments participating in copyright income require their own
type and rights design.
18.3 Data Authorization and Privacy‑Preserving Collaboration
The data provider and user agree on purpose, recipients and duration, while a custodian controls actual
access. A TrustObject represents a dataset version or access commitment, and controlled evidence records
authority, provenance and processing constraints. A policy evaluates the request with minimum
disclosure. A receipt together with separate authorization enables time‑limited access, controlled
queries or permitted computation; logs record actual calls.
Sensitive source data remains in a controlled environment; an on‑chain commitment does not provide
confidentiality. Revocation should prevent subsequent authorized access, but cannot erase copied data or
effects already incorporated into a model. Tests measure the distribution of time from revocation to
access blocking, successful unauthorized queries, disclosed fields and leakage through logs. Loss of
control at the user, model leakage and data deletion require separate safeguards and evidence.
Data access rights depend on licences and access controls. $RWAIX may support approved data‑service fees
or node‑service compensation, but token holdings do not automatically purchase sensitive data or AI
training rights. Facility DCNFT does not serve as a data‑access credential.
18.4 Supply Chains and Physical Performance
Suppliers, carriers and recipients coordinate batch handovers. A TrustObject links the batch, order and
traceability identifier; the evidence graph links signed receipts, inspections and sensor records. The
policy checks participants’ authority, event order, quantities and acceptance conditions. A receipt
supports the receiving decision; an authorized system separately recognizes inventory, payables or a
dispute.
A signature identifies the declarant; tags may be copied and sensors manipulated. The physical contents
and quality still require inspection. Tests inject duplicate identifiers, missing handovers, anomalous
readings and collusion cases, reporting detection and false‑positive rates and comparing ledger records
with physical goods through independent sampling. Unobservable physical facts remain indeterminate.
Batch and handover objects carry logistics evidence; $RWAIX may support approved verification fees or
node bonds, while payment for goods is settled separately. Tokenized interests used in receivables or
inventory financing require separately defined instruments, debtors, security and transfer rules.
Facility DCNFT rights documents cannot simply be reused for them.
18.5 AI Agents and Organizational Workflows
An organization delegates procurement, scheduling or approval submissions to an Agent. A TrustObject
identifies the principal and task, and the evidence graph connects the delegation chain, tool
permissions and business evidence. The policy evaluates a structured intent. Its receipt does not
replace authority: the executor rechecks the payee, current status and shared budget, atomically
reserves allowance, invokes the tool and appends an execution record.
External text cannot expand authority; subdelegation can only narrow it, and human approval binds to a
specific intent. Tests apply prompt injection, concurrent transaction splitting and retries, checking
that consumed allowance plus pending reservations stays within the limit and reporting unauthorized
effects and human‑review volume. A timeout enters OUTCOME_UNKNOWN, retains its reservation and awaits
reconciliation; it must not be treated as confirmed failure, used to release the reservation, or
resubmitted under a new key.
$RWAIX spending and other payment assets enter an Agent's budget separately. Any DCNFT subscription,
transfer or bond lock requires a separate, explicit delegation. Service‑orchestration authority does not
automatically expand into investment, funds‑management or voting authority.
18.6 Subsequent Compute Services and Facility‑Rights Expansion
As a subsequent extension, the compute use case tests the full path from objects and facts to execution.
A facility NFT references the legal entity responsible for the facility and its versioned records;
device objects reference device identities; service commitments reference resource reservations,
workloads and acceptance policies. Delivery evidence forms an industry‑specific ServiceReceipt, which a
general policy incorporates into a TrustReceipt. The industry receipt and the general trust receipt
serve distinct purposes; a general ALLOW result cannot replace actual verification of a compute result.
The customer submits resource, time, budget and verification requirements. The scheduler reserves
capacity and generates a reservationId. A running attemptId links devices, workloads and observations.
The verification service checks device attestation, execution evidence and customer acceptance under the
policy. An authorized settlement adapter then processes payables or refunds. Resource reservations can
constrain duplicate commitments only within the protocol's managed scope; the ledger alone cannot
discover every instance of off‑chain overselling.
Remote attestation addresses whether a device or execution environment meets explicit measurement
conditions; it does not generally establish the semantic correctness of arbitrary AI outputs. Task
correctness may require redundant computation, output sampling, verifiable computation or customer
acceptance, with methods selected by task type and their costs disclosed. Integrating confidential
computing with the universal trust protocol requires an explanation of proof coverage and the inputs
still supplied by external parties. [S14]
Customer service funds and investment financing funds are controlled separately. For example, using the
same asset and unit of account, a prepayment of 1000, an amount of 720 that has met payment conditions,
including the agreed fees in this example, and a pending refund of 280 create only the corresponding
payable and refund records. Approval does not mean that funds have been received, and it does not
automatically create returns distributable to investors. Under the proposed and duly authorized facility
structure, Agent Link would undertake project and technology operations; the facility SPV would hold
assets or lawful interests and raise financing; and a qualified local FacilityOp would undertake on‑site
performance and its licensing obligations. This allocation of responsibilities is the proposed facility
deployment structure, not a protocol requirement for every industry.
In the subsequent compute application, a DCNFT series carries only the interests expressly defined in the
identified SPV's documents; customer compute orders exist independently. Under an approved
configuration, $RWAIX may be used for network service fees, operator performance bonds or verified
service incentives. Customer payments, Agent Link service compensation, SPV operating and debt payments,
DCNFT distributions and network rewards are accounted for separately. Non‑cash token receipts are not
counted as cash available for facility distributions before the agreed conversion and cash
reconciliation are complete.
The presence of a device does not prove saleable capacity, and signed telemetry does not prove correct
computation. Performance and correctness are verified separately. A pilot fixes workloads and resource
baselines, reporting task‑acceptance error rates, discrepancies against independent metering, latency
percentiles and dispute costs. Tests include failures, overselling and duplicate settlement; passing
selected cases does not establish that every computation is verifiable.
This application tests cooperation between both instruments: DCNFT maps facility‑series interests, while
$RWAIX supports approved network economic functions. Linking identifiers connect service evidence, fees
and series reports; each category of funds remains subject to its own contracts, sources and
authorizations.
18.7 Devices, Robots and Machine Services
A device operator provides inspection, handling or maintenance services to a customer. A TrustObject
binds the device version and service commitment, while the evidence graph links maintenance
qualifications, calibration, task logs and acceptance. The policy checks the requested purpose and
operating scope. A separately authorized on‑site adapter starts a permitted task only after
current‑authority and local safety checks pass, then submits completion evidence.
The protocol handles task‑level authorization and audit. Emergency stops, real‑time motion control and
clinical or other safety‑critical judgments remain in local systems with the appropriate safeguards;
chain finality cannot replace safety mechanisms. Tests exercise network outages, lost communication, key
compromise and duplicate commands, measuring unauthorized actions, time to stop on failure and log
completeness. Thresholds follow the risk assessment for the specific device.
Devices and maintenance qualifications use their own NFT or credential types. Approved machine‑service
fees and node bonds can connect to the $RWAIX module. Device financing or income participation requires
a separately designed instrument. Insufficient token balances must not prevent emergency stops, rescue
or other necessary safety actions.
19 A Trusted Collaboration Path Across Applications
The following is a proposed cross‑application extension after initial NFT validation, not a description
of a live service. A design company presents credentials for its organizational qualifications, and its
authorized designer presents credentials for their project role and authority. The relying party checks
the issuer, subject binding, purpose and current status. A creator licenses specified versions of a
collection of materials to the company solely for design generation within the agreed project, term and
territory. The licence defines permitted uses of outputs and excludes sublicensing and model training.
The materials' NFT references their versions and licence documents; it does not automatically transfer
copyright. The company then delegates authority to an Agent with limits on tools, compute providers,
tasks, duration and a budget inclusive of fees. The Agent may choose only processing paths permitted by
the licence and submit tasks to an approved compute provider. After rechecking the licence, delegation
chain and current status, the executor reserves shared budget capacity and binds the task, input digest
and run identifier. Reuse across industries occurs through common object, evidence and authorization
interfaces; qualifications, copyright and compute facts still require their own verification.
After processing, the system links the materials' versions, licence, model and configuration, execution
evidence and output digest into a provenance record, producing a TrustReceipt under the policy. The
receipt describes the relationship between evidence and rules; it does not establish originality,
non‑infringement or the correctness of AI outputs. Smart contracts cannot replace agreed sampling, human
review and customer acceptance. Acceptance creates payable or refund records, while every movement of
funds still requires separate approval by the authorized funds‑control party, with payment and receipt
of funds recorded separately. If the creator or company revokes a licence or delegation under the
applicable agreement, new processing and uses within the protocol must be rechecked against the
effective time and required status freshness rather than rely on an old receipt. Revocation does not
automatically erase completed processing, historical evidence, output‑use rights already in effect or
prior payments, nor does it automatically discharge obligations already incurred. Deletion of copies and
subsequent use of outputs follow the applicable licence and rules; the platform cannot guarantee
prevention of misuse outside the protocol.
In the workflow above, customer service charges and network fees are quoted and reconciled separately. If
$RWAIX is selected to pay approved network fees, the request binds a specific quote, payment asset,
maximum debit and payee. Even where the compute facility has DCNFT investors, their rights depend solely
on that facility's series documents and actual distributable cash. Licensor compensation, compute
charges, network fees and node rewards are not automatically interchangeable and do not establish a
fixed exchange relationship between DCNFT and $RWAIX.
When this example is recorded under the transaction reference specification, the contractual
relationships among the company, creator and compute provider are each bound to a tradeId. Licensing,
computation and network fees have separate obligationId values connected through linking fields. The
Agent's parent budget constrains the sum of the subordinate obligations. Delivery of materials,
computation results and customer acceptance each create a separate event. Partial acceptance creates a
payable only for the accepted scope; a dispute preserves the evidence and amounts of the affected
obligations rather than labeling the entire chain as wholly successful or wholly failed.
20 A Roadmap for Future Technology Evolution
The technology roadmap develops composable capabilities for collaboration. Near‑term delivery focuses on
selected standards and a functioning reference implementation; medium‑term validation addresses
collaboration across institutions, applications and different trust roots; long‑term research explores
stronger privacy, verifiable computation, edge autonomy and cryptographic migration. Stages are defined
by evidence and entry conditions rather than preset dates promising capabilities that have not yet been
implemented.
The company’s NFT transactions are the planned initial implementation entry point, with seven subsequent
extension domains retained. Initial independent validation selects three profiles with identifiable
responsible parties: NFT transactions; work provenance and licensing; and institutional qualifications
and Agent delegation. Compute delivery follows in a later phase after its facility, metering, customer
and funds conditions are established. Each new scenario identifies reused object, evidence and authority
mechanisms before specifying additional domain observations and rules. Generality is tested by whether
evidence can be transferred safely with few changes to the core.
Dual‑token development follows the technical stages. The foundational stage uses test assets with no real
funds to validate registration, fees and budget conservation. The pilot stage applies separate entry
conditions to service launch, DCNFT issuance and $RWAIX distribution. Only the expansion stage evaluates
additional asset types and networks. Unapproved supply, release or incentive parameters do not enter
production. Scaling across applications depends on eligible services and external demand, rather than
token appreciation or new funding used to subsidize earlier commitments.
20.1 Portable Identity and Continuously Checked Permissions
Moving from one‑time verification to trust relationships that can be checked continuously requires
connecting credential status, delegation chains, key recovery and authorization before execution.
Near‑term work fixes verifiable‑credential and status profiles and supports identifiers separated by
purpose; medium‑term work tests issuance across institutions and independent verification. Long‑term
research examines combining proofs of qualifications without exposing the complete graph of identity
relationships, while preserving revocation and traceable accountability. [S1–S3]
20.2 Privacy‑Preserving Evidence Composition
Minimum disclosure for a specified purpose is foundational; selective disclosure and zero‑knowledge
proofs apply to precisely defined propositions. Near‑term work first implements minimum disclosure under
a fixed credential suite and runs separate proofs of concept for bounded predicates such as
qualification thresholds, licence scope and specified status. Additional proof suites enter deployment
profiles only after passing tests. Medium‑term work evaluates proof composition across issuers and
correlation risks in status queries. Long‑term research examines verifiable policy execution and
lower‑cost proof composition, measuring proof generation, verification, data availability and privacy
leakage separately. Concealing inputs does not establish their truth. [S2–S3]
20.3 Constrained Collaboration Between People and Agents
The long‑term role of Agents includes discovery, negotiation and execution, but their actions must be
authorized by an identified principal. Near‑term work uses short‑lived capabilities, shared budgets,
human approvals and durable idempotency records. Medium‑term work tests subdelegation among multiple
Agents and tasks across organizations, constraining expansion of authority through delegation layers and
duplicate payments. Existing agent‑transaction authorization protocols, including AP2, may be studied as
adaptation targets using the authorization interfaces of an explicitly identified version. Any
compatibility claim fixes the specific version and testing scope; signed authorization and actual
transaction outcomes are verified separately. Delegation between Agents is a proposed RWAIX extension
and is outside the scope of the current AP2 v0.2 specification. [S17]
20.4 Linking Provenance Across Content, Data and Computation
For generative content and data collaboration, the protocol links input versions, licences, processing
environments, output versions and acceptance records. Content‑provenance standards can help record
signed provenance and processing history, while models such as ODRL can express usage rules. Provenance
records do not determine content truth or copyright ownership, and expressing rules does not
automatically enforce data restrictions. Long‑term research explores selectively disclosed provenance
chains and verifiable processing while retaining independent judgments about data controllers, licences
and task correctness. [S15–S16]
20.5 Physical Devices and Edge Collaboration
Machine services connect device control, maintenance qualifications, short‑lived authority and
operational evidence. Near‑term work collects events through controlled device gateways; medium‑term
tests cover disconnection, key rotation, conflicting sensor readings and reconciliation after recovery.
Offline authority must define acceptable status staleness, separately preallocated quotas and permitted
actions. High‑risk operations pause when sufficiently fresh status is unavailable. After connectivity
returns, reconciliation precedes release or replenishment of quotas. On‑chain protocols record
commitments and authority and support subsequent verification; real‑time safety interlocks remain in
appropriately validated local control systems. The scope of remote attestation depends on the specific
measurements and trust roots. [S14]
20.6 Cryptographic Agility and Long‑Term Verifiability
Long‑lived identities, rights and evidence need to support migration between cryptographic schemes.
Near‑term work records proofSuite, keys and implementation versions while preserving historical
verification materials. Medium‑term work evaluates the message size, latency, and account and chain
compatibility of new signature suites in test environments. Migration to post‑quantum algorithms
involves dependencies and lifecycles throughout the system and requires a migration plan based on the
threat model and standards. Citing NIST standards or using a particular algorithm does not establish
end‑to‑end quantum resistance for the system. [S18–S19]
Stage
Deliverable Capabilities
Basis for Advancing
Core build
Fixed schemas, NFT bindings, credential status, PolicyDecision, TrustReceipt and independent
executors; two verification implementations
Consistent test‑vector results; specified cases of unauthorized action, replay and use after
revocation are blocked; key‑recovery and failure drills are complete
Joint pilot
Three profiles led by NFT transactions; independent institutions, minimal disclosure, shared
budgets, evidence export and migration
External parties can review results; reports cover privacy, failures, human intervention and
end‑to‑end costs
Extended research
Extend to compute and remaining domains under their own conditions; study composed proofs,
cross‑domain authority, edge autonomy and cryptographic migration
Security propositions, comparative experiments and applicability boundaries for each
capability; deployment expands only after new capabilities pass review
21 Minimum Reference Implementation and Reviewable Deliverables
The minimum implementation planned for the next engineering stage would use one approved and selected
smart‑contract test network, one fixed signature and hash configuration, object‑registration and state
contracts, off‑chain credential and evidence storage, a deterministic policy engine, an indexing service
and exportable verification tools. The basic trust path is validated before adding cross‑chain
operations, complex zero‑knowledge proofs and economic incentives, preventing the number of dependencies
from obscuring core protocol issues.
Planned engineering deliverables include protocol schemas, object and state contracts, a signature‑domain
specification, a reference verifier, policy rules and their test vectors, an adapter SDK, a deployment
manifest and a recovery manual. The Policy engine executes constrained rules rather than arbitrary
untrusted code, with defined resource budgets, dependency‑depth limits, timeouts and treatment of
unknown fields. A policy upgrade produces a new digest; issued receipts retain their original version.
Two independent verification implementations should be able to import the same authorized evidence
package and, under the same snapshot and configuration, produce identical predicate results, conclusions
and reason codes. Deidentified test vectors, expected outputs and failure cases can be published, while
sensitive evidence uses equivalent verification procedures in a controlled environment. Publishing
interface names or a demonstration video alone does not establish interoperability.
The reference flow is: resolve the object and version; validate context, challenge and deadline; verify
credential signatures, issuer authority and subject bindings; resolve the status snapshot and evidence
graph; evaluate the policy predicate by predicate; issue a TrustReceipt; and have an independent
executor recheck authority and status before executing. Any missing mandatory condition produces an
explicit denial or indeterminate result rather than automatically fabricating evidence.
Subsequent engineering deliverables should include proposed schemas for TokenRegistry, RightsBinding,
FeeQuote, FeeReceipt, BondRecord and RewardClaim, each with permissions, state transitions and test
vectors. The registry fixes network and asset identifiers; rights bindings reference series documents;
fee modules distinguish quotes, reservations, payments and refunds; bond and reward modules distinguish
eligibility, disputes, approval and completion. Business identifiers connect the three ledger
categories, which can each be exported and reconciled independently.
Further planned deliverables for the transaction specification include machine‑readable schemas for
TradeEnvelope, TradeEvent, AcceptanceRecord, DisputeRecord and ConformanceManifest, state‑transition
tables, an error‑code dictionary, unit and precision rules, an extension registry and
requirement‑by‑requirement test vectors. Field types, required fields and compatibility rules must be
frozen before an interoperability candidate release. The field lists in this whitepaper are design
contracts and do not substitute for these implementation materials.
The deliverable scope described above, including a test network, independent implementations and
persistent services, remains a subsequent engineering target. The current prototype provided in Section
26 is limited to a single browser session. It performs actual SHA‑256 hashing and ECDSA P‑256 signature
verification, but does not yet provide production persistence, multi‑node concurrency, or connections to
real chains and payment rails. It does not replace the complete implementation materials specified in
this section.
Minimum Module
Deliverables and Acceptance Scope
Object and state contracts
Registration, versions, bindings, suspension, revocation, events and a permission matrix
Credential and evidence services
Fixed schemas, evidence commitments, access controls, retention and status synchronization
Policy and receipt tools
Deterministic evaluation, dependency graphs, reason codes, replay and signature verification
Collaboration and execution adapters
Independent authorization, idempotency, cumulative budgets, reconciliation, timeouts and
compensation
Independent implementations and pilots
Two verifiers; NFT transactions, work provenance/licensing, and institutional
qualifications/Agents; adversarial tests and recovery drills
22 Experiments and Acceptance Criteria for Technical Advancement
Claims of technical advancement require baselines under comparable conditions. Comparators should include
a centralized database with signed logs, a system directly combining NFTs and verifiable credentials,
existing attestation solutions and industry implementations without a universal core. Comparisons should
fix hardware, network, data volume, privacy level, evidence quality and security assumptions, counting
issuance, verification, storage, status synchronization, chain fees, recovery and manual dispute
handling in total cost.
Performance reports should present throughput, p50, p95 and p99 latency, failure rates, on‑chain cost,
client overhead and how these change as the evidence graph grows. Experimental versions, workloads,
sample sizes and pass criteria are registered in advance, with raw results or equivalent independently
verifiable records published. Complex proofs or verification by multiple parties may increase costs;
reporting only favorable peak figures is insufficient.
The minimum security threshold is deterministic output consistency across the published test set; none of
the specified cases involving invalid signatures, expiry, revocation, a wrong audience, replay or
unauthorized actions may produce executable authorization; and failure states must not silently become
acceptance. This threshold covers only the cases tested and does not guarantee the absence of unknown
attacks. Fuzzing, state‑machine property tests, independent security review and recovery drills jointly
determine readiness for actual deployment.
Industry pilots should report which core modules the three profiles reuse, which components require
customization, integration effort, verification errors and dispute‑handling costs. Adoption across
operators, successful evidence migration and successful replay after replacing a service provider are
important subsequent measures of whether market structure can change. Reduced code volume or a
successful integration demonstration does not directly establish market disruption.
Dual‑token acceptance testing covers mismatches between fees and rights, incorrect contracts or
precision, expired quotes, price jumps, concurrent overspending, unknown payment outcomes, duplicate
rewards, unauthorized penalties and duplicate bridge supply. Reports cover balance and supply
conservation per asset, register consistency, budget use, penalty appeals and service costs without
reward subsidies. Tests also examine lawful access paths for users who hold neither instrument, checking
that the economic modules do not incorrectly block open participation.
Acceptance testing for the transaction reference specification combines the rule tests in Section 5 with
exchange between implementations. Reports should identify the specification version, profile,
implementation role, passing and failing vectors, unsupported extensions and dependencies on external
facts. Business performance, transaction correctness, legal review and economic sustainability receive
separate conclusions. A verifier passing its tests does not certify the entire operating organization,
its token issuance or every commercial transaction.
The operating guide in Section 26 provides repeatable normal workflows and fault checks. Each formal
release records the code version, browser environment, cases actually executed and their outputs. Local
state checks, independent interoperability and production acceptance are reported separately. Displaying
a mapping to N01–N10 does not confer conformance certification.
Research Hypothesis
Experimental Design
Results to Report
Receipts can be checked across implementations
Two independent implementations run the same valid and invalid vectors
Predicate‑level agreement, reasons for differences and unsupported cases
Revocation constrains subsequent execution
Inject revocations, cache delays, chain reorganizations and concurrent execution
Erroneous‑authorization windows, pause behavior and residual risk
Evidence graphs improve dependency identification
Insert cycles, republication from common sources and known common‑control relationships
Detection rates, false‑positive rates, limits on detecting hidden collusion and overhead
Privacy preserves verifiability
Compare full disclosure, minimal disclosure and selected proof configurations
Disclosed fields, linkability, computation and status‑query costs
The core is reusable across industries
Three profiles use the same lifecycle and receipt interfaces
Core changes, adaptation effort, defects and governance differences
Agent safety enables greater automation
Adversarial tests for prompt injection, concurrent budgets, retries and replay
Unauthorized execution, budget conservation, human‑review volume and latency
23 Incorporating Company Technology and Deployment Responsibilities
The project plans to use the company’s disclosed NFT business as its first implementation use case, with
Agent Link Tech Ltd undertaking project and technology work under valid authority. The management
discussion for the first half of 2026 attributes operation of the existing NFT platform to Metaverse HK;
this does not establish that Agent Link operates that platform or that RWAIX is integrated in
production. Before integration, verify platform and contracting entities, interface permissions, modules
and code versions, contract addresses, licences and IP ownership, security reviews and interface gaps.
Operating an NFT business or having a listed‑company affiliation does not establish ownership of the
universal trust core described here. [S34–S35] Artwork shares, licences and any income arrangements in
existing NFT products require separate review against product and customer contracts; the single
indivisible synthetic order in Section 26 does not replace that review. [S35]
This whitepaper defines a proposed technical specification and validation plan. Existing company
components may be listed as reusable modules once verifiable version and ownership evidence is supplied.
New TrustContext, TrustReceipt, evidence‑graph, lifecycle‑policy and adapter components are disclosed
individually by development status. Production deployment, performance advantages, patent originality
and global leadership each require their own evidence; the protocol's vision cannot substitute for it.
For the initial NFT pilot, the actual platform operator, seller or licensor, customer, technology
provider and payment provider retain their respective contractual and authorization responsibilities.
Agent Link does not automatically acquire existing customer relationships, customer funds or licensing
rights. Later compute deployment continues to distinguish Agent Link, the facility SPV and local
FacilityOp; other domains identify parties by their factual, contractual, licensing and data
responsibilities. Technical administration does not automatically confer credential‑issuance
eligibility, legal agency, asset rights, customer‑funds custody or payment authority, or the status of a
securities issuer.
Figure 5. Proposed allocation of corporate and project responsibilities
The dual‑token design does not merge legal entities or responsibilities. The obligations of a DCNFT
series are proposed to be assumed by a verified and duly authorized facility SPV under the offering
route and series documents applicable and approved at that time. The issuer of $RWAIX, legal owner of
its treasury, distribution routes and management authority are determined separately; technology
operations do not automatically assign these roles to Agent Link. The candidate supply budget in Section
7.4 creates no sale, allocation or return commitment. Legal determinations, entity authority, funds
controls and outstanding original records are verified separately through the Release and SEC Filing
Preparation Review and Outstanding Materials Checklist, with definitive documents prepared from actual
transaction facts. The technical evidence package dated October 12, 2026 separately preserves the actual
specification, implementation and test identifiers and original records. A general TrustObject does not
change DCNFT’s proposed investment character or recast existing investment interests as ordinary
evidence.
DCNFT and $RWAIX must each be classified through analysis of their specific rights, sale and operating
arrangements, rather than by NFT, utility or governance labels. The parent's listing or project
disclosures do not replace the issuance conditions for either instrument, and protocol votes do not
replace valid company or SPV authority. Explicit mappings of applicable documents and technical versions
keep specifications, economic parameters and legal documents consistent; applicable arrangements are
reassessed after material changes. [S20–S21]
Once the necessary ownership rights and authority have been established, Agent Link may organize
reference implementations, test packages and pilot operations. Responsibilities for protocol
maintenance, independent assessment and dispute handling should be disclosed separately. Facility SPVs
bear the rights and obligations defined in their documents; a technical specification does not replace
participants' corporate authority or statutory responsibilities. Adoption by industry participants does
not automatically give Agent Link control over their assets, customer relationships or commercial
decisions.
The industry measures and billing assumptions in Section 25 are not revenue or cash flow of Agent Link, a
facility SPV or the listed parent, and do not promise DCNFT distributions or $RWAIX value. Actual
contracts must identify the service provider, delivery responsibilities, intellectual‑property rights
and receiving accounts. Parent‑level reporting also requires consolidation and elimination of
intercompany transactions under the applicable accounting rules. The demonstration in Section 26 creates
no token issuance, asset transfer or authority to dispose of real funds.
24 Open Evolution and the Path to Industry Adoption
RWAIX's standardization objective is to establish shared transaction rules that multiple parties can
implement, mutually recognize and maintain over time. The proposed stages are a reference‑specification
proposal, a frozen interoperability candidate, public testing and independent implementations, limited
industry pilots, and progression through an appropriate standards organization's process after actual
adoption. Each stage discloses its scope, issues and exit criteria. Meeting a technical threshold does
not automatically confer standards status or regulatory recognition.
Specification changes should produce version records through public proposals, issue discussion, impact
analysis, test evidence and explicit maintainer decisions. Material semantic changes enter a new version
with published transition periods and migration methods. Security issues may justify emergency pauses
with retained audit records. A governance charter defines maintainer composition, conflicts of interest,
appeals and decision‑making authority. Agent Link's initial maintenance role should not be described as
governance authority already accepted by every industry participant. The principles of due process,
consensus, transparency, balance and voluntary adoption described in RFC 6852 may inform governance
design. That document is Informational and does not confer standardization authority on RWAIX. [S27]
$RWAIX's limited parameter governance operates under its approved rules. Token votes do not automatically
determine specification conformance, assessment conclusions, corporate authority or DCNFT investor
rights. Standardization work, management of economic parameters and governance of facility contracts use
separate decision and change records. Testing and verification services should disclose their scope and
fees. Legally qualified implementers may build alternative services under approved licences, avoiding
the purchase of tokens as a route to technical certification.
Validation of commercial adoption should compare integration time, total verification and dispute costs
per transaction, successful evidence migration, engineering effort to replace a service provider and the
number of independent operators. Proposed revenue sources may include deployment, hosting, adaptation,
verification and support services; actual charges must correspond to delivered services and contracts.
Facility financing is arranged separately under DCNFT documents, while demand for $RWAIX is tested
through actual network services. Continued protocol operations must not be premised on token
appreciation or continually increasing subsidies.
The next deliverables for industry participation are a versioned specification and test package that
external implementers can try, together with a public interoperability report containing both successful
and failed cases. Whether the protocol is world‑class should be judged by comparative evidence of
performance, security, privacy, portability and adoption by multiple parties. The long‑term vision
continues to guide development; standards status is established through actual governance and adoption
processes.
Sections 25 and 26 connect the adoption path to testable commercial assumptions and an interactive
prototype. The sequence is to establish which delivered services users will pay for, compare total
integration, verification, dispute and migration costs, and then advance independent implementations and
limited pilots. Industry scale describes the demand environment; the prototype describes the current
executable scope. Neither replaces evidence of adoption by multiple parties or a standards
organization’s process.
25 Future Industry Scale and Verifiable Commercial Pathways
The expansion of digital commerce is reflected in digital transactions, investment in cloud and AI,
growth in machine services and demand for trusted identity access. RWAIX’s commercial proposition is to
provide technical services for collaborations with defined parties, contracts and evidence requirements;
it does not automatically charge every related transaction. The following indicators help identify
validation scenarios and customer problems, while retaining their observation years, forecast status and
coverage.
Industry transaction values, purchasing expenditure, equipment counts and identity‑coverage gaps are
different measures and cannot be combined into one total market. Revenue earned by industry participants
from goods, licences, data or compute also cannot be directly converted into protocol revenue,
parent‑company cash flow, distributable facility cash or token value. Commercial opportunities must be
tied to actual service buyers, contractual units, delivery capacity and verifiable billing events.
25.1 Sourced Industry Context
The table uses sources corresponding to the stated information dates and retained review records.
Historical estimates may be revised, and institutional forecasts are not future outturns. No uniform
tax, exchange‑rate or constant‑price basis is assumed where it is not disclosed. Digital services,
e‑commerce, cloud and AI measures overlap, as may the identity gaps; none are added together. [S28–S33]
Indicator and Source
Value, Year and Status
Scope and Interpretation
Digitally delivered service exports [S28]
About US$5.27 trillion in 2025; WTO historical estimate revised in July 2026
Worldwide cross‑border digitally delivered services, excluding the full range of domestic
transactions; not all e‑commerce or blockchain transactions.
Business e‑commerce [S29]
About US$28 trillion in 2024; UNCTAD update of May 2026
Business sales in 45 economies, defined by digital ordering; current prices and differing
tax bases, not worldwide protocol‑service revenue.
Public cloud services [S30]
Above US$1 trillion in 2026; IDC forecast of March 2026
Worldwide spending on SaaS, PaaS, IaaS and other categories; not wholly GPU compute or
trusted‑transaction service budgets.
AI‑related IT spending [S31]
About US$1.3 trillion in 2029; IDC forecast of August 2025
Applications, infrastructure and services; not a standalone Agent‑protocol market, and
overlapping with cloud expenditure.
Industrial robots [S32]
About 5 million in operation in 2025; forecast annual installations of 806,000 in 2029
Published by IFR in September 2026; the first is a stock and the second an annual flow. They
cannot be added or directly converted into paying customers.
Identity‑access gaps [S33]
2025 ID4D edition, mainly 2024 observations: about 800 million without official ID; at least
2.8 billion without government‑recognized online digital identity
World Bank coverage‑gap estimates, not separate additive populations or a forecast of paying
users. A wallet does not automatically provide legal identity.
25.2 From Addressable Scope to Annual Billing Assumptions
TAM should mean qualified buyers and billable units with demand for a specified technical service within
a fixed geography, period and service scope. SAM narrows that scope to the intersection of current
product capabilities, channels, languages and lawful delivery. SOM is then constrained by reachable
customers, conversion, implementation and support capacity, retention and funding. All three use the
same units and period. Where only the macroeconomic data above are available, a monetary project TAM
should not be forced, nor should an arbitrary market share be presented as an achievable target.
A, B and C below are three purely hypothetical configurations with no target year, used to examine
pricing structure and delivery scale. They are not accounting revenue, revenue forecasts, profit or
financing valuations. Customers are assumed to use the service for a full year; amounts are in USD,
exclude tax and have no costs deducted. Net price means the billing price after discounts, not profit
per unit. Annual technical‑service billings = customers × annual subscription fee + customers ×
max(annual eligible unique events per customer − included events per customer, 0) × net price per excess
event. The event volumes already exclude retries, replays, duplicate records and other non‑billable
events. Included allowances are deducted once, and the same service cannot be billed again across
applications.
An actual model should allow adjustments to customer numbers, activation months, churn, packages, net
prices, service credits and implementation capacity, with separate bridges for subscription and usage
billings, accounting recognition, collections and costs. A, B and C are not development stages or
promised customer scale. The tests are whether contracts support the event definition and whether
service can remain sustainable after cloud resources, support, disputes, channels and ongoing
maintenance costs. The model excludes customer transaction principal, facility financing and
distributions, token sales and price appreciation.
Case
Full year clients
Events per Customer / Included
Annual Subscription / Net Excess‑Event Price
Annual Technical‑Service Billings
A
100
1,000,000 / 100,000
USD 10,000 / USD 0.01
USD 1,900,000
B
1,000
5,000,000 / 1,000,000
USD 20,000 / USD 0.008
USD 52,000,000
C
5,000
10,000,000 / 2,000,000
USD 30,000 / USD 0.005
USD 350,000,000
25.3 Payers for the Initial NFT Business and Seven Extensions
The table presents proposed commercial‑validation paths, not signed customers or established industry
qualifications. The billing entity is the provider responsible for technical delivery under the
contract. NFT transaction consideration, platform commissions, licence consideration, goods payments,
data fees, compute charges and machine‑operating revenue remain with their respective rights holders and
contracting parties. Agent Link earns a corresponding technical‑service fee only where it has the
necessary rights and authority and performs the contracted service.
An initial milestone should produce both reviewable technical results and a basis for payment before
expansion is considered. The RWAIX brand does not automatically become a legal recipient of funds.
Consolidated reporting and freely available cash at the listed parent (ticker: MI) cannot be equated
with providers’ aggregate billings. Distributable facility‑SPV cash and DCNFT series interests are
calculated separately under the applicable documents. Actual demand to use $RWAIX likewise does not
imply price appreciation or revenue participation.
Use case
Technical Billing Entity
Payer
Candidate Billing Unit
Initial Validation Milestone
NFT trades
Authorized transaction‑workflow provider
Platform operator or contracted party
Platform integration / unique order check
One authorized order: binding, licence, delivery, acceptance and separate reconciliation;
consideration and commissions separately accounted
Identity
Identity integration or verification provider
Relying institution or sponsor
Institutional subscription / authorized check
Institution‑accepted credentials and revocation review; zero‑price demonstration
Content
Provenance and licensing‑workflow provider
Licensor or user platform
Work version / licensing workflow
Review rights chain, purpose and expiry rejection; separate creator consideration
Data
Controlled‑access and policy provider
Custodian or enterprise user
Dataset integration / authorized query
Admission, revocation and complete access logs for one synthetic purpose
Supply chain
Handover and reconciliation connector provider
Buyer, supplier or logistics party
Connected site / unique handover
Partial acceptance of one batch without duplicate handover accumulation
Agent workflows
Authorization and execution‑audit provider
Delegating organization
Workflow subscription / authorized task
Budget and authority conservation; unknown outcomes retain allowance
Compute
Contracted technology operator or verification provider
Resource provider or enterprise customer
Connected resource pool / accepted task
Reviewable delivery, acceptance and separate customer‑payment and network‑fee ledgers
Device services
Device‑identity and task‑adapter provider
Device operator or industrial customer
Device integration / authorized task
Out‑of‑scope commands rejected; local safety responsibilities defined
26 Technical Implementation and Eight Application Demonstrations
Interactive reference prototype: https://chatgpt.com/space/page_508562e10774819199303889a5033b9f . The
reference prototype defaults to a separate NFT transaction profile and retains identity, content, data,
supply‑chain, Agent, compute and device workflows, for eight scenarios in total. Users can switch
between Chinese and English, inspect signed events and export a review bundle. Identities, credentials,
delivery, payments and dispute decisions are synthetic. The prototype does not connect to the company’s
existing platform or a real chain, receive real funds, mint or transfer real NFTs, or execute real
device or GPU tasks.
The browser uses WebCrypto to perform actual SHA‑256 hashing and ECDSA P‑256 signing and verification.
Demonstration roles have separate session keys, but all remain under the control of the same browser;
they do not constitute independent institutions or production isolation. Signatures can check the
relationship between records and keys and detect tampering. They do not establish identity, copyright,
physical delivery or the correctness of AI results.
Figure 6. Actual synthetic NFT demonstration: one delivery accepted and simulated payment attributed,
with zero network fee
26.1 Observable Workflow and Separate Ledgers
The normal path is bind → commit → deliver → verify → accept → authorize → submit → reconcile → apply:
bind synthetic qualifications and roles; have both parties sign the same terms digest; have the provider
sign evidence for the current portion; check its digest and signature; obtain separate customer
acceptance; obtain separate funds authorization; then reserve and simulate submission, reconcile
receipt, and apply the receipt to the specified obligation. A TrustReceipt does not replace acceptance
or funds authorization. The identity scenario has zero customer payment and zero network fee and
completes after acceptance, without requiring token holdings or a meaningless payment. This sequence is
the chosen synthetic demonstration flow. It does not restrict a real contract from using approved
advances or installments; the real flow must separately define obligations, independent authority and
funds safeguards.
Each of the eight scenarios defines an adapterPolicy included in the termsDigest signed by both parties.
NFT transactions constrain the network, contract, tokenId, work digest, licence version and scope,
seller‑control claim and recipient; identity constrains qualifications and the relying institution;
content constrains the work version, territory and sublicensing; data constrains purpose, recipient and
query type; supply‑chain delivery constrains the batch and inspection; Agents constrain tools, payees
and subdelegation; compute constrains the challenge and output format; and devices constrain the task
and local safety permission. Verification actually compares delivery evidence’s domain fields with the
signed terms. Even when a replacement signature remains valid, out‑of‑scope evidence receives DENY and
DOMAIN_POLICY_SCOPE_MISMATCH. This checks consistency between synthetic inputs and explicit rules, not
the truth of real‑world statements.
Customer payments use USD_TEST and network fees use RWAIX_TEST. These are synthetic test units with no
conversion or redemption meaning, and are not displayed as real amounts using fiat‑currency symbols.
Each obligation retains its own obligationId, paymentAttemptId, limit and discharge records. Discharged
amounts, executed but unapplied amounts, and pending payments that may still execute occupy mutually
exclusive categories and collectively consume coverage. OUTCOME_UNKNOWN does not release reservations or
permit resubmission using another asset. The compute scenario only displays a rights reference to a
synthetic DCNFT series; it does not issue, mint or transfer DCNFT or allocate facility cash. RWAIX_TEST
only demonstrates $RWAIX’s proposed network‑fee function, not real token balances or market quotes.
The NFT transaction demonstration fixes one indivisible NFT, quantity 1 and exactly one portion, with
transaction consideration of 12000 minimum USD_TEST units at precision 2 and a zero RWAIX_TEST network
fee. The zero network fee illustrates that the initial NFT business need not issue $RWAIX; other
scenarios retain separate accounting for optional network charges. The NFT adapterPolicy binds network,
contract, tokenId, workDigest, licenceVersion, licenceScope, sellerControl and recipient, and fixes
copyrightTransfer=false. Changes to the copyright‑transfer flag or other constrained fields in signed
delivery evidence are rejected. Seller‑control and receipt records are synthetic claims; verification
does not replace real‑chain confirmation, copyright review or platform authority. No facility DCNFT
minting, financing or distribution occurs. The single indivisible object and zero network fee are
synthetic demonstration parameters, not a description of the structure, charges or legal classification
of all existing company NFT products.
26.2 Repeatable Operating Guide
Open the prototype in an environment supporting WebCrypto, select an application and start with “New
local run”. Use a fresh workflow for each fault, perform the action at the prerequisite state below, and
inspect the reason code, coverage and signed events. Compare actual results with the expectations below
and retain the records. “Implementation scope” identifies the implemented portion and exclusions for
each rule.
Action and Prerequisite
Repeatable Steps
Expected Observation
Normal path
The default NFT order has one portion; complete it with the main button. Advance to the next
portion only in two‑portion scenarios; identity ends at acceptance
Separate records for commitment, evidence, acceptance, funds authorization, execution and
discharge; distinct obligations remain separate
Tampering or missing evidence; delivery completed
Select “Tamper and verify” or “Hide required evidence”, then restore the signed evidence
Tampering is not allowed; missing evidence is indeterminate. Restoration requires
verification again, and an error does not become acceptance
Valid signature, wrong scope; delivery completed
Select “Valid signature, wrong scope” and inspect the newly signed evidence and reason code
The signature remains valid, but domain policy rejects it: DENY /
DOMAIN_POLICY_SCOPE_MISMATCH; no acceptance or payment authority is created
Revocation; before payment submission
Select “Revoke execution authority”, then attempt new acceptance, authorization or
submission
Current‑authority checks block new execution; existing records and payments are not erased
Unknown outcome; before first submission
Select “Next outcome unknown”, submit, inspect the separate ledgers, then reconcile
OUTCOME_UNKNOWN retains coverage; simulated receipt confirmation remains unapplied, and
discharge is recorded only after apply
Duplicate or alternate asset; a payment attempt exists
Select “Retry original instruction”, then “Try another payment asset”
The original instruction reuses its existing attempt without a second payment; an
unauthorized asset change is rejected
Dispute; transaction terms committed
Select “Dispute this portion”, try to advance, then simulate review and resume
New execution and receipt application pause for that portion; history and coverage remain.
Resumption appends a record without an automatic refund
Evidence export
Export the review bundle under “Implementation scope”; copy or download JSON
A snapshot, events, public keys and scope disclosures, without private keys; export alone
does not establish successful third‑party review
26.3 Delivery Gates from Browser Prototype to Limited Pilot
The first stage fixes a reviewable browser version, synthetic data, operating scripts, export format and
results for each case. Current transaction state exists only within the session and is cleared by
refresh or a new run. At most, language and application preferences may sync through the host, not
transaction ledgers or private keys. The prototype does not implement production persistence,
cross‑process recovery, distributed concurrency, independent institutional key control, real chains and
payment rails, or verification of real identity and asset rights. It makes no claim to full N01–N10
certification.
The archived local Node/WebCrypto test record reports 50 of 50 tests passed, with no failures. Browser
records cover all eight scenarios and NFT cases in which unknown payments retain coverage, retries reuse
one attempt, asset switching is rejected, disputes block receipt attribution, and validly signed
out‑of‑scope evidence is denied. Chinese and English layouts showed no horizontal overflow at viewport
widths of 320 and 736 pixels; this is browser layout testing, not physical‑device or
production‑performance certification. For one exported NFT review bundle, the same‑lineage offline
verifier passed all 36 signature, digest, event‑chain and coverage checks. It is not a second
independent protocol implementation and does not verify real‑world rights. N01–N08 and N10 remain
PARTIAL, while N09 is LIMITED_TEST. Records are collected in the technical evidence package dated
October 12, 2026, retaining the original code identifiers, source, test results and coverage manifests.
October 11 is the prior task‑record date; the original test JSON contains no independently authenticated
execution timestamp. October 12 identifies compilation and review only, not a new test run or a change
to the code or original records. Test counts do not replace independent security review or full
conformance certification.
The next stage freezes machine‑readable schemas, role permissions and test vectors; adds persistent
intents, recovery, concurrent budgets and sandbox adapters for real external interfaces; and completes
independent security review. Two independent implementations then exchange the same evidence packages
and report successes, failures and unsupported cases. Browser serialization and signatures from multiple
local roles cannot replace this stage’s isolation, durability and interoperability validation.
Before a limited industry pilot, establish actual contracting parties, industry qualifications, data use
and asset rights, together with separate acceptance, funds authorization, complaints, disputes and exit
arrangements, and register technical and commercial measures in advance. The number of browser
demonstrations does not change the initial independent‑validation route: NFT transactions; work
provenance and licensing; and institutional qualifications with Agent delegation. Compute is a
subsequent extension. Pilots then test the Section 25 model against actual delivery, payment,
maintenance cost and portability; wider deployment and standardization follow Section 24.
Reference Standards Technology and Regulatory Sources
This document is dated 12 October 2026. The standards, existing‑technology and regulatory sources below
are listed on the basis of retained review records to define component capabilities and comparison
baselines. Original publication dates and applicable versions are preserved separately and should be
rechecked when adopted. A citation does not imply endorsement of RWAIX by a standards body or
certification of this protocol. Each compatibility profile must fix the applicable versions and pass the
relevant tests. S20 is a Commission interpretation; S21 is a nonbinding SEC staff statement. Neither
citation represents project‑specific approval. S22 to S27 inform requirement levels, business‑document
mappings, legal boundaries and open governance. Model laws depend on local enactment and do not take
effect merely through citation. S28 to S33 provide industry context. Their periods, forecast status and
statistical boundaries appear in Section 25; they are not added into an addressable project market.
S1 W3C DID Core v1.0
S2 W3C Verifiable Credentials Data Model v2.0
S3 W3C Bitstring Status List v1.0
S4 ERC‑721 — Non‑Fungible Token Standard
S5 ERC‑1155 — Multi Token Standard
S6 ERC‑5192 — Minimal Soulbound NFTs
S7 ERC‑5484 — Consensual Soulbound Tokens
S8 ERC‑1271 — Standard Signature Validation Method for Contracts
S9 ERC‑4337 — Account Abstraction Using Alt Mempool
S10 Ethereum Attestation Service — Official SDK
S11 Sign Protocol — Official Evidence Layer Product Documentation
S12 EIP‑712 — Typed structured data hashing and signing
S20 SEC, Application of the Federal Securities Laws to Certain Types of Crypto Assets and
Certain Transactions Involving Crypto Assets, Release 33‑11412
S21 SEC Division of Corporation Finance, Division of Investment Management and Division of
Trading and Markets, Statement on Tokenized Securities
S22 RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
S23 RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
S24 OASIS Universal Business Language Version 2.4
S25 UNCITRAL Model Law on Electronic Transferable Records (2017), with Explanatory Note
S26 UNCITRAL Model Law on Automated Contracting (2024), with Guide to Enactment
S27 RFC 6852 — Affirmation of the Modern Paradigm for Standards
