Demonstration environment. This record describes synthetic instruments on Ethereum Sepolia. It does not represent a real credit right or a real person. The backing claim below carries a synthetic payload: it proves the registry mechanics, not the content of any reserve.

REGISTRY-STATE REFERENCE

FACTOS-PRS-8320-2026-09-18

One asset that is at the same time the asset of an ERC-8226 agent mandate and an IRegistryAnchor of an ERC-8320 claim registry. The agent can act only while a backing claim is live. When the claim is suspended, the action stops, even though the mandate itself is still valid. The two standards, from the same authors, composed on one asset.

Refined 21 September. This record gates on whether any backing claim is active, which is existence, not selection. The gate was refined to require a claim from a specific trusted author, so an unrelated author's claim cannot hold it open. See FACTOS-PRS-8320-SEL-2026-09-21.

Version 1 · 18 September 2026 Ethereum Sepolia · test network Synthetic payload

Two parties, as the standard separates them

ERC-8320 says the service-provider roster is the grant table. We wired it that way. FACTOS operates the registry: it registers the asset, keeps the grant table, and runs the maker-checker lifecycle as validator and activator. A separate key authors the backing claim. In this demo the auditor role is played by a test key; the design requires a key distinct from the validator's, which in real use would belong to an independent third party, the one that reviews the reserves or the loanbook and signs. In Colombia that party would be a receivables verification agent; in the United States it is often a loan-review firm. FACTOS does not author the backing, and never authors valuation or risk.

Registry (ERC-8320)	`0x077c6f1f23DF776B25A48D2cdC015e15a7D3a002` · reference implementation of the authors, unmodified
Anchored asset	`0x25B443684e240f0362d019AB666EDdFE0a93c3Ac` · the same asset of the mandate and the anchor of the registry
Mandate registry (ERC-8226)	`0xB7e7B1ca762144A135FB43F9f543Ee76B21B8583` · Brickken, unmodified
FACTOS (operator)	`0x9016EfF3AC70DDaeDC15ac8fb3d839f2d3b965a5` · admin, validator, activator
Auditor (backing author)	`0x903b5f200935a650720132729FaEA8dB9174F3d3` · a test key standing in for the auditor; the registry requires the validator to differ from the author

What happened on chain

Backing goes live	the auditor proposes, FACTOS validates and activates · claim ACTIVE
Agent acts	`0x277c4d8a…02317131` · mandate OK, registry state current, backing live · executes
FACTOS suspends the backing	`0xc6cb7dfb…34cdf444` · claim ACTIVE → VALID
Agent retries	`0x192deb53…cbe1cbe7` · the mandate still answers `(true, OK)`, yet the asset reverts `NoActiveBackingClaim(3)`

The agent's mandate never expired and was never revoked. The action stopped because the backing that a separate party had attested was withdrawn from the ERC-8320 registry. That is the join between the two standards: an ERC-8226 execution gated on ERC-8320 published state, with neither contract modified.

Check it without asking us

Use an archive endpoint. Reads at a past block need an archive node; a pruned public node answers state at block … is pruned. Any archive endpoint works; https://sepolia.gateway.tenderly.co is one.

# The backing claim is no longer active after the suspend: the set is empty.
cast call 0x077c6f1f23DF776B25A48D2cdC015e15a7D3a002 \
  "getActiveClaims(bytes32,uint8)((bytes32,uint8,bytes32,bytes32,uint64,uint64,uint64,uint8,bytes32[],bytes32,address,string)[])" \
  0x7e646f4f719d1da5c21d22509ef7c11e9e20934c981c2d8341f7ac31832a5474 5 --rpc-url <archive>
# []

# The two parties are distinct, and it is on chain: the auditor authors, FACTOS validates.
# isAuthorized(assetId, BACKING=5, roleKind, who): AUTHOR=0, VALIDATOR=1
cast call 0x077c6f1f23DF776B25A48D2cdC015e15a7D3a002 "isAuthorized(bytes32,uint8,uint8,address)(bool)" \
  0x7e646f4f719d1da5c21d22509ef7c11e9e20934c981c2d8341f7ac31832a5474 5 0 \
  0x903b5f200935a650720132729FaEA8dB9174F3d3 --rpc-url <archive>
# true   the auditor holds AUTHOR of BACKING

cast call 0x077c6f1f23DF776B25A48D2cdC015e15a7D3a002 "isAuthorized(bytes32,uint8,uint8,address)(bool)" \
  0x7e646f4f719d1da5c21d22509ef7c11e9e20934c981c2d8341f7ac31832a5474 5 0 \
  0x9016EfF3AC70DDaeDC15ac8fb3d839f2d3b965a5 --rpc-url <archive>
# false  FACTOS does not author the backing

What this record does not claim

The backing claim carries a synthetic payload. Its contentHash is the hash of a label, and its uri does not resolve to a document. This record demonstrates the mechanics of the registry and the composition, not the content of any reserve. A production backing claim would anchor the hash of a real evidence file and a canonical schema.

Unlike the FACTOS instrument registry, which has no administrator and is written by a single key, this asset has an owner: the holder, who approves or removes the registries the asset recognises. If the holder removes the registry, the action fails closed, which is the consumer rule the standard states. The typed FACTOS instrument registry still sits alongside the ERC-8320 registry, because ERC-8320 keeps business state in the off-chain payload and cannot express the holder-to-right relationship on chain. The two reads answer different questions and neither replaces the other.

Scope of what is published. Synthetic instruments on a test network. FACTOS operates the registry; the backing is authored by a separate key, a test key in this demo, which in real use would belong to an independent third party. What is published is a measured fact, never a recommendation. It does not certify that a right is valid or enforceable in any given forum, nor the authenticity of the identity binding of the parties.