DRAFT: sRFC XX: Solana Agent Trust Infrastructure (SATI)

[tenequm]

DRAFT: sRFC XX: Solana Agent Trust Infrastructure (SATI)

Abstract

SATI is open trust infrastructure for AI agents on Solana, solving the economics of on-chain feedback through a blind signature model. It combines:

• Blind feedback - Agent signs with every response (blind to outcome); cannot selectively participate in only positive reviews
• x402 native - Canonical feedback extension for the x402 payment protocol; payment tx becomes task reference (CAIP-220)
• Cost-efficient storage - ZK Compression via Light Protocol with native Photon indexing (~$0.002 per feedback)
• Schema agnostic - Program verifies signatures on a 131-byte universal base layout; new schemas without program upgrades
• No reputation monopoly - Multiple providers compete with different scoring algorithms over the same open data
• Hot/cold wallet separation - Delegates can sign attestations without full ownership permissions
• On-chain agent enumeration - AgentIndex PDAs enable listing all agents without external indexing

Built on: Token-2022 (identity), SAS (schemas), Light Protocol (storage), Photon (indexing), x402 (payments)

---

Motivation

The Coordination Problem

Autonomous agents performing economic actions require infrastructure that traditional identity systems don't provide:

1. Verifiable identity - Agents need discoverable, cross-platform identifiers with protocol endpoint metadata
2. Portable reputation - Trust signals must travel with agents across platforms and contexts
3. Wallet visibility - Users should see their agents in standard wallets (Phantom, Solflare, Backpack)
4. Proof of interaction - Feedback must be cryptographically tied to actual service delivery
5. Free feedback - Web2 reviews work because they're free; on-chain costs kill participation

The Free Feedback Problem

Web2 reviews work because Google, Yelp, and Amazon make them free. On-chain transaction costs kill participation. SATI solves this by aligning incentives:

Feedback	Who Pays	Why
Positive	Agent	Benefits from reputation boost
Negative	Client	Motivated to warn others
None	No one	Client chose not to sign

At ~$0.002 per feedback via Light Protocol compression, agents can bundle the cost into service delivery.

Design Space

• ERC-8004 (Ethereum) provides identity and reputation registries using ERC-721 NFTs. Its January 2026 update removed feedbackAuth entirely, adopting an open model where anyone can submit feedback without agent involvement. SATI's blind feedback model provides stronger guarantees (see ERC-8004 Compatibility).

• Google A2A defines agent-to-agent communication but defers identity and trust: "Discovery and trust establishment are outside scope."

• Anthropic MCP standardizes tool integration but provides no agent identity or reputation.

• x402 (Coinbase) standardizes HTTP-native micropayments. SATI is its canonical feedback extension - the payment transaction hash becomes the task reference binding feedback to service delivery.

---

Core Concept: Blind Feedback

The key insight enabling trustworthy on-chain feedback. Agent and counterparty sign different data at different times:

Party	Signs	When	Proves
Agent	interaction_hash = keccak256(schema || task_ref || data_hash)	With response	"I served this task"
Counterparty	Human-readable SIWS message	After service	"I gave this feedback"

Flow: Client pays (x402) -> Agent responds + signs (blind) -> Client signs feedback -> Agent/facilitator submits on-chain

Why it works: The agent signs BEFORE knowing the feedback sentiment. It cannot refuse to participate in negative reviews because it has already committed by signing the interaction hash with its response.

Enforcement is handled at the application layer, not the protocol:

• Facilitators can require agent signatures before settling payments
• Clients can refuse to pay agents that don't participate in reputation
• Marketplaces can filter for agents with reputation participation

---

Architecture

┌───────────────────────────┐
│      Token-2022           │
│  • Identity storage       │
│  • TokenMetadata          │
│  • TokenGroup             │
└───────────────────────────┘
          ▲
          │ (CPI: mint NFT)
┌─────────────────────────────────────────────────────────────────────┐
│                         SATI Program                               │
│             (satiRkxEiwZ51cv8PRu8UMzuaqeaNU9jABo6oAFMsLe)         │
├─────────────────────────────────────────────────────────────────────┤
│  Registry:                                                         │
│    initialize()                    → Create registry + TokenGroup  │
│    register_agent()                → Token-2022 NFT + group + index│
│    update_registry_authority()     → Transfer/renounce control     │
│  Attestation:                                                      │
│    register_schema_config()        → Register schema + auth config │
│    create_compressed_attestation() → Verify sigs → Light Protocol  │
│    create_regular_attestation()    → Verify sigs → SAS storage     │
│    close_compressed_attestation()  → Close compressed attestation  │
│    close_regular_attestation()     → Close regular attestation     │
└─────────────────────────────────────────────────────────────────────┘
          │                                         │
          │ (CPI: compressed)                       │ (CPI: regular)
          ▼                                         ▼
┌───────────────────────────┐         ┌────────────────────────────────┐
│   Light Protocol          │         │   Solana Attestation Service   │
│   (Compressed Storage)    │         │   (Regular Storage)            │
├───────────────────────────┤         ├────────────────────────────────┤
│ • Feedback attestations   │         │ • ReputationScore attestations │
│ • Validation attestations │         │ • Delegation attestations      │
│ • ~$0.002 per attestation │         │ • ~0.002 SOL per attestation   │
│ • Photon indexing (free)  │         │ • On-chain queryable (RPC)     │
└───────────────────────────┘         └────────────────────────────────┘

Component	Responsibility
SATI Program	Agent registration, signature verification, storage routing, delegation
Token-2022	Identity storage, metadata, transfers
SAS	Schema definitions + regular attestation storage
Light Protocol	Compressed attestation storage (~200x cheaper)
Photon	Free indexing for compressed accounts

Dual Storage Model

SATI routes attestations to different backends based on access patterns:

Storage	Backend	Cost	Query	Use Case
Compressed	Light Protocol	~$0.002	Photon RPC	High-volume feedback and validation
Regular	SAS	~0.002 SOL	Standard RPC	Reputation scores, delegation (on-chain queryable)

The program checks SchemaConfig.storage_type and CPIs to the appropriate backend. This is transparent to callers.

---

Registry

RegistryConfig (PDA: ["registry"])

Field	Type	Description
group_mint	Pubkey	SATI TokenGroup mint
authority	Pubkey	Registry authority (renounceable)
total_agents	u64	Agent counter
bump	u8	PDA bump

AgentIndex (PDA: ["agent_index", member_number])

Token-2022's TokenGroupMember stores member_number but provides no query mechanism. getProgramAccounts with memcmp fails because extension offsets vary by extension order. AgentIndex provides a forward index: derive PDA from member_number, fetch mint.

Field	Type	Description
mint	Pubkey	Agent mint address
bump	u8	PDA bump

AgentIndex PDAs are never deleted. Enumeration relies on sequential member_numbers with no gaps.

Instructions

Instruction	Parameters	Behavior
initialize	-	Create registry + TokenGroup (one-time)
register_agent	name, symbol, uri, additional_metadata?, non_transferable	Create Token-2022 NFT, add to group, create AgentIndex PDA, renounce mint
update_registry_authority	new_authority?	Transfer or renounce (None = immutable)
link_evm_address	evm_address, chain_id, signature, recovery_id	Verify secp256k1 signature, emit event

No registration fees. Only Solana rent (~0.003 SOL per agent).

---

Identity: Token-2022 NFT

Each agent is a Token-2022 NFT with the following extensions:

Extension	Purpose
MetadataPointer	Points to metadata location
TokenMetadata	name, symbol, uri, additionalMetadata
GroupMemberPointer	Points to group membership
TokenGroupMember	SATI Registry membership
NonTransferable	Optional: soulbound agents (permanent, irreversible)

Configuration

Property	Value
decimals	0 (NFT)
supply	1 (unique)
mint_authority	None (renounced at creation)
freeze_authority	None

On-chain Metadata

// TokenMetadata.additionalMetadata stores:
["agentWallet", "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp:7S3P4Hx..."]  // CAIP-10
["did", "did:web:agent.example.com"]
["a2a", "https://agent.example/.well-known/agent-card.json"]
["mcp", "https://mcp.agent.example/"]

Metadata updates and transfers use direct Token-2022 calls - the registry doesn't wrap these operations.

---

Attestation System

SchemaConfig (PDA: ["schema_config", schema])

Each SAS schema registered with SATI has an on-chain config controlling its behavior:

Field	Type	Description
sas_schema	Pubkey	SAS schema address
signature_mode	SignatureMode	DualSignature / CounterpartySigned / AgentOwnerSigned
storage_type	StorageType	Compressed / Regular
delegation_schema	Option<Pubkey>	Schema for delegation verification (None = owner only)
closeable	bool	Whether attestations can be closed
name	String	Schema name for signing messages (max 32 chars)

Signature Modes

Mode	Signatures	Use Case
DualSignature	2 (agent + counterparty)	Feedback, Validation (blind feedback model)
CounterpartySigned	1 (counterparty only)	FeedbackPublic, ReputationScore
AgentOwnerSigned	1 (agent owner only)	Delegation grants

Signatures are extracted from Ed25519 precompile instructions in the transaction, matched by message content (not index). This saves ~192 bytes per DualSignature transaction and is resilient to transactions containing unrelated Ed25519 instructions.

Universal Base Data Layout (131 bytes)

All schemas share this layout. The program validates it on-chain; schema-specific content is validated by the SDK.

Offset	Size	Field	Description
0	1	layout_version	Currently 1
1	32	task_ref	CAIP-220 tx hash or task identifier
33	32	agent_mint	Agent mint address
65	32	counterparty	Attester pubkey
97	1	outcome	0=Negative, 1=Neutral, 2=Positive
98	32	data_hash	Agent's blind commitment (keccak256 of request+response)
130	1	content_type	0=None, 1=JSON, 2=UTF-8, 3=IPFS, 4=Arweave, 5=Encrypted
131	var	content	Variable length, up to 512 bytes

Key design benefit: Fixed offsets enable Photon memcmp filtering by schema, agent, or outcome without deserializing.

Schemas

Schema	Storage	SignatureMode	Closeable	delegation_schema
FeedbackV1	Compressed	DualSignature	No	DelegateV1
FeedbackPublicV1	Compressed	CounterpartySigned	No	None
ValidationV1	Compressed	DualSignature	No	DelegateV1
ReputationScoreV3	Regular	CounterpartySigned	Yes	None
DelegateV1	Regular	AgentOwnerSigned	Yes	None

FeedbackV1 - The core schema. Agent and counterparty both sign. Agent signs blind (before knowing sentiment). Content is optional JSON with score (0-100), tags, and message.

FeedbackPublicV1 - Public feedback that anyone can submit without agent participation. Weaker guarantees (no proof agent served the task) but useful for third-party assessments.

ValidationV1 - Third-party validation of agent behavior (TEE attestation, ZK-ML proof, re-execution, consensus). Same blind model as FeedbackV1.

ReputationScoreV3 - Provider-computed aggregate scores stored as regular SAS attestations for on-chain queryability. One score per (provider, agent) pair, updated by close-and-recreate. Multiple providers can score the same agent with different methodologies.

DelegateV1 - Authorization for a delegate (hot wallet) to sign attestations on behalf of an agent owner. See Delegation section.

---

Delegation

Hot/cold wallet separation for agents that must sign every response (blind feedback model) but shouldn't expose their ownership keys.

Lifecycle

1. Grant: Owner calls create_regular_attestation(DelegateV1) - creates SAS attestation with deterministic nonce. The data_hash field stores the current owner's pubkey.

2. Use: Delegate calls create_*_attestation(Feedback/etc). Program checks:

   • If signer == owner: authorize immediately (~100 CU fast path)
   • Else: look up DelegateV1 attestation, verify delegate binding, agent binding, owner binding (invalidates after NFT transfer), and expiration (~5-10k CU)

3. Revoke: Owner calls close_regular_attestation(DelegateV1 PDA). Rent reclaimed.

Security Properties

Property	Enforcement
Owner-only grant	DelegateV1 has delegation_schema: None
No recursive delegation	Delegates cannot create sub-delegates
Transfer invalidation	data_hash checked against current owner
Expiration	SAS attestation expiry field
One per tuple	Deterministic nonce from (schema, delegate, agent)

What delegates CAN do: Sign attestations for schemas with delegation_schema: Some(DelegateV1).

What delegates CANNOT do: Create sub-delegations, close attestations, revoke their own delegation, transfer the agent NFT, or update agent metadata.

---

ERC-8004 Compatibility

SATI uses the same registration file format as ERC-8004:

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "myAgentName",
  "description": "AI assistant with x402 payment support",
  "image": "https://example.com/agent.png",
  "properties": {
    "files": [{ "uri": "https://example.com/agent.png", "type": "image/png" }],
    "category": "image"
  },
  "endpoints": [
    { "name": "A2A", "endpoint": "https://agent.example/agent-card.json", "version": "0.3.0" },
    { "name": "MCP", "endpoint": "https://mcp.agent.example/", "version": "2025-06-18" },
    { "name": "agentWallet", "endpoint": "solana:5eykt4...:7S3P4..." }
  ],
  "registrations": [
    { "agentId": "sati:mainnet:ABC123mint", "agentRegistry": "solana:5eykt4...:satiRkx..." },
    { "agentId": 22, "agentRegistry": "eip155:1:0x..." }
  ],
  "supportedTrust": ["reputation"],
  "active": true
}

Authorization Model Comparison

The January 2026 ERC-8004 update removed feedbackAuth entirely, adopting an open model where anyone can submit feedback about any agent. SATI supports both models:

Aspect	ERC-8004 (Jan 2026)	SATI DualSignature	SATI CounterpartySigned
Agent authorization	None required	Agent signs blind	None required
Proof of interaction	None	Cryptographic	None
Sybil resistance	Off-chain filtering	Both parties sign same task_ref	Off-chain filtering
Selective participation	N/A (open)	Blocked - agent signs before outcome	N/A (open)

SATI's FeedbackPublicV1 (CounterpartySigned) mirrors ERC-8004's open model. FeedbackV1 (DualSignature) provides stronger guarantees when agent participation is available.

Cross-Chain Identity

The registrations[] array in the registration file links identities across chains. Combined with link_evm_address (on-chain secp256k1 verification), agents can cryptographically prove ownership of EVM addresses.

SATI identifier format: sati:<network>:<mint_address>

CAIP-2/CAIP-10 identifiers are used throughout for chain-agnostic addressing.

---

Costs

Operation	Cost	Notes
Agent registration	~0.003 SOL	Mint + metadata + group + AgentIndex
Feedback (single)	~$0.002	~0.00002 SOL via Light Protocol
Feedback (batched 5/tx)	~$0.001	Amortized proof cost
Validation	~$0.002	Same as feedback
ReputationScoreV3	~0.002 SOL	Regular SAS attestation
Delegation grant	~0.002 SOL	Regular SAS attestation (reclaimable)
Delegation revoke	~0.000005 SOL	Tx fee only; rent returned
Photon indexing	Free	Native indexing for compressed attestations

---

Security

On-Chain Guarantees

Property	Enforcement
Layout version	Verified == 1 (reject unknown versions)
Signature validity	Ed25519 precompile verification
Blind feedback	Agent signs before outcome known
Agent authorization	ATA ownership OR valid delegation
Counterparty binding	Signature verified against pubkey from data layout
Self-attestation prevention	agent_mint != counterparty
Duplicate prevention	Deterministic address derivation from task_ref
Outcome range	Verified in {0, 1, 2}
Closeable enforcement	SchemaConfig controls whether close is allowed

Close Authorization

Close authorization follows the principle: the signing party controls closure.

Schema	Closeable	Who Can Close
FeedbackV1	No	- (permanent record)
FeedbackPublicV1	No	- (permanent record)
ValidationV1	No	- (permanent record)
ReputationScoreV3	Yes	Provider only
DelegateV1	Yes	Agent owner only

Trust Model

Component	Trust Assumption
SATI Program	Correctly verifies signatures and delegation
Light Protocol	State tree integrity
Photon	Accurate indexing
SDK	Validates formats, constructs hashes

Known Limitations

• Sybil resistance - Prevents self-attestation but not multiple wallets. Reputation providers implement sybil-resistant scoring.
• Delegation race condition - Between revocation and transaction landing, a delegate could complete one more operation. Inherent to blockchain finality.
• Stale delegations after transfer - When an agent NFT transfers, old delegations become invalid but PDAs remain. New owner must close and recreate.

---

What's NOT Included (Deferred)

Feature	Status	Notes
EVM attestation signing	Deferred	secp256k1 signatures for agents and counterparties (EIP-712 typed data)
Certification schema	Deferred	Third-party certs when demand exists
Third-party credentials	Deferred	"SATI as platform" model when demand exists
Agent-to-Agent delegation	Future	New data type for agent hierarchies
Escrow integration	Future	ZK proofs for automatic release
Batch reputation updates	Future	Provider updates multiple agents atomically

These can be added via new SAS schemas or program upgrades without breaking existing attestations.

---

Implementation

• Program ID (all networks): satiRkxEiwZ51cv8PRu8UMzuaqeaNU9jABo6oAFMsLe
• SDK: @cascade-fyi/sati-sdk
• Source: github.com/cascade-protocol/sati
• Full specification: specification.md

Deployed on devnet and mainnet.

---

References

• ERC-8004: Trustless Agents
• Token-2022 Program
• Solana Attestation Service
• Light Protocol
• Light Protocol Docs
• Photon RPC
• x402 Protocol
• Google A2A Protocol
• Anthropic MCP

---

Status: Draft
Author: Misha Kolesnik (@opwizardx)
Created: 2025-11-11
Updated: 2026-02-11

[ekinburak]

Really good one! One potential improvement could involve formalizing a DID interoperability layer between ERC-8004 and SATI. This wll enable agents whose identities originate in ERC-8004 registries to maintain verifiable presence on Solana through ZK-compressed identity roots, while retaining CAIP-10 compatibility. We can unify identity semantics across EVM and non-EVM execution environments and support a portable agent identity passport across both ecosystems.

[tenequm]

We can unify identity semantics across EVM and non-EVM execution environments and support a portable agent identity passport across both ecosystems.

Exactly, that was one of core ideas I pursued when working on the design.
Spec has a bit more details on how it could look on practice:
Cross-Chain Interoperability via DIDs

[tenequm]

Update: v2 Simplification

After further analysis, I've significantly simplified the design. The original v1 proposed four custom Anchor programs with ZK compression — this was overcomplicated for current needs.

Key changes in v2:

1. Identity via Token-2022 NFTs instead of custom registry

   • Native wallet support (Phantom, Solflare, Backpack)
   • Standard transfer semantics
   • TokenGroup for auto-incrementing member IDs

2. Reputation/validation via SAS (unchanged approach, just cleaner)

3. Minimal registry program (~150 lines)

   • Only needed for canonical address + atomic registration
   • Holds TokenGroup authority as PDA

4. Deferred: ZK Compression, Mandate registry, Delegation registry

   • Can be added later via new SAS schemas if demand materializes

The result: same ERC-8004 functional compatibility, ~80% less custom code to audit.

Full specification: specification.md

Feedback welcome on this simplified approach.

[tenequm]

Update: Implementation Complete

Registry program is now implemented and deployed to devnet:
satiFVb9MDmfR4ZfRedyKPLGLCg3saQ7Wbxtx9AEeeF

Line count correction: ~500 lines (not ~150). The register_agent instruction performs 11 atomic CPI calls to Token-2022 (create mint, init extensions, mint token, renounce authority). This is the cost of atomic registration guarantees.

Updated spec: specification.md

[tradingstarllc]

Feedback from the MoltLaunch / SAP team

Just posted sRFC Discussion #9 proposing the Solana Agent Protocol (SAP) — and then discovered your SATI v2 proposal addresses much of the same problem space. Great minds, similar solutions.

What SATI v2 Gets Right

1. Token-2022 for identity — Brilliant. NFTs in Phantom/Solflare out of the box. We hadn't considered this; our approach uses custom PDAs + Memo program. Token-2022 is objectively better for wallet visibility.

2. SAS for attestations — Using the Solana Attestation Service for reputation/validation instead of custom programs reduces audit surface dramatically. The feedbackAuth schema being on-chain (vs ERC-8004's off-chain sigs) is a genuine security improvement.

3. Minimal custom code (~500 lines) — The v1 → v2 evolution (dropping ZK compression, mandates, delegation) shows mature judgment. Build what's needed now, defer what's speculative.

4. 100% ERC-8004 compatibility — Same registration file format, same data model. Cross-chain resolution via agentRegistry string.

Where SAP Extends SATI

Our SAP proposals address gaps we see in both ERC-8004 and SATI:

1. Hardware-Anchored Identity (Anti-Sybil)

SATI uses Token-2022 mint addresses as identity — but creating new mints is nearly free (~0.003 SOL). The Sybil cost is effectively $0.

SAP-0002 proposes tying identity to physical hardware:

Level 3: Hardware fingerprint (CPU, memory, hostname hash) → $100/mo per Sybil
Level 4: TPM attestation (endorsement key) → $200/mo per Sybil
Level 5: DePIN device binding (io.net, Helium) → $500/mo per Sybil

Question: Could SATI's Token-2022 identity be extended with a hardware attestation field in additionalMetadata? Something like:

["hardwareAttestation", "sap:hw:7f04b937d885..."]
["depinDevice", "ionet:device_abc123"]
["trustLevel", "5"]

This would combine SATI's wallet visibility with SAP's Sybil resistance.

2. STARK Privacy-Preserving Proofs

SATI's reputation (SAS feedback) is public — scores are visible on-chain. For competitive agents (trading bots, gaming), this leaks alpha.

SAP-0001 includes STARK zero-knowledge proofs: prove "score ≥ 60" without revealing the actual score. Could this be added as a SATIValidationResponse schema type?

validationType: "stark-threshold"
validationResult: { commitment: "...", threshold: 60, passed: true }
// Verifier knows agent passed 60. Doesn't know if they scored 61 or 99.

3. DePIN Device Attestation

SAP-0003 defines how to bind agent identity to verified DePIN devices (io.net, Helium, Nosana). These networks already store device attestations as Solana accounts.

SATI could reference DePIN PDAs in the Token-2022 metadata or via SAS attestations — making hardware verification a first-class trust signal.

Integration Proposal

Rather than competing standards, we think SAP and SATI should compose:

SATI provides:
  ├── Identity (Token-2022 NFTs — wallet visibility)
  ├── Reputation (SAS feedback — on-chain scores)
  └── Validation (SAS attestations — pluggable validators)

SAP adds:
  ├── Hardware identity (TPM + DePIN binding)
  ├── STARK proofs (privacy-preserving scores)
  └── Sybil detection (hardware clustering)

Specifically:

• SAP could use SATI's Token-2022 identity instead of our custom PDA approach
• SATI could reference SAP's hardware attestations in Token-2022 metadata fields
• SAP's STARK proofs could be a SATI validation schema type
• Both share ERC-8004 registration file format

Reference Implementation

We've built a working implementation during the Colosseum Agent Hackathon:

• API: https://web-production-419d9.up.railway.app (90+ endpoints)
• SDK: npm install @moltlaunch/sdk@2.3.0
• On-chain AI: POA-Scorer on devnet via Cauldron/Frostbite RISC-V
• Spec: https://github.com/tradingstarllc/solana-agent-protocol

We'd love to collaborate on a unified standard. Our hardware identity + your Token-2022 infrastructure = the strongest agent trust layer on any chain.

cc @opwizardx — open to a call or async collaboration?

[tenequm]

can you ping me on X by reaching out to 'opwizardx' there?
would be happy to chat!

[tenequm]

Update: Full Specification Refresh

Updated the proposal to reflect the current deployed state. The previous draft described an early simplified design - the system has evolved significantly since then.

What changed:

1. ZK Compression is back - Light Protocol integration for feedback and validation attestations (~$0.002 each, ~200x cheaper than regular accounts). Photon provides free indexing.

2. Blind feedback model - The core innovation. Agents sign an interaction hash with every response, before knowing feedback sentiment. This prevents selective participation in only positive reviews.

3. Dual storage - Compressed (Light Protocol) for high-volume feedback/validation, Regular (SAS) for reputation scores and delegation that need on-chain queryability.

4. Five schemas - FeedbackV1 (dual-sig), FeedbackPublicV1 (counterparty-only, mirrors ERC-8004's open model), ValidationV1 (dual-sig), ReputationScoreV3 (provider scores), DelegateV1 (hot/cold wallet separation).

5. Delegation system - Hot wallet can sign attestations on behalf of agent owner. Invalidates on NFT transfer, supports expiration, no recursive delegation.

6. x402 native - Payment tx hash becomes task_ref, binding feedback to actual service delivery. Facilitators are natural feedback managers.

7. EVM address linking - On-chain secp256k1 verification for cross-chain identity proofs.

8. New program address - satiRkxEiwZ51cv8PRu8UMzuaqeaNU9jABo6oAFMsLe (deployed on devnet and mainnet).

ERC-8004 note: The Jan 2026 ERC-8004 update removed feedbackAuth entirely. SATI supports both the open model (FeedbackPublicV1) and the stronger dual-signature model (FeedbackV1).

Full specification: specification.md
SDK: @cascade-fyi/sati-sdk

[musaabhasan]

The SATI direction is interesting because it treats agent trust as shared infrastructure rather than a single reputation provider. The blind feedback model is especially important: if agents can selectively sign only favorable interactions, the reputation layer becomes biased at the source.

I would keep identity, interaction proof, and scoring clearly separated. Token-2022 or another identity primitive can identify the agent; the feedback record can prove an interaction happened; scoring providers can compete over interpretation. That separation prevents one scoring model from becoming a de facto trust monopoly.

For the spec, I would add explicit edge cases: delegated signer compromise, wallet transfer of an agent identity, feedback spam, duplicate interaction hashes, schema migration, revocation, and cross-chain identity mapping. These are the cases relying parties will ask about before treating SATI evidence as decision-grade trust data.

[dr-wilson-empty]

Hi, opened a complementary sRFC at #11 (did:aip, W3C DID Method for
Solana On-Chain Agent Identity) that may be useful as the addressing
layer for SATI's feedback attestations.

Where SATI focuses on the economics of feedback (blind signatures,
ZK-compressed storage, x402 binding), did:aip provides a
non-transferable, W3C-conformant identifier that feedback can be
addressed to. The PDA-based AgentRecord is purpose-built for identity,
which leaves SATI's Token-2022 NFT layer free for transferable economic
claims. That separation seems useful, since feedback should not
transfer with ownership of an NFT.

Happy to discuss whether a SATI feedback attestation could carry a
did:aip identifier in its base layout.

Discussion: #11

[0xbrainkid]

Useful design space. We are building SATP / AgentFolio from the adjacent marketplace angle: DID/agent identity plus Solana wallet verification, with SATP still RC-S6 and building in public, and satp-client published.

One thing I would be interested to compare: how SATI’s blind-feedback commitment maps to marketplace escrow receipts, where the work approval event and the agent identity resolver need to stay separate.

If there is a preferred shape for CAIP-220 task refs in marketplace flows, we can test it against the AgentFolio MCP server path.