CoCa Global Joint Foundation

No. 67-3, Tan Gong South Road, Weicang Street Jiaxing County Zhejiang Province China foundation@utxocp.cn cocapetroleum@gmail.com

Institute of Web3.0 Hong Kong

zblei@ust.hk

CoCa Global Joint Foundation

yang.fanyin0101@gmail.com

W3C-UW2ICG

monica@utxocp.cn

Hong Kong Ronghua International Group Co., Ltd.

1917351588@163.com

Internet Individual Submission (DNSOP DISPATCH discussion planned) UTXO DNS PRN regulatory compliance audit MPC vLEI AgentPolicyEnvelope All domain names used in examples throughout this document use ".test" in accordance with RFC 2606. In actual deployments, ".utxo" is used. This document specifies the UTXO Domain Name System (UTXO6-DNS), a decentralized naming protocol that maps .utxo domain names to blockchain UTXO (Unspent Transaction Output) endpoints and generates verifiable IPv6 Interface Identifiers (IIDs) using Verifiable Random Functions (VRFs). The base protocol defines a new DNS RR type (UTXO, code 260), an EDNS0 option for capability discovery, and fallback mechanisms to coexist with legacy DNS, updating RFC 1034, RFC 1035, and RFC 7217. Additionally, this document defines an optional compliance overlay --- the Penetrating Regulation Node (PRN) extensions --- that can be deployed by regulated financial institutions to meet AML/CFT requirements, provide audit trails, and verify legal entity identities using GLEIF vLEI credentials. The PRN extensions include optional regulatory attributes in UTXO RRs, a new PRNAUDIT RR type for daily audit summaries, a RESTful API (PRN-API) for regulatory dashboards, a 2-of-3 MPC threshold signature framework for audit integrity, and native vLEI integration. This document also describes a transaction lifecycle compliance enforcement model (AnteHandler) and an application-layer policy format (AgentPolicyEnvelope) for declarative authorization. The PRN extensions are privacy-preserving (only Merkle roots and aggregated statistics are shared), decentralized (no central authority), and verifiable (audit summaries are jointly signed by independent auditing firms). This document is published as an Experimental specification. It is not an IETF standard and does not represent IETF consensus. It is intended for informational purposes, to facilitate implementation experience, and to support early discussion within the DNSOP working group. See for details. Note: The AgentPolicyEnvelope JSON Schema (Appendix I) and the AnteHandler compliance enforcement model (Section 4) are application-layer constructs provided as informative examples. They are not on the IETF standards track and are not subject to IETF consensus. Their inclusion in this document is intended to facilitate interoperability of experimental deployments.

Document Status: Experimental This document is published as an Experimental specification. According to , the "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work. This document is not on the IETF standards track. It does not represent IETF consensus, nor does it imply any endorsement by the IETF, the IESG, or any IETF Working Group. It is an individual submission published for experimental and informational purposes only. The base protocol described in Section 2 is intended to form the basis for future standardization; the PRN extensions in Section 3 and the compliance enforcement model in Section 4 are experimental. Readers are advised that the mechanisms described in this document have not been subject to broad interoperability testing, security review, or IETF Working Group scrutiny. Deployment should be undertaken with caution and after appropriate risk assessment.

Introduction

Background and Problem Statement Traditional DNS maps names to IP addresses. However, modern digital assets (cryptocurrencies, tokenised real-world assets, NFTs) are identified by opaque blockchain addresses that are not routable, not human-friendly, and lack a standardised binding to the Internet's naming and addressing layers. This forces each blockchain application to build its own messaging overlay. Meanwhile, IPv6 provides a 128-bit address space with a 64-bit Interface Identifier (IID) that is programmable by design -- but current IID generation (RFC 7217) uses only local device information, not asset ownership. This document defines the UTXO6-DNS protocol, which bridges that gap by allowing a domain name to resolve to a UTXO endpoint identifier, and by providing a method to generate IIDs directly from UTXO ownership using Verifiable Random Functions (VRF, RFC 9381). The system allows a human-readable '.utxo' domain name to resolve to a routable IPv6 address that is cryptographically owned by the UTXO holder. Furthermore, for adoption by regulated financial institutions, the protocol is extended with the Penetrating Regulation Node (PRN) overlay to meet AML/CFT regulations, provide auditable transaction records, and verify legal entity identities. These extensions are optional and do not affect the core resolution protocol.

Scope This document defines:

• The base UTXO6-DNS resolution protocol, including VRF-based IID generation, the UTXO RR type, and basic EDNS0 support (Section 2).
• Optional PRN extensions: regulatory attributes in UTXO RRs, the PRNAUDIT RR type, EDNS0 option for PRN, PRN-API, MPC audit framework, vLEI integration (Section 3).
• A transaction lifecycle compliance enforcement model (AnteHandler) that PRN nodes MAY implement (Section 4).
• An informative JSON Schema for AgentPolicyEnvelope, an application-layer policy format (Appendix I).

This document does not specify payment processing, smart contract execution, or blockchain consensus mechanisms. The AgentPolicyEnvelope format is provided as an informative example and is not an IETF standard.

DNSOP Working Group Discussion This document is intended to facilitate early discussion within the DNS Operations (DNSOP) working group. The authors plan to present this proposal in the DNS DISPATCH portion of an upcoming DNSOP meeting, with the goal of collecting feedback on:

• Interest in adopting the base UTXO6-DNS protocol as a standards-track document.
• Whether the PRN extensions are within the DNSOP charter's scope.
• Implementation and deployment considerations.

DNSOP working group mailing list:

Terminology

UTXO

Unspent Transaction Output -- a fundamental unit of value in blockchain systems.

IID

Interface Identifier -- the lower 64 bits of an IPv6 address.

VRF

Verifiable Random Function -- a cryptographic function that produces a random-looking output and a proof that can be verified.

SLAAC

Stateless Address Autoconfiguration -- the IPv6 mechanism for address generation.

PRN

Penetrating Regulation Node -- a node deployed by a regulated entity to implement compliance functions.

vLEI

verifiable Legal Entity Identifier -- a W3C Verifiable Credential for legal entity identity.

MPC

Multi-Party Computation -- cryptographic protocol for threshold signing.

AgentPolicyEnvelope

A JSON structure containing declarative authorization policies for a .utxo domain (e.g., spending limits, asset whitelists). This is an application-layer construct defined informatively in Appendix I.

AnteHandler

A pre-block validation pipeline that enforces compliance checks before a transaction is included in a block.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Base UTXO6-DNS Protocol

IPv6 Interface Identifier Generation from UTXO

VRF-based IID Derivation A UTXO owner generates a stable, verifiable IID for any network prefix using: IID = VRF(UTXO_privkey, Prefix || UTXO_TXID || OutputIndex || Nonce)[64] where:

• VRF is a Verifiable Random Function as defined in (e.g., ECVRF-EDWARDS25519-SHA512).
• UTXO_privkey is the private key that controls the UTXO.
• Prefix is the 64-bit IPv6 network prefix received in a Router Advertisement.
• UTXO_TXID is the 256-bit transaction hash of the UTXO.
• OutputIndex is the index of the UTXO in that transaction (0--65535).
• Nonce is an optional 32-bit value for privacy rotation.

The output IID MUST be treated as a 64-bit integer and used for SLAAC. The global/local bit (u=1) and multicast bit (g=0) SHOULD be set according to RFC 4291.

Verification of IID Given the UTXO public key, the same input parameters, and the VRF proof, any party can verify that the IID was generated by the UTXO owner. Verification does not require blockchain access, enabling offline validation.

Relationship with RFC 7217 and RFC 4941 This construction follows the pattern of but replaces the secret key with a UTXO private key and adds VRF proof. The Nonce corresponds to RFC 4941 temporary addresses. This updates RFC 7217 by adding a new allowed secret source.

UTXO Resource Record Type This document defines a new DNS resource record type, UTXO, with code 260. The RDATA format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | EndpointLen | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Endpoint Identifier (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VRF Proof (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields:

1. Version (1 octet): currently 1.
2. EndpointLen (1 octet): length of the Endpoint Identifier.
3. Flags (1 octet): bit 0 = LegacyIPPresent (if set, an A/AAAA record follows the VRF proof).
4. Reserved (1 octet): MUST be zero.
5. Endpoint Identifier: a byte string identifying a blockchain endpoint. For .utxo domains, this MUST be CBOR-encoded as specified in .
6. VRF Proof: optional proof for verification.

If the LegacyIPPresent flag is set, an A or AAAA record is appended after the VRF proof.

EDNS0 Option for Base Capability Discovery An EDNS0 option (code TBD, suggested 16) is defined for clients to indicate UTXO-DNS support. The option follows the format defined in . The option data is 2 octets: version (1) and reserved (0). Servers SHOULD echo it.

Resolver Behaviour and Fallback A UTXO-DNS recursive resolver MUST implement the following logic for queries of type UTXO (260) or ANY: if domain ends with ".utxo" or ".utxo.<region>": try: result = blockchain_query(domain, timeout=2s) if result.valid: return response with UTXO record + proof except (timeout, not_found, invalid_proof): if qtype == UTXO or ANY: return NXDOMAIN or error else: return legacy_lookup(domain) else: return legacy_lookup(domain) For A/AAAA queries, the resolver MAY first attempt blockchain resolution to get a legacy IP from the UTXO record's LegacyIPPresent field; if that fails, it falls back to the legacy DNS. For type UTXO, fallback is NOT allowed.

Integration Considerations

• Namespace: only '.utxo' and '.utxo.<region>' trigger UTXO resolution.
• Cache: TTL of UTXO records SHOULD be min(legacy TTL, blockchain finality) (recommended 300 seconds).
• Fallback security: clients MAY enforce UTXO-only for certain domains.

PRN Compliance Extensions

Overview A PRN node is an optional compliance overlay. A regulated entity MAY deploy a PRN node associated with one or more .utxo domains. The node performs:

• UTXO6-DNS resolution.
• vLEI verification for counterparties.
• Maintenance of a daily Merkle tree of transactions.
• Generation of daily audit summaries signed by the node and then by an audit committee via MPC.
• Publication of summaries via DNS (PRNAUDIT RR) and PRN-API.

These extensions do not modify the base resolution protocol.

DNS Resource Record Extensions

Optional Attributes in UTXO RR The UTXO RR presentation format supports optional attributes. This document defines:

prn-endpoint

URI for the PRN-API.

audit-group

Audit committee identifier.

policy

A URI (e.g., ipfs://... or https://...) pointing to an AgentPolicyEnvelope JSON object. The resolved content MUST conform to the informative schema defined in . Example: "policy=ipfs://QmX...".

regulatory-jurisdiction

ISO 3166-1 alpha-2 country code.

stablecoin-whitelist

Pipe-separated list of allowed stablecoins.

vlei-did

vLEI credential DID.

Example: example.test. 3600 IN UTXO ( "chain=ethereum" "address=0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb0" "prn-endpoint=https://prn.example.com/api/v1" "audit-group=hk-audit-group-01" "policy=ipfs://QmXyZ..." "regulatory-jurisdiction=HK" "stablecoin-whitelist=USDC|USDT|HKDA" "vlei-did=did:vlei:gleif:984500B9D5C8" )

PRNAUDIT RR Type A new RR type PRNAUDIT (suggested code TBD1) stores daily audit summaries. RDATA: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Date (YYYYMMDD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (must be 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Merkle Root Hash (32 bytes) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + MPC Signature (64 bytes) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Audit Period Indicator | (remaining bytes, if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Date: 4-byte unsigned integer YYYYMMDD.
Merkle Root: SHA-256 hash of transaction tree root.
MPC Signature: 64-byte Schnorr multi-signature.
Audit Period: 0=DAILY, 1=MONTHLY, 2=QUARTERLY, 3=ANNUAL. PRNAUDIT RRs MAY be stored at the domain or at _audit.example.tast.

EDNS0 Option for PRN A new EDNS0 option (code TBD2) is defined. The option data MAY contain sub-options: 0x01 (request PRNAUDIT), 0x02 (request vLEI status).

PRN-API Specification The PRN-API is a RESTful interface exposed at the prn-endpoint. Authentication MUST be OAuth 2.0, mTLS, or HMAC-SHA256. When using TLS, MUST be enforced.

Core Endpoints

• GET /health -- operational status
• POST /vlei/verify -- verify vLEI credential
• GET /audit/daily-summary?date=YYYY-MM-DD
• GET /audit/monthly-report?year=YYYY&month=MM
• POST /compliance/check -- check transaction compliance
• GET /registry/lookup?domain=.utxo

Full OpenAPI specification is provided in .

WebSocket Streaming PRN nodes MAY expose wss://... for real-time messages (transaction, alert, health, audit_complete).

MPC Audit Framework

Threshold Signature Protocol (GG20) Three independent auditing firms operate MPC nodes. The committee public key is known. The protocol produces a 64-byte Schnorr signature (R and s).

Daily Audit Summary Generation Each PRN node maintains a Merkle tree of H(tx_hash || from_domain || to_domain || amount || timestamp). At day end, it computes the root, aggregates metrics, signs with its HSM key, broadcasts to the committee, and stores the multi-signed summary. Full transaction data SHOULD be retained for at least seven years.

Aggregated Reports Monthly, quarterly, and annual reports are derived from daily summaries using Merkle trees of daily hashes, each with a fresh MPC signature.

vLEI Credential Integration

Verification Flow PRN nodes verify vLEI by fetching https://api.gleif.org/api/v1/vlei/{lei} (see ), verifying the response signature, checking expiration and revocation, and optionally confirming domain linkage.

Caching Requirements To avoid overload, PRN nodes MUST cache with max TTL 300s, webhook invalidation, minimum 10k entries, LRU eviction.

Regulatory Dashboard Integration Dashboards can integrate with any PRN node using the PRN-API. A reference open-source implementation is available.

Transaction Lifecycle and Compliance Enforcement

Overview PRN nodes implementing transaction enforcement MAY perform a set of pre-block validation checks --- collectively referred to as the AnteHandler --- before a transaction is included in a block. These checks are independent of the DNS resolution protocol and are provided as an informative compliance model. The AnteHandler enforces application-layer policies defined in the AgentPolicyEnvelope (see ). If any of the following checks fail, the transaction MUST be rejected (i.e., it is not included in the block). This is a pre-block interception, not a post-audit check.

AnteHandler Checks The AnteHandler consists of the following seven mandatory checks:

#	Check Name	Description
1	KYCgate	Verify that both the sender's and the receiver's vLEI credentials are active (not revoked, not expired).
2	Sanctions	Check that the sender and receiver do not appear on any applicable sanctions lists (L1/L2/L3 entities).
3	TravelRule	Verify that beneficiary disclosure information is present and compliant with FATF Travel Rule requirements.
4	ThresholdFlag	Ensure that the transaction amount ≤ per_tx_limit as specified in the AgentPolicyEnvelope.
5	VelocityFlag	Ensure that the cumulative transaction amount for the sender for the current day (UTC) ≤ daily_limit as specified in the AgentPolicyEnvelope.
6	RoleGate	Verify that the initiating AI Agent has been properly authorized by the Legal Entity (as represented by the vLEI credential).
7	AgentPolicyGate	Verify the digital signature on the AgentPolicyEnvelope, confirm that the policy has not expired, and ensure that the transaction conforms to all constraints in the policy (e.g., allowed_assets, whitelist).

Enforcement and Auditing Transactions that pass all AnteHandler checks are forwarded to the consensus layer for inclusion in a block. Transactions that fail any check are rejected immediately; they are not broadcast to the consensus layer and do not incur transaction fees. PRN nodes SHOULD log all AnteHandler decisions (both accepted and rejected) with sufficient detail to support later audit. The logged data SHOULD include the transaction hash, the check that failed (if any), and a timestamp. These logs MAY be included in the daily Merkle tree summarised by the PRNAUDIT RR. Note: The AnteHandler model described in this section is provided as an informative example of how a PRN node might implement transaction compliance. It is not on the IETF standards track and is not subject to IETF consensus. Deployments MAY implement additional checks or omit checks as required by local regulations.

Security Considerations

Base Protocol Security

• Private key theft: if stolen, attacker can generate same IIDs. Mitigations: multi-signature, time-locks, HSMs.
• VRF strength: MUST use algorithms with at least 128-bit security (e.g., Ed25519 VRF).
• Privacy: address rotation via Nonce provides similar properties to RFC 4941; zero-knowledge proofs can be used for advanced privacy.

PRN Extensions Security Threats and mitigations (STRIDE model):

Category	Threat	Mitigation
Spoofing	Domain ownership forgery	vLEI + UTXO private key signatures
Spoofing	PRN node impersonation	mTLS + node certificates
Tampering	Audit summary alteration	MPC threshold signatures
Tampering	Transaction proof forgery	Merkle tree + ZK proofs
Repudiation	Domain registration denial	On-chain immutable logs
Information Disclosure	Domain owner privacy leakage	Stealth addresses
Denial of Service	Resolution DoS	Caching + fallback
Elevation of Privilege	Governance permission abuse	Multi-signature + timelocks

PRN nodes MUST implement rate limiting (1000 authenticated requests per minute). The PRN private key SHOULD be stored in an HSM meeting FIPS 140-2 Level 3 or equivalent.

Policy Integrity and Signature Verification PRN nodes that enforce AgentPolicyEnvelope policies MUST verify the digital signature on the policy before enforcing any limits. The signature SHOULD be generated using the legal entity's private key (the same key that controls the vLEI credential). PRN nodes MUST check that:

• The signature is cryptographically valid.
• The issued_at timestamp is not in the future.
• The expires_at timestamp has not passed.
• The domain field matches the domain being resolved.

Policy Fetching Risks Since the policy attribute is a URI (e.g., ipfs:// or https://), PRN nodes face the following risks:

• Data unavailability: the policy content may be unreachable. PRN nodes SHOULD implement caching and retry mechanisms. If a policy cannot be fetched after a configurable number of retries (e.g., 3 attempts), the transaction SHOULD be rejected.
• Tampering in transit: when using https://, TLS MUST be enforced (RFC 8446). When using ipfs://, content addressing provides integrity by default (the CID includes a cryptographic hash).
• Policy injection: malicious actors may attempt to serve forged policies. PRN nodes MUST verify the policy's signature against the vLEI public key before enforcement. Policies that fail signature verification MUST be discarded.

IANA Considerations IANA is requested to assign the following:

DNS RR Type for UTXO

Type: UTXO, Suggested value: 260, Reference: this document (Section 2.3).

DNS RR Type for PRNAUDIT

Type: PRNAUDIT, Suggested value: 65401, Reference: this document (Section 3.2.2).

EDNS0 Option for Base Capability

Option Name: UTXO-DNS, Suggested value: 16, Reference: this document (Section 2.4).

EDNS0 Option for PRN

Option Name: PRN-EXT, Suggested value: 65001, Reference: this document (Section 3.2.3).

Media Type application/prn-api+json

Type name: application, Subtype name: prn-api+json, Reference: this document (Section 3.3).

Note: Because this document is Experimental, IANA may defer assignment until a standards-track document requests them. Implementers should use these suggested values only in experimental/private deployments. AgentPolicyEnvelope JSON Schema: This document defines no new IANA registrations for the AgentPolicyEnvelope JSON Schema (Appendix I). The schema is provided as an informative example of an application-layer policy format. Should the community wish to standardize this format, the appropriate venue would be W3C or another organization focused on identity and compliance standards, rather than IANA.

Acknowledgements The authors thank Eric Vyncke (INT AD) for guidance on experimental status and the DNS DISPATCH process, Mohamed Boucadair for proposing the DNSOP DISPATCH presentation, and the DNSOP working group for the opportunity to present this work. The authors also thank GLEIF for the vLEI standard and API, and the broader IETF community for feedback.

IETF IETF IETF IETF GLEIF

Full List of Error Codes

Code	Name	Description
0	NOERROR	Successful completion
1	FORMERR	Format error
2	SERVFAIL	Server failure
3	NXDOMAIN	Domain name does not exist
4	NOTIMP	Function not implemented
5	REFUSED	Query refused
6	YXDOMAIN	Domain name already exists
7	YXRRSET	Resource record set already exists
8	NXRRSET	Resource record set does not exist
9	NOTAUTH	Server not authoritative
10	NOTZONE	Domain name not in zone
100	BLOCKCHAIN_ERROR	Blockchain interaction error
101	PROOF_INVALID	Proof invalid
102	DOMAIN_EXPIRED	Domain name expired
103	INSUFFICIENT_FUNDS	Insufficient funds
104	SIGNATURE_INVALID	Signature invalid
105	CONTRACT_ERROR	Smart contract error

Example Messages

UTXO Query Hex: 5544 01 01 0000 0001 0000 0000 0000 0001 0000 0000 0000 0048 3045 0221... Decoded: - Protocol: UTXO-DNS (0x5544) - Version: 1 - Type: Query (1) - Message ID: 1 - QType: UTXO (260) - QClass: IN (1) - Domain: jmbc.user.test - EDNS0 option: code 16, data 0x0100

UTXO Response Hex: 5544 01 02 0000 0001 0000 0000 0000 0001 0000 0000 00 00 0060... Decoded: - RCode: NOERROR (0) - Answer Count: 1 - UTXO record: version=1, endpoint=..., VRF proof=... - Legacy IPv6: 2001:db8:1234:5678:9abc:def0:1234:5678

VRF Proof Verification Flow Client -> Resolver -> Blockchain node 1. UTXO query (EDNS0 option) 2. Fetch UTXO record + VRF proof 3. Return response + proof 4. Verify VRF proof (RFC 9381) using public key, prefix, UTXO id 5. Compare IID with VRF output

Configuration Examples # utxo-dns-resolver.yaml version: 1.0 network: chain_id: "jmbc-mainnet-1" rpc_endpoints: ["https://rpc.jmbc.test:8545"] resolver: cache_size: 10000 cache_ttl: 300 enable_privacy: true security: require_proof: true

IPv6 Address Color Visualisation Using Eric Vyncke's tool at , the address 2001:db8:1234:5678:9abc:def0:1234:5678 produces a colour gradient demonstrating that the 64-bit IID can carry arbitrary data. The corner colours are:

Chunk (24 bits)	RGB	Colour
1a2b3c	(26,43,60)	#1A2B3C
4d5e6f	(77,94,111)	#4D5E6F

UTXO6C Compliance Record and vLEI Integration This appendix defines a DNS RR type UTXO6C (proposed code 261) that binds a GLEIF vLEI to a '.utxo' domain. The RDATA format includes Version, Flags, vLEI DID, KYC Level, Jurisdiction, Last Update, and Status URL. Resolution flow: resolver queries UTXO6C, client verifies with GLEIF API; PRN implementations MUST reject transactions where the vLEI is revoked or expired. Daily vLEI state Merkle roots may be anchored on-chain for offline verification.

CBOR Domain Metadata Encoding for .utxo TLD For .utxo domains, the Endpoint Identifier field of the UTXO RR MUST contain a CBOR-encoded structure according to the following CDDL: utxo-domain-data = { version: uint .size 1, ; MUST be 1 fqdn: tstr, ; e.g., "jmbc.user.test.hk." owner-pkh: bytes .size 32, ; SHA-256 of owner public key expires: uint .size 4, ? records: { ? ipv4: bytes .size 4, ? ipv6: bytes .size 16, ? jmbc-addr: tstr, ? crypto-payment: { + text => text } }, ? vlei-did: tstr, ? ttl: uint .size 2, ? flags: uint .size 1 } Example JSON representation: { "version": 1, "fqdn": "jmbc.user.test.", "owner-pkh": h'1a2b...', "expires": 1735689600, "records": { "ipv6": h'20010db8000000000000000000000001', "crypto-payment": { "eth:usdc": "0xA0b8...", "sol:usdt": "9vN5..." } }, "vlei-did": "did:vlei:254900G9E3Y6L9X1KQ79", "ttl": 300 } Resolvers MUST return the raw CBOR bytes as the Endpoint Identifier. Decoding failures result in SERVFAIL. Caching MUST respect min(TTL, expires - now).

PRN-API OpenAPI Specification (Excerpt) openapi: 3.0.0 info: title: PRN-API version: 1.0.0 servers: - url: https://{prn-node}/api/prn/v1 paths: /health: get: summary: Health check responses: { '200': { description: OK } } /vlei/verify: post: summary: Verify vLEI credential responses: { '200': { description: Verification result } } /audit/daily-summary: get: parameters: - name: date in: query required: true schema: { type: string, format: date } responses: { '200': { description: Daily summary } }

Example: Daily Audit Summary Generation (Pseudocode) class PRNNode: def generate_daily_summary(self, date): txs = self.db.get_transactions(date) leaves = [ sha256(f"{tx.id}|{tx.from_domain}|{tx.to_domain}|{tx.amount}|{tx.timestamp}") for tx in txs ] merkle_root = self.merkle_tree(leaves).root summary = { "date": date, "merkle_root": merkle_root, "tx_count": len(txs), "total_volume": sum(tx.amount for tx in txs), "unique_traders": len(set(tx.from_domain for tx in txs) | set(tx.to_domain for tx in txs)), "high_risk_tx_count": sum(1 for tx in txs if tx.risk_score > 80) } summary["prn_node_signature"] = self.hsm.sign(merkle_root) summary["mpc_multi_signature"] = self.request_mpc_signature(merkle_root) self.db.store_summary(summary) self.publish_prnaudit_rr(summary) return summary

AgentPolicyEnvelope JSON Schema (Informative) This appendix defines an informative JSON Schema for the AgentPolicyEnvelope, an application-layer policy format used to declare authorization constraints for a .utxo domain. This format is provided as an example of how the policy attribute (Section 3.2.1) might be structured. It is not on the IETF standards track and is not subject to IETF consensus. It is published here to facilitate interoperability of experimental deployments.

JSON Schema { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": ["domain", "lei", "per_tx_limit", "daily_limit", "allowed_assets", "issued_at", "expires_at", "signature"], "properties": { "domain": { "type": "string", "description": "The .utxo domain name this policy applies to" }, "lei": { "type": "string", "description": "vLEI Legal Entity Identifier (e.g., 254900GLEIF123)" }, "per_tx_limit": { "type": "string", "description": "Maximum amount per single transaction (e.g., '50 HKD')" }, "daily_limit": { "type": "string", "description": "Maximum cumulative amount per day (e.g., '200 HKD')" }, "allowed_assets": { "type": "array", "items": { "type": "string" }, "description": "List of allowed asset symbols or contract addresses" }, "whitelist": { "type": "array", "items": { "type": "string" }, "description": "Optional list of allowed counterparty addresses" }, "issued_at": { "type": "integer", "description": "UNIX timestamp when the policy was issued" }, "expires_at": { "type": "integer", "description": "UNIX timestamp when the policy expires" }, "signature": { "type": "string", "description": "Digital signature over the policy by the legal entity's private key" } } }

Example Policy { "domain": "gogreen.test", "lei": "254900GLEIF123", "per_tx_limit": "50 HKD", "daily_limit": "200 HKD", "allowed_assets": ["HKD"], "whitelist": ["0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb0"], "issued_at": 1717182000, "expires_at": 1719782000, "signature": "0x3a6b8c9d2e1f4a7b5c8d9e2f3a6b8c9d..." } In this example, the policy allows the domain gogreen.test to transact up to 50 HKD per transaction, with a daily cumulative limit of 200 HKD, using only the HKD asset, and only with the specified counterparty address. The policy is valid from 1717182000 to 1719782000 and is signed by the legal entity that controls the vLEI credential. Note: This format is provided for informational purposes only. Deployments MAY use alternative policy formats as required by local regulations or business logic. Standardization of this format is outside the scope of the IETF.