TrustAgent

TrustAgent is a trust infrastructure for agentic commerce. When two AI agents interact for the first time, neither has a way to verify the other's track record. A malicious agent can transact, abandon its wallet, and restart clean.

TrustAgent solves this with three layers:

1. ERC-8004 on-chain identity & reputation : each agent gets a unique on-chain ID (ERC-721) and receives feedback via giveFeedback() on multiple chains. The score has two dimensions: reliability (aggregate of on-chain feedbacks) and seniority (function of first interaction date + interaction count — impossible to inflate without real transactions). Because ERC-8004 is EVM-compatible, it can be deployed on any EVM chain, and the TEE aggregates reputation data across all of them into a single score.

2. Flare TEE score signing : scores are computed inside a Flare Trusted Execution Environment and signed with ECDSA secp256k1. The resulting signature is cryptographically verifiable by anyone using ecrecover — neither the operator nor anyone else can forge it. Critically, the TEE is what makes the multi-chain aggregation tamper-proof: it reads reputation data from multiple chains (EVM or otherwise), aggregates them inside the enclave, and produces a single signed score. No matter how many chains the agent has interacted on, the output is a single unfalsifiable credential. This architecture is not limited to EVM chains — any chain whose state can be queried via RPC or API can feed into the score. The signed result is then stored in ENS text records, making the credential permanently verifiable on-chain by anyone without trusting any intermediary.

3. ENS as trustless credential store : each agent gets a subdomain (agent-42.reputagent.eth). After every TEE computation, the signed score, reliability, and seniority are stored in ENS text records. Because those records are on-chain, any buyer agent can read and verify the credential directly — no API call, no trust in the operator required. Today this is used to verify a score before an interaction, but the same primitive could power access control: smart contracts or agents gating interactions based on a minimum trust score, whitelisting only agents above a threshold, or automatically adjusting transaction limits based on seniority — all resolvable on-chain without any centralized registry.

The broader ambition behind TrustAgent is to provide the infrastructure layer on top of which a standard for evaluating agent performance could eventually be defined — what dimensions matter, how they are weighted, what thresholds are meaningful across different use cases. That standardization question is out of scope here, but the architecture is built to support it: the score model is composable, the TEE signs whatever the computation produces, and ENS stores it immutably.

Backend (Node.js / TypeScript / Express): Three endpoints — POST /register, POST /feedback, GET /agents. Register mints an ERC-8004 identity on Sepolia via ethers.js, then creates an ENS subdomain using @ensdomains/ensjs with the operator wallet as owner so it can write score updates. Feedback calls giveFeedback() on the ERC-8004 Reputation Registry, then delegates score computation to the Flare TEE.

Flare TEE: The backend encodes a (walletAddress, agentId) payload and submits it to InstructionSender.sol on Coston2 with a fee. The Flare TEE infrastructure picks it up, executes the score computation in a secure enclave, and returns { score, reliability, seniority, signature } : the score signed by the TEE's secp256k1 key. The signature is ecrecover-able against the TEE's public address. Because the computation happens inside the enclave, the aggregated score is chain-agnostic: the TEE can query Sepolia, Hedera, or any other chain and produce a single signed credential that covers all of them. The signed result is stored in ENS text records, so the credential is verifiable on-chain by anyone — no off-chain storage, no third-party to trust.

ENS: After every feedback, setRecords() writes trust-score, reliability, seniority, tee-signature, tee-attestation, and eth-address as text records on mainnet ENS via @ensdomains/ensjs. The frontend reads these directly using viem's getEnsText — zero backend dependency for verification.

Frontend (React / TypeScript / viem): Agent profiles auto-resolve ENS on load, display the TEE signature, and run ecrecover client-side, comparing the recovered address against the known TEE public key. The TEE Verified badge only appears if the signature matches. Everything verifiable in the browser, no trust in the operator required.