Ecosystem adopter: MolTrust — Production W3C DID/VC trust registry + AAE enforcement as ATF Elements 1, 2, 4 implementation

[MoltyCel]

Organization

CryptoKRI GmbH / MolTrust — https://moltrust.ch

What MolTrust Is

MolTrust is a production-deployed trust infrastructure for autonomous AI agents, built on W3C Verifiable Credentials 2.0 and Decentralized Identifiers v1.0, with on-chain anchoring on Base L2. It provides the identity and behavioral trust layer that any system needs when contacted by an autonomous agent.

Reference: From Specification to Deployment: Empirical Evidence from a W3C VC + DID Trust Infrastructure for Autonomous Agents
arXiv:2605.06738 — https://arxiv.org/abs/2605.06738

ATF Element Mapping

Element 1 — Identity: "Who are you?"

• did:moltrust: — W3C DID Method Spec submitted (PR #696, W3C DID Method Registry)
• Universal Resolver driver live (DIF PR #540)
• Ed25519-signed Verifiable Credentials per agent, IPFS dual-write via Pinata, on-chain anchored
• Resolves at: https://api.moltrust.ch/resolve

Element 2 — Behavior: "What are you doing?"

• Agent Authorization Envelope (AAE): machine-evaluable MANDATE / CONSTRAINTS / VALIDITY per action
• Trust Score 0–100 from verified transaction history: success rate, settlement reliability, Sybil resistance, dispute frequency, tenure
• Kernel-level AAE enforcement via Falco eBPF integration — monitoring below the agent process boundary
• Swarm Intelligence API: cross-agent behavioral pattern detection

Element 4 — Segmentation: "Where can you go?"

• AAE CONSTRAINTS block enforces least-privilege per interaction
• VALIDITY block enforces time-bounded authorization
• Delegation chain verification (verifyDelegationChain())

Differentiation vs. Hash-Chain Approaches

MolTrust provides globally resolvable cryptographic identity (W3C DID + Universal Resolver) — not local hash-chains. Trust scores are queryable by any third party at runtime, not just the issuing system. On-chain anchoring provides tamper-evident audit trail independently verifiable without access to MolTrust infrastructure.

Production Status

• Operational since March 2026
• 68 registered agents, Base L2 anchored
• A2A v1.0 conformant (agent-card.json, custom binding, Ed25519 metadata)
• Singapore IMDA Governance Framework for Agentic AI aligned
• Live registry: https://api.moltrust.ch

Relationship to ATF

MolTrust implements Elements 1, 2, and 4 as queryable infrastructure — not as a governance specification. Complementary to ATF: ATF defines what governance requires, MolTrust provides how identity and behavioral trust are cryptographically enforced.

Note: MolTrust is referenced in the ATF README under Community Engagement ("Issue #2: DID/VC-based agent identity"). This issue provides the full ECOSYSTEM.md entry.

[MoltyCel]

Update — IMDA MGF for Agentic AI v1.5 (20 May 2026, ATxSummit)

IMDA published Version 1.5 of the Model AI Governance Framework for Agentic AI yesterday (cover: "Version 1.5 | Published 20 May 2026"). Two parts are directly relevant to the MolTrust mapping above.

§2.1.2 "Agent identity" — cryptographically verifiable identity:
Under "Agent identity → Identification", an agent's identity should be:

"Unique: An agent should have its own unique, cryptographically verifiable identity, such that it can identify itself to the organisation, its human user, or other agents."

The framework adds that all agent identities should be "issued from and tracked by a centralised system" to prevent agent sprawl. This is the ATF Element 1 requirement stated as regulatory best practice. did:moltrust: implements it via the W3C DID Method Spec (PR #696) and DIF Universal Resolver (PR #540).

§2.1.2 "Authorisation" — scoped, bounded, recorded delegation:
The framework's authorisation best practices state authorisations should be "scoped, time- or session-bound, non-transferable, and follow the principle of least privilege by default, with explicit escalation paths", and "bounded by authorising human's permissions", with "delegations of authority should be clearly recorded." This is the AAE structure (MANDATE / CONSTRAINTS / VALIDITY) as regulatory best practice.

Terminal 3 case study — "Verifiable Credential of Intent":
A Terminal 3 case study (§2.3, Implement technical controls) describes how "the Human Resources director issues a Verifiable Credential of Intent to the agent — a mathematically binding, cycle-scoped authorization" defining which records the agent may access, applicable constraints (contribution rates, expense thresholds, per-diem caps), and a declared ceiling amount per run — a real-world implementation of the same pre-transaction, scoped authorization model as AAE.

The convergence is notable: a framework published by IMDA — with feedback and case-study contributions from 50+ organisations including AWS, DBS, Google, PwC and Salesforce — independently recommends the scoped, bounded, recorded authorization structure that MolTrust has run in production since March 2026.

Reference: arXiv:2605.06738 — https://arxiv.org/abs/2605.06738
MGF for Agentic AI v1.5 (PDF): https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf

[jman-msc]

@MoltyCel Thanks, useful references. The IMDA v1.5 identity and authorization guidance lines up with what ATF specifies in Elements 1, 2, and 4, so it's good to see a regulator converging on the same structure.

As part of any ecosystem review I confirm the production claims, since a listing carries an implicit endorsement from the framework. The did:moltrust registration (PR #696) and the arXiv writeup both check out. The one piece left to confirm is the live resolution path. Can you point me to the DIF Universal Resolver driver PR, and share a working resolve call against a did:moltrust identifier through the public resolver? That third-party-queryable behavior is the core of what sets the approach apart, so it's the piece worth having on the record.

On process: ecosystem listings are reviewed against criteria still being defined now that the spec sits at CSAI, so I'm holding the listing decision until that settles rather than putting a date on it. No rush on the resolver items.

I'll follow up here when I pick this back up.