REGISTRY-STATE REFERENCE
FACTOS-PRS-8320-SEL-2026-09-21
A refinement of FACTOS-PRS-8320-2026-09-18. The first record gated an ERC-8226 agent action on whether any backing claim was active. That is existence, not selection. When several claims are active, suspending the relevant one leaves the others, and a claim reporting weak coverage passes a mere-existence check. This record gates on a claim from the required author: the specific attestor the asset trusts.
Version 1 · 21 September 2026 Ethereum Sepolia · test network Synthetic payload
Why this record exists
Raised in the thread (post #7): with multiple active backing claims, does suspending one leave an
unrelated one active, and does a claim reporting only partial coverage still pass? Both were true of a
length-only gate. The fix is consumer selection, which the standard already puts on the reader: the
asset requires an active claim whose author is the attestor it trusts. It reads the claim's
immutable author and lifecycle state, both on-chain, and no payload. Content adequacy stays off-chain
and schema-specific, by design.
| Registry (ERC-8320) | 0x3D07a11A12B6e27fAE1b00474211D5D02624dbe3 |
|---|---|
| Asset (requires auditor A) | 0xE04545ACdCAB1Fbff91e2e4Ac88a6d8257024CF9 |
| Mandate registry (ERC-8226) | 0xB7e7B1ca762144A135FB43F9f543Ee76B21B8583 · Brickken, unmodified |
| Auditor A (required) | 0x903b5f200935a650720132729FaEA8dB9174F3d3 · test key; the attestor this asset trusts |
| Auditor B (authorized, not required) | 0xEfcc7f51f9455AaC217c89dE089A7b24a90b484B · test key; may publish, but its claim does not satisfy this asset |
What happened on chain
Both auditors published an active backing claim. The asset requires auditor A. FACTOS then suspended only auditor A's claim, leaving auditor B's active.
| Two claims active, agent acts | 0xd521cfd2…c12ca90 · executes |
|---|---|
| FACTOS suspends auditor A's claim | 0xb5c1e545…0c6d63a3 · A: ACTIVE → VALID; B stays ACTIVE |
| Agent retries | 0x773f55e8…baf95073 · reverts NoActiveBackingClaim(4), though auditor B's claim is still active |
An existence gate would have passed the retry: a backing claim was still active. Selection by required author did not, because the claim it required was gone. That is the point.
Check it without asking us
state at block … is pruned. https://sepolia.gateway.tenderly.co is one.# One backing claim is still active after the suspend, and it is auditor B's, not the required one.
cast call 0x3D07a11A12B6e27fAE1b00474211D5D02624dbe3 \
"getActiveClaims(bytes32,uint8)((bytes32,uint8,bytes32,bytes32,uint64,uint64,uint64,uint8,bytes32[],bytes32,address,string)[])" \
0xa147460944099d529415035b59d81f8e2f78cd24762e785e80c1628a6b6f71a2 5 --rpc-url <archive>
# one entry, author 0xEfcc7f51f9455AaC217c89dE089A7b24a90b484B (auditor B)
# The asset requires auditor A, so the retry reverts.
cast call 0xE04545ACdCAB1Fbff91e2e4Ac88a6d8257024CF9 "requiredBackingAuthor()(address)" --rpc-url <archive>
# 0x903b5f200935a650720132729FaEA8dB9174F3d3 (auditor A)What this record does not claim
Selection answers whose attestation and whether it is live. It does not read the attestation's content. Whether the backing is adequate, say 60 percent versus full coverage, lives in the off-chain payload and needs a schema-specific reader. That boundary is deliberate: the lifecycle and authorship are reusable across every issuer; the content threshold is issuer and schema specific, and does not compose without agreeing on a schema.
Requiring a single author is the simplest policy and carries the obvious availability tradeoff: if that attestor goes quiet, the asset stalls. All-must-hold or m-of-n is where a production asset would go. The payload here is synthetic, so this proves the selection, not any real reserve.