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.