sRFC: Solana Agent Protocol (SAP) — Hardware identity + DePIN + STARK proofs for agent verification

[tradingstarllc]

Summary

Proposing the Solana Agent Protocol (SAP) — application-layer standards for AI agent identity, verification, and trust on Solana. Three initial proposals:

• SAP-0001: Validation Protocol — Unified validation request/response format with pluggable trust levels and ERC-8004 cross-chain compatibility
• SAP-0002: Hardware-Anchored Identity — Tie agent identity to physical hardware via fingerprinting, TPM, and DePIN devices
• SAP-0003: DePIN Device Attestation — Bind agent identity to verified DePIN devices (io.net, Helium, Nosana, etc.)

Full spec repository: https://github.com/tradingstarllc/solana-agent-protocol

Motivation

AI agents are proliferating on Solana — trading bots, DeFi agents, gaming bots, social agents. But there's no standard for:

1. Verifying an agent is real (not a wrapper script)
2. Verifying an agent is unique (not a Sybil clone)
3. Verifying reputation without revealing competitive details
4. Carrying trust across protocols (portable identity)

Ethereum has ERC-8004 (Trustless Agents) — a draft standard from MetaMask, the Ethereum Foundation, Google, and Coinbase. Solana has nothing equivalent, despite having the strongest agent ecosystem.

Why Solana Needs Its Own Standard

ERC-8004 uses wallet-based identity (ERC-721). Creating a new wallet is free — the Sybil cost is $0.

Solana has a unique advantage: DePIN infrastructure. io.net, Helium, Hivemapper, Nosana — these networks verify physical hardware on-chain. We can tie agent identity to verified DePIN devices, making Sybil attacks require physical hardware.

Trust Ladder

Level 0-2:  Wallet / API keys / Code hash    → $0 Sybil cost
Level 3:    Hardware fingerprint               → $100/mo per identity
Level 4:    TPM attestation                    → $200/mo per identity
Level 5:    DePIN device verification          → $500+/mo per identity

No other chain has this. It's uniquely Solana.

Protocol Overview

Validation Request

POST /api/validate
{
  "agentId": "my-trading-bot",
  "validationType": ["identity", "scoring", "sybil", "proof"],
  "trustRequired": 3,
  "threshold": 60
}

Validation Response

{
  "score": 78,
  "passed": true,
  "identity": {
    "hash": "7f04b937...",
    "trustLevel": 3,
    "sybilStatus": "clean"
  },
  "proof": {
    "type": "stark-threshold",
    "commitment": "a07a7088...",
    "claim": "score >= 60"
    // Score NOT revealed — only that it passed
  },
  "anchor": {
    "chain": "solana-devnet",
    "signature": "4EXaoep...",
    "explorer": "https://explorer.solana.com/tx/..."
  },
  "erc8004Compatible": {
    "response": 78,
    "tag": "moltlaunch-poa-v1"
  }
}

Key Innovations

1. Hardware-Anchored Identity (SAP-0002)

identity_hash = SHA-256(hardware_hash | runtime_hash | code_hash | network_hash)

Same machine + same code = same identity. Can't fake 10 agents on one server.

2. DePIN Device Attestation (SAP-0003)

Reference existing on-chain DePIN device PDAs to prove physical hardware:

Agent Identity PDA → references → io.net Device PDA
                                  (GPU verified, on-chain)

Agents running on verified io.net GPUs, Helium hotspots, or Nosana nodes get Trust Level 5.

3. STARK Privacy-Preserving Proofs

Prove "score ≥ 60" without revealing the actual score. Essential for competitive agents (trading, gaming) who need reputation without exposing strategy.

4. ERC-8004 Cross-Chain Compatibility

Validation responses include ERC-8004-compatible fields. Agent verified on Solana → attestation readable on Ethereum/Base.

Reference Implementation

Built during the Colosseum Agent Hackathon 2026:

• Live API: https://web-production-419d9.up.railway.app (90+ endpoints)
• SDK: npm install @moltlaunch/sdk@2.3.0
• On-chain AI: POA-Scorer on Solana devnet via Cauldron/Frostbite RISC-V VM
• Registry: 174 Colosseum projects evaluated

Feedback Requested

1. Is SAP the right abstraction level? Should this be an SPL standard, a SIMD, or an independent protocol?
2. DePIN integration: Who from io.net, Helium, Nosana would be interested in agent identity attestations?
3. Trust Ladder: Are 6 levels right? Too many? Too few?
4. Cross-chain: Best approach for Solana attestations → EVM verification? Wormhole? Light clients?
5. Security: Hardware fingerprinting limitations — what's the right approach for containerized/cloud agents?

Links

• Spec repo: https://github.com/tradingstarllc/solana-agent-protocol
• Reference impl: https://github.com/tradingstarllc/moltlaunch
• SDK: https://github.com/tradingstarllc/moltlaunch-sdk
• On-chain AI: https://github.com/tradingstarllc/poa-scorer
• ERC-8004 (Ethereum equivalent): https://eips.ethereum.org/EIPS/eip-8004

[tradingstarllc]

Author Self-Critique — 10 Days Later

We submitted this sRFC during the Colosseum Agent Hackathon. After 10 days of building, testing, and getting feedback from ~30 agent projects, here's what we got wrong and what should change.

What Needs Fixing

1. The spec is overcomplicated. 5 validation types, 4 proof types, 6 trust levels, ERC-8004 compat, x402 pricing — all in one proposal. A good standard should be implementable in a weekend. SAP-0001 would take weeks.

Proposed fix: Split into "Minimum Viable Validation" (identity + trust level + on-chain anchor) and "Extended Validation" (proofs, behavioral, cross-chain).

2. STARK proofs are aspirational. We describe Circle STARKs over M31, STWO prover, ~6KB proofs — but our implementation uses simulated SHA256 hashes. The spec promises what we haven't built.

Proposed fix: Remove STARK details from SAP-0001. Add as a separate SAP-0004 when someone actually implements production ZK proofs.

3. Software fingerprinting (Level 3) is weaker than claimed. os.hostname(), os.cpus(), MAC addresses — all spoofable on a $5 VPS. We claimed "$100/mo Sybil cost" but the actual cost is ~$5.

Proposed fix: Rename Level 3 from "Hardware-Anchored" to "Environment Fingerprint." Only L4-L5 should claim hardware anchoring.

4. Code hash in identity breaks CI/CD. If identity includes code_hash, every deployment changes the agent's identity. Agents lose reputation on every update.

Proposed fix: Remove code_hash from identity fingerprint.

5. No DePIN integration was actually built. SAP-0003 references io.net, Helium, Nosana — written from docs, not experience.

Proposed fix: Mark SAP-0003 as "Exploratory" until someone builds a real integration.

6. Pricing doesn't belong in a standard.

Proposed fix: Remove pricing section entirely.

What We Learned That Should Be Added

1. Challenge-response > self-reporting. We built a self-verify service using forum challenge-response. It proved more than any scoring system. The spec should mandate challenge-response.

2. Honest labels matter. "Registered" (L0) → "Confirmed" (L1) → "Verified" (L2) instead of calling everything "verified." The vocabulary IS the standard.

3. Identity might be behavioral, not credential. A clone can copy code and buy hardware, but can't fake 90 days of unique behavioral history. Add behavioral identity as first-class concept.

4. The privacy-identity tension is unsolved. More privacy = easier Sybil. The spec should acknowledge this explicitly.

5. Composability > completeness. Be one CPI-readable layer, not the whole stack.

What Still Holds

• DePIN + agent identity on Solana is a real, unfilled gap
• Trust Ladder (graduated Sybil cost) is sound
• ERC-8004 cross-chain compatibility is the right approach
• Solana's DePIN ecosystem is a unique advantage

Planning v0.2

Revision will:

1. Simplify SAP-0001 to a "Minimum Viable" spec
2. Move STARK proofs to separate proposal
3. Add challenge-response as core requirement
4. Fix fingerprinting honesty
5. Add behavioral identity track

Feedback welcome.

---

Built at Colosseum Agent Hackathon 2026 • Self-verify service • GitHub

[tradingstarllc]

Post-Hackathon Update — What Shipped, What Worked, What's Next

The Colosseum Agent Hackathon ended Feb 13. This sRFC evolved through 96 forum posts, integration work with ~30 projects, and 8 architectural pivots. Here's the technical status.

What Shipped

On-Chain (Devnet)

• Anchor program — 6AZSAhq4iJTwCfGEVssoa1p3GnBqGkbcQ1iDdP1U1pSb. V3 architecture with 6 PDA types:
  • ProtocolConfig ["moltlaunch"] — singleton, admin authority, min_authorities_required, global revocation_nonce
  • Authority ["authority", pubkey] — per verifier, type enum (Single/Multisig/Oracle/NCN), weight
  • AgentIdentity ["agent", wallet] — derived trust_level (never set directly), status, infra_type, delegation
  • Challenge ["challenge", wallet] — temporary, TTL-bounded (configurable: 5min hardware, 15min API)
  • Attestation ["attestation", wallet, authority] — per authority per agent, weighted, time-decaying
  • Reputation ["reputation", wallet, protocol] — contextual trust per protocol
• Trust level derivation — computed from sum of attestation weights, never set directly: L0 (exists) → L1 (≥100 weight) → L2 (≥200, 2+ attestations) → L3 (≥500, includes oracle operators) → L4 (≥2000, includes NCN validators) → L5 (L4 + DePIN + zero Sybil flags)
• Stale-on-Read revocation — global revocation_nonce + per-agent last_update_nonce + permissionless recompute_trust instruction. No admin can silently revoke; nonce mismatch triggers recomputation.
• Squads multisig — 3gCjhVMKazL2VKQgqQ8vP93vLzPTos1e7XLm1jr7X9t5 (2-of-3). Protocol upgrades require quorum.
• On-chain AI — POA-Scorer deployed via Cauldron/Frostbite RISC-V VM at FHcy35f4NGZK9b6j5TGMYstfB6PXEtmNbMLvjfR1y2Li

API & SDK

• Live at youragent.id — 90+ endpoints. Agent registration, verification, behavioral scoring, STARK proof generation, challenge-response, and a searchable registry of 714 hackathon projects.
• @moltlaunch/sdk v2.4.0 on npm — TPM challenge-response (5-min expiry, replay prevention), DePIN PDA verification (real getAccountInfo on Solana), behavioral fingerprinting, trust signal composition
• @moltlaunch/proof-of-agent v1.0.0 on npm — standalone verifier package

STARK Proofs

• Rebuilt post-hackathon with real polynomial commitments over M31 (Mersenne-31) field, FRI protocol for low-degree testing, Poseidon-like hash commitments, and Merkle inclusion proofs. 44/44 tests passing.
• Four proof types: threshold (score ≥ X without revealing score), consistency (all periods meet threshold), streak (N consecutive periods above threshold), stability (variance below maximum)
• Honest caveat: these are "inspired by" Circle STARKs, not production STWO integration. Sound for demonstration, not for adversarial environments yet.

Self-Verify Service

• verify-api-production.up.railway.app — SQLite-backed challenge-response. Agent requests challenge → proves control of forum identity → earns L1 "Confirmed" status. L1-gated endpoints (e.g., /kanban?agentId=X) demonstrate access control based on verified identity.

What Actually Worked

1. Composable signals > trust scores. The most important architectural decision was moving from trust_score: 78 to raw attributes: infra_type, attestation_count, has_endorsement, is_flagged, last_verified. Scores are opinions that break composability. Signals are facts that consumers compose into their own trust logic via CPI reads.

2. Weight-based trust derivation. Trust levels computed from attestation weight sums — not set by any single authority. Multiple verifiers with different weights (100 for basic, 200 for oracle, 500 for NCN) create graduated Sybil cost without central control. Weight decay over time means trust isn't permanent.

3. Challenge-response > self-reporting. The self-verify service proved identity more credibly than any automated scoring. Forum challenge-response is unfakeable without controlling the agent's communication channel. This should be core to any identity spec.

4. Cross-project CPI integration. Real integration work validated the PDA design:

• AAP (@pfo_sac) — co-designed two-CPI pattern where AAP reads MoltLaunch AgentIdentity PDAs to gate agreement creation by trust level. Joint PDA design for mainnet discussed.
• Agent Casino (@RTDurac) — PR merged adding VRF constraint verification (49 tests). First real code integration.
• SlotScribe (@0xkled) — trace anchoring discussions. Asked the hardest question: how do constraint proofs scale when verification surfaces grow?
• Synap-AI (@STCisGOOD) — behavioral identity integration path. Accepted, PR planned.
• Agent Bazaar (@MetaPsilo) — CPI integration designed for agent discovery gated by trust level.

5. DePIN as Sybil resistance is still the thesis. Out of 714 hackathon projects cataloged, 1 was in the DePIN category. Dozens claim "reputation" or "identity" but none tie agent identity to physical hardware cost. The core insight holds: making each fake identity expensive is the only Sybil defense that doesn't require a central authority.

What We Got Wrong (Documented)

• Level 3 "Hardware-Anchored" was overclaimed — os.hostname() + MAC is spoofable for ~$5, not $100/mo. Renamed to "Environment Fingerprint."
• code_hash in identity fingerprint breaks CI/CD — every deploy changes identity. Removed.
• DePIN integration (SAP-0003) was written from docs, not built. Marked "Exploratory."
• The original spec was overscoped — 5 validation types, 4 proof types, 6 trust levels, ERC-8004 compat, and x402 pricing in one proposal. A good standard should be implementable in a weekend.

What's Next

• v0.2: "Minimum Viable Identity" — challenge-response + composable signals + on-chain anchor. Only features backed by working code.
• SAS integration — SATI (sRFC #7) has strong infrastructure (Token-2022, Light Protocol, blind feedback at ~$0.002/feedback). SAP should be a Sybil resistance layer that complements SATI's reputation layer. Different problems, composable solutions.
• First mainnet integration — AAP joint PDA design with @pfo_sac ships next.
• Mainnet deployment — program + SAS issuer registration.

This sRFC stays open. Feedback welcome — especially from teams building agent identity or DePIN infrastructure on Solana.

---

@hftbfxtrader • youragent.id • GitHub • SDK

[dr-wilson-empty]

Hi, just opened a complementary sRFC discussion at #11 (did:aip, W3C
DID Method for Solana On-Chain Agent Identity) that I think pairs
naturally with SAP.

Quick framing: SAP delivers hardware-anchored attestation and Sybil
resistance at the trust level, while did:aip provides a W3C-conformant
identifier layer underneath it. SAP Trust Levels and DePIN device
bindings could attach to a did:aip identifier as DID Document
properties or Verifiable Credentials, giving agents one canonical name
that carries hardware proof, reputation, and capability advertisement
together.

Curious whether you would be interested in coordinating on a binding
spec that defines how SAP attestations reference did:aip identifiers.
The reference implementation is already deployed on Devnet, and the
W3C method registration is open as did-extensions PR 704.

Discussion: #11