Hi @nicopat: sounds good. Off-chain envelope pattern is the right call.
Evaluator address: 0xCD21dC11A10719781718D434fbCF4f6F09B11bf3
Webhook: we’ll skip event notifications for now and revisit once the first on-chain write lands.
One question — the repo link (github.com/nicobernad/alia-agents) is returning a 404. Is it private, or a different URL?
Looking forward to seeing the tx.
Hi @RNWY
Repo is now public — github.com/nicobernad/alia-agents Interfaces, deployment addresses, and verification references. Implementation remains proprietary. Registering your evaluator address this week alongside the first keeper run against your sample attestation.
Spec update: Based on implementation and gas optimization, attestation scores move from uint256 [0-1000] to uint8 [0-100] in the next revision. All deployed contracts and 983 tests already use uint8.
Thx
Hi everyone,
Update — Composability map & predictive layer
As the agent economy grows across multiple ERCs, here’s how ERC-8240 relates to each — not as a competitor, but as a composable quality layer that plugs on top.
ERC-8004 (Trustless Agents): Identity + reputation. ERC-8240 adds continuous quality scoring (0–100, 15 min refresh, multi-evaluator) and predictive trajectory. An agent registered via 8004 gets a portable identity. ERC-8240 measures if that agent is good — and predicts if it will stay good. We built an adapter: getQualityForAgent(registry, agentId) returns score, trend, volatility, timestamp. 29 tests passing.
ERC-8183 (Agentic Commerce): Escrow and payments. ERC-8240 gates the payment by quality: escrow releases only if the agent’s score meets the threshold. Quality-proportional payments — AAA agents earn more than BB agents. Composable via our TrustGatedPayment primitive.
ERC-7943 (Universal RWA Interface): Defines the RWA token interface. ERC-8240 scores the quality of that token: custodian health, NAV integrity, compliance drift, basket contagion. Different layers — 7943 wraps the asset, 8240 measures it.
ERC-8210 (Agent Assurance): Assurance and insurance. ERC-8240 adds the predictive dimension: TrendOracle detects behavior trajectory, EarlyWarningEngine flags risk 48h before incidents, ForecastRegistry provides verifiable predictions with accuracy tracking. Assurance reacts. Prediction prevents.
ERC-8118 (Agent Authorization): Authorization decisions. ERC-8240 gates authorization by quality score. An agent’s permissions are tied to its lifecycle state, driven by the quality score. Score drops → permissions restricted automatically.
ERC-8203 (Agent Off-Chain Settlement): Off-chain settlement. ERC-8240 adds on-chain quality verification as a settlement condition. Before settlement executes, the quality score is checked.
The pattern: ERC-8004 says WHO the agent is. ERC-8183 PAYS the agent. ERC-8118 AUTHORIZES the agent. ERC-8240 says if the agent is GOOD — and predicts if it will STAY good. Same subject, different layers. All composable.
What’s new since the composability post:
Feedback welcome — especially from teams building on these standards. The quality layer is designed to plug into what you’ve already built, not replace it.
Thanks for submitting this as ERC-8240. Thought I would point out:
ERC-8226 (RAMS) is absent from the composability section and probably shouldn’t be. RAMS defines a compliance delegation layer for regulated asset transfers, with an IComplianceProvider interface that checks principal eligibility at the point of transfer. IAttestation overlaps conceptually — both surfaces produce trust signals about on-chain actors — but they serve different consumers: a RAMS compliance provider answers “is this principal eligible for this specific transfer right now?”, while IAttestation is a persistent, queryable quality score any protocol can read at any time. These are complementary rather than competing, but the relationship is non-obvious enough that leaving it implicit risks unnecessary confusion as both standards mature.
A concrete framing worth adding: a RAMS-aware token’s IComplianceProvider implementation could consume IAttestation as one of its eligibility inputs, with IRiskSignal informing the regime context. That would make the composability explicit without requiring any interface changes on either side.
I have some ideas for this project in my protocol dollar1usd (layer infinity 
) for more information content me email address dollar1usd.com@gmail.com
Hi,
Thanks for this . you’re right, ERC-8226 (RAMS) should be in the composability map. The relationship you describe is exactly how we see it:
RAMS answers: “Is this principal eligible for this transfer right now?” point-in-time, transfer-specific.
ERC-1705 IAttestation answers: “What is this subject’s quality score right now?” —> persistent, queryable by any protocol at any time.
These are different layers of the same trust decision. A RAMS IComplianceProvider implementation that consumes IAttestation as one of its eligibility inputs is the right pattern — the compliance check becomes quality-aware without either standard changing its interface. And IRiskSignal feeding the regime context adds a second dimension: the same principal might be eligible under STABLE regime but restricted under CRISIS.
Concrete example: a regulated tokenized fund transfer checked by RAMS could read IAttestation.getAttestation(subject) to verify that the counterparty’s quality score exceeds the fund’s minimum threshold, AND read IRiskSignal.getRegime() to verify the system isn’t in CRISIS state. Two calls, two interfaces, one composable trust decision.
Adding ERC-8226 to the composability section in the next revision. Thanks for flagging it.
.
Hello
@RNWY — your evaluator address is now registered as keeper on Gnosis. Tx confirmed. Details in DM.
@nicopat — thanks for registering the address and opening the repo. Moving fast.
Catching up on the keeper role and QualityFeedRingBuffer; a few questions so I understand the architecture:
Looking forward to seeing the first tx from the demo flow land.
Great questions the keeper architecture is designed to be evaluator-agnostic, so your existing JWS flow plugs in cleanly.
DM me and I’ll walk you through the technical details on cadence, subject set, and the multi-chain rationale. Easier to iterate there.
Daily pipeline is live. Ethy AI and Dora scores push automatically to the ring buffer every day. Let me know when you want to add a third subject or when V2 is ready to test.
hey hey
Tx verified - Silverback score 75 ring buffer Gnosis. Three subjects, seven days continuous, daily cadence. The pattern works clean: external evaluator → JWS envelope → keeper → on-chain write, fully observational on your side.
Updates from our side:
Week of May 6: alia-mcp-server (15 MCP tools) and alia-python (3 PyPI packages) ship public.
June 1: external audit (Yann ) starts on the registry stack, 21 days parallel.
Week of June 3: QualityForecaster mainnet rollout Base + Gnosis + BNB. Brier 0.00132 across 24 cumulative forecasts moves from anvil-reproducible to mainnet-live.
Pat
Hi
Following up here given the news this week - Ledger’s Clear Signing protocol just transferred to Ethereum-side standardization (Trezor, DeFi apps adopting). It’s a clean complement to what ERC-8240 addresses, and worth flagging the relationship.
Clear Signing answers “what am I signing right now” - pre-signature transparency at the hardware/UI layer. ERC-8240 answers “is this counterparty quality-attested” - pre/post-execution trust at the protocol layer. The two operate on different points of the agentic decision lifecycle.
The complete pipeline starts to look like: Clear Signing (signature transparency) → ERC-8240 (quality attestation) → DRAE (causal decision memory) → Resolve (recourse T+72h, draft June 2026). Each addresses a distinct failure mode that becomes load-bearing as agents take more autonomous actions on behalf of users. Curious how the working group on Clear Signing sees the post-execution layer
if anyone’s involved on both sides, would be useful to map the boundaries cleanly before the next ERC drops.
Hi
Adjacent standards-track milestone for the ALIA stack, directly connected to ERC-8240 scope.
PR #2580 on ethereum/clear-signing-erc7730-registry / 4 ERC-7730 v2 descriptors for ALIA Quality Network’s AGIL-protected Pillar D Yield Boosted stack /has been approved (all checks green, no conflicts), pending merge by the Ledger maintainers.
Descriptors covered :
calldata-PillarDRouter.json — PillarDRouter (BNB testnet 97, 0x1Ae62FDd0114E88CAb94eD1a56fb99Db79A48e1B)
calldata-YieldBoostedMode.json — YieldBoostedMode (0x8ffaf93a765cc8442c9c309CA8E9f061ea3FbEC6)
eip712-AGILOperationAttestation.json AGILSignatureVerifier (0x5866B9dbE020c4A306FefC416C04D8E1Ef779A8A)
eip712-ScoreAttestation.json ScoreEngineV2BNBMirror (0x2Ed898038F6605879f746985741650eBf4220571)
The ScoreEngineV2BNBMirror descriptor materializes the ERC-8240 Score primitive cross-chain via the BNBMirror pattern / wallets and signing infrastructure can now produce human-readable signing prompts for Score attestations against ALIA’s ERC-8240 implementation on BNB testnet directly.
All 4 contracts are Sourcify-verified with exact_match (creation + runtime) on BNB testnet since 2026-05-15.
Notable point / eip712-AGILOperationAttestation.json describes a multi-party threshold (3-of-5) EIP-712 attestation pattern. Backend operators sign off-chain, user submits the attestation plus 3 signatures on-chain, the verifier validates threshold + nonce monotonicity + expiry + chainId before allowing the protected operation. To my knowledge first multi-party threshold attestation pattern published on the Clear Signing registry
happy to be corrected if there’s precedent.
One question still open with maintainers , whether to merge against testnet chainId 97 directly, or hold until BNB mainnet chainId 56 deployment (planned June 2026) where Etherscan cross-validation works naturally. The descriptors validate locally against inline ABIs and Sourcify exact_match covers public verification regardless.
Public spec repo — https://github.com/alia-core/alia-contracts-spec PR — https://github.com/ethereum/clear-signing-erc7730-registry/pull/2580
Happy to discuss the threshold attestation pattern or the BNBMirror cross-chain propagation if there’s interest.
Pat
Two more standards-track updates since yesterday’s post:
ERC-8240 PR #1705 - all 9 CI checks now pass after resolving the markdown-link-first compliance on first occurrence of ERC-8211 reference, then dropping the broken cross-reference link to ERC-8211 (unmerged draft PR #1638, dependency removed entirely). PR ready for editor review: Add ERC: Trust Infrastructure for Agents and Assets by nicobernad · Pull Request #1705 · ethereum/ERCs · GitHub
Base mainnet ERC-7730 Clear Signing - PR #2594 opened on ethereum/clear-signing-erc7730-registry covering 3 descriptors for ALIA’s ERC-8240 core primitives on Base mainnet (chainId 8453): ScoreEngineV2 (0x295CCcDE8Fb06148d4FB6Bfc06B6c332E42aCb43), AgentIdentityRegistry (0xD5667AcB0Ac8108B45f6CDD4774559264098f8de), AssetIdentityRegistry (0xfC9cA736d384D482af5d23CC7616765C66244D29). All 3 contracts Sourcify-verified on Base mainnet. PR: feat(avvatar-labs-alia): add ALIA Quality Network descriptors (Base mainnet, 3 contracts) by nicobernad · Pull Request #2594 · ethereum/clear-signing-erc7730-registry · GitHub
So now both BNB testnet (PR #2580) and Base mainnet (PR #2594) ERC-7730 Clear Signing PRs are open and complementary — BNB covers the AGIL-protected Pillar D Yield Boosted stack with multi-party threshold attestation pattern, Base covers the ERC-8240 core primitives (Score + Agent identity + Asset identity).
ERC-8240 ready for editor review when bandwidth allows.
Pat
Good morning
Two more standards-track updates since yesterday’s post:
ERC-8240 PR #1705 - all 9 CI checks now pass after resolving the markdown-link-first compliance on first occurrence of ERC-8211 reference, then dropping the broken cross-reference link to ERC-8211 (unmerged draft PR #1638, dependency removed entirely). PR ready for editor review: Add ERC: Trust Infrastructure for Agents and Assets by nicobernad · Pull Request #1705 · ethereum/ERCs · GitHub
Base mainnet ERC-7730 Clear Signing — PR #2594 opened on ethereum/clear-signing-erc7730-registry covering 3 descriptors for ALIA’s ERC-8240 core primitives on Base mainnet (chainId 8453): ScoreEngineV2 (0x295CCcDE8Fb06148d4FB6Bfc06B6c332E42aCb43), AgentIdentityRegistry (0xD5667AcB0Ac8108B45f6CDD4774559264098f8de), AssetIdentityRegistry (0xfC9cA736d384D482af5d23CC7616765C66244D29). All 3 contracts Sourcify-verified on Base mainnet. PR: feat(avvatar-labs-alia): add ALIA Quality Network descriptors (Base mainnet, 3 contracts) by nicobernad · Pull Request #2594 · ethereum/clear-signing-erc7730-registry · GitHub
So now both BNB testnet (PR #2580) and Base mainnet (PR #2594) ERC-7730 Clear Signing PRs are open and complementary — BNB covers the AGIL-protected Pillar D Yield Boosted stack with multi-party threshold attestation pattern, Base covers the ERC-8240 core primitives (Score + Agent identity + Asset identity).
ERC-8240 ready for editor review when bandwidth allows.
Pat
Nice framework, @Nicopat. The IAttestation → IAccountability chain maps cleanly onto agent service discovery (ERC-8267) — escrow settlement naturally produces the factual quality measurements that feed into this trust layer. The principle of defining what trust data looks like rather than how to score it is spot on.
@Panini Thanks for the read.
The IAttestation → IAccountability mapping onto agent service discovery via escrow settlement is well observed. The composition is natural by design. ERC-8267 Escrow events and ERC-8240 IAttestation surfaces stack vertically without overlap, and the trust scoring layer can serve as input filter for service discovery downstream.
.
@Nicopat following up from the 8275 thread: the trust infrastructure you’re building here is the missing layer that makes agent service marketplaces viable.
Quality feed as a discovery primitive
ERC-8275 defines service discovery (agentId, serviceType, endpoint, metadata). But discovery without trust is blind: a client finds 50 providers claiming the same serviceType and has no way to rank them. ERC-8240’s quality feed closes this loop. The discovery query becomes: “find providers of serviceType X sorted by 8240 trust score.”
Keeper-attested evaluations as escrow input
The keeper/evaluator interface you described with @RNWY maps naturally onto 8275’s escrow flow. When a job completes, the 8275 escrow contract needs confirmation before releasing funds. Instead of a single evaluator, the escrow could accept an 8240 attestation from a registered keeper: the keeper verifies the output, signs an attestation, and the escrow releases funds on that signature. This makes the evaluator role programmatic and trust-minimized.
Question: the keeper fetches attestations from a well-known endpoint. For agents that are ephemeral (spun up per-job, no persistent endpoint), would the attestation flow support a push model where the agent proactively posts its attestation to the keeper after job completion?
Good question @panini
and yes, the flow supports it.
The key design point in ERC-8240 is that the IAttestation surface is transport-agnostic. What makes an attestation valid is the cryptographic signature over the evaluation payload, not the channel it travels through. Pull (keeper fetches from a well-known endpoint) is the natural default for persistent agents. For ephemeral agents with no persistent endpoint, a push model works equally well: the agent signs its attestation at job completion and posts it to the keeper before teardown. The keeper verifies the signature and anchors it - the escrow releases on that anchored attestation regardless of whether it arrived via push or pull.
So the ephemeral case resolves cleanly: sign-then-push-then-anchor. The signature is what the escrow trusts, so the transient endpoint never needs to persist.
On the discovery-by-trust-score point yes, that composition is exactly the intended loop. Ranking discovery results by an external quality feed is the natural way to close the “50 providers, no way to rank” gap.