| Internet-Draft | UTXO Domain Name System (UTXO6-DNS): Bas | June 2026 |
| Tian, et al. | Expires 23 December 2026 | [Page] |
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 Section 1 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document is published as an Experimental specification. According to [RFC2026], 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.¶
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.¶
This document defines:¶
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.¶
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:¶
DNSOP working group mailing list: https://mailarchive.ietf.org/arch/browse/dnsop/¶
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 [RFC2119].¶
A UTXO owner generates a stable, verifiable IID for any network prefix using:¶
IID = VRF(UTXO_privkey, Prefix || UTXO_TXID || OutputIndex || Nonce)[64]¶
where:¶
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.¶
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.¶
This construction follows the pattern of [RFC7217] 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.¶
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:¶
If the LegacyIPPresent flag is set, an A or AAAA record is appended after the VRF proof.¶
An EDNS0 option (code TBD, suggested 16) is defined for clients to indicate UTXO-DNS support. The option follows the format defined in [RFC6891]. The option data is 2 octets: version (1) and reserved (0). Servers SHOULD echo it.¶
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.¶
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:¶
These extensions do not modify the base resolution protocol.¶
The UTXO RR presentation format supports optional attributes. This document defines:¶
prn-endpointaudit-grouppolicyipfs://... or https://...) pointing to an AgentPolicyEnvelope JSON object. The resolved content MUST conform to the informative schema defined in Appendix I. Example: "policy=ipfs://QmX...".¶
regulatory-jurisdictionstablecoin-whitelistvlei-didExample:¶
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" )¶
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.¶
A new EDNS0 option (code TBD2) is defined. The option data MAY contain sub-options: 0x01 (request PRNAUDIT), 0x02 (request vLEI status).¶
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, [RFC8446] MUST be enforced.¶
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 Appendix G.¶
PRN nodes MAY expose wss://... for real-time messages (transaction, alert, health, audit_complete).¶
Three independent auditing firms operate MPC nodes. The committee public key is known. The [GG20] protocol produces a 64-byte Schnorr signature (R and s).¶
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.¶
Monthly, quarterly, and annual reports are derived from daily summaries using Merkle trees of daily hashes, each with a fresh MPC signature.¶
PRN nodes verify vLEI by fetching https://api.gleif.org/api/v1/vlei/{lei} (see [GLEIF-API]), verifying the response signature, checking expiration and revocation, and optionally confirming domain linkage.¶
To avoid overload, PRN nodes MUST cache with max TTL 300s, webhook invalidation, minimum 10k entries, LRU eviction.¶
Dashboards can integrate with any PRN node using the PRN-API. A reference open-source implementation is available.¶
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 Appendix I).¶
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.¶
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). |
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.¶
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.¶
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:¶
Since the policy attribute is a URI (e.g., ipfs:// or https://), PRN nodes face the following risks:¶
https://, TLS MUST be enforced (RFC 8446). When using ipfs://, content addressing provides integrity by default (the CID includes a cryptographic hash).¶
IANA is requested to assign the following:¶
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.¶
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.¶
| 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 |
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¶
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¶
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¶
# 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¶
Using Eric Vyncke's tool [Vyncke] at https://www.vyncke.org/myipcolor.php, 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 |
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.¶
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).¶
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 } }¶
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¶
This appendix defines an informative JSON Schema [RFC8259] 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.¶
{
"$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"
}
}
}¶
{
"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.¶