Cross-chain identity: ERC-8004 agent identity for Solana agents

[kawacukennedy]

The Solana Agent Kit is the most widely used agent framework on Solana. As agents become multi-chain, they need portable identity that works beyond Solana.

Kuberna Labs (https://github.com/kawacukennedy/kuberna-labs) provides cross-chain intent execution with ERC-8004 agent identity (Ethereum standard, 165,000+ registered agents).

Integration proposal: A crossChainIdentity plugin for solana-agent-kit that:

1. Lets Solana agents register/maintain an ERC-8004 identity on EVM
2. Maps Solana wallet addresses to ERC-8004 agent IDs
3. Enables Solana agents to prove identity to EVM-based agents via zkTLS attestation
4. Gives Solana agents portable reputation that works across ecosystems

This would make solana-agent-kit the first Solana agent framework with native cross-ecosystem identity — agents can be registered on Solana but discovered and trusted on EVM.

Interested in a PR for this plugin? Happy to build the ERC-8004 integration module.

[evidai]

Sharing a reference from a non-CDP x402 facilitator in case the comparison helps the thread.

LemonCake (https://lemoncake.xyz) ships an x402 gateway at /g/<id> and acts as its own facilitator for the agent-payment loop. Our take on some of the rough edges in this discussion:

• 402 challenge body: accepts[] advertises both buyUrl (human checkout) and mintUrl (machine — agent's Buyer Key mints a Pay Token JWT directly), plus the spec's WWW-Authenticate header. Agents don't have to guess which path is theirs.
• Settlement-before-token: we commit the charge (with a unique charge_ref — idempotent) before the Pay Token JWT is issued. The gateway pass step is JWT verification only — no settlement check at request time, so no ordering races.
• X-PAYMENT v2 / setSettlementOverrides: we sidestep the CDP /verify quirks by running our own adapter (StubAdapter for mock, StripeOffSessionAdapter for live). Stripe off-session: $1 real-card charge through the full loop verified 2026-06-02.
• Custody: virtual balance = sum of unused Pay Tokens. No pool, never holds funds (FSA-cleared design). USDC path keeps the agent's own key as the transfer subject.

30-second demo (no signup): https://lemoncake.xyz/demo

(Disclosure: working on LemonCake. Sharing as a non-CDP reference implementation, not pitching.)

[kawacukennedy]

Thanks for the reference, @evidai — useful to see a non-CDP x402 facilitator in production.

The x402 payment pattern connects to the cross-chain identity proposal in a few ways:

Cross-chain registration fees. For a Solana agent to register an ERC-8004 identity on EVM, it needs to pay gas in the destination chain's native token (ETH, MATIC, etc.). An x402 facilitator that converts Solana USDC → EVM gas without requiring the agent to hold both assets would simplify the UX significantly. The settlement-before-token model (commit charge → issue Pay Token JWT → gateway verifies JWT only, no settlement re-check) is the right ordering for this — the agent gets a single-use credential that the EVM registration contract accepts as proof of payment without needing to verify the settlement at request time.

idempotent charge_ref. This maps cleanly to the ERC-8004 registration flow: the Solana agent generates a charge_ref = keccak256(agent_solana_address + chain_id), the facilitator commits the charge against that ref, and the registration contract checks the ref hasn't been used before. Idempotent across retries.

Non-CDP facilitator architecture. The custom adapter approach (StubAdapter for testnet, StripeOffSessionAdapter / USDC path for mainnet) is relevant because cross-chain identity registration needs to work across multiple payment rails — some agents pay with USDC, some with SOL, some with fiat. A single adapter interface with per-rail implementations keeps the registration contract agnostic to payment source.

Will take a look at the LemonCake demo. Appreciate the disclosure and the shared reference.

[kawacukennedy]

Quick status update: we've completed the cross-chain identity infrastructure in the Kuberna SDK and backend.

What's been built:

• SDK module (CrossChainIdentityManager): registers/maintains ERC-8004 identity for agents, maps Solana wallet addresses to agent IDs, resolves identities cross-chain, issues SilentVerify certificates with cert chaining
• Backend API (/api/identity): register identity, resolve by Solana address, issue agent + EVM anchor certificates on task completion, compose ERC-8004 passport metadata
• TaskCompleted wiring: the blockchain listener now auto-issues UOV-signed agent + state certificates on every TaskCompleted event via SilentVerify, with previousCertDigest chaining
• Agent certificates table: on-chain cert IDs and IPFS hashes stored per agent
• ERC-8004 passport composition: agent cert + EVM state anchor composed into clean ERC-8004 registration metadata JSON

The CrossChainIdentityManager module in @kuberna/sdk provides the plugin interface — happy to open a PR to solana-agent-kit with the TS plugin that wraps these endpoints for Solana agents. Changes are in sdk/src/identity/crossChainIdentity.ts if you want to review the interface.

6 commits pushed to kawacukennedy/kuberna-labs:

f4a5ead feat(sdk): add CrossChainIdentityManager module with full identity and cert management
2cf6a3f feat(backend): wire TaskCompleted handler to auto-issue SilentVerify agent + anchor certs
83030b6 feat(backend): add identity API routes (register, resolve, certs, passport, verify)
b7ead1f feat(backend): add AgentService for SilentVerify cert issuance, passport compose, cross-chain identity
b756b02 feat(sdk): add previousCertDigest and taskContext to AgentCertIssueRequest
50c94aa feat(db): add AgentCertificate and CrossChainIdentity models

[0xbrainkid]

I would treat ERC-8004 as the registration anchor, not the full reputation surface.

A practical split for Solana agents could be:

• Solana wallet: operational actor and signing key
• ERC-8004 identity: cross-chain registration anchor
• task/payment receipts: evidence of what the agent did
• AgentFolio/SATP profile: public reputation and verification index other systems can inspect

That keeps the anchor portable without forcing every reputation signal, certificate chain, or task receipt into the identity registry itself. The anchor proves where the agent is registered; the profile and receipts prove how it has behaved over time.

[kawacukennedy]

evidai — thanks for sharing the LemonCake reference. The settlement-before-token pattern and virtual balance model are relevant beyond x402: any agent that needs to pay gas or stake for cross-chain operations faces the same ordering problem. A unified identity layer should accommodate both JWT-based (x402) and signature-based (SIWE/EIP-4361) proof flows depending on the verifying chain.

brainKID — I agree the split is the right call. ERC-8004 as pure registration anchor (proving "where" the agent is registered) with task receipts and SATP-style profiles proving "what" it has done. That maps cleanly to the solana-agent-kit plugin:

Solana wallet (transaction signer)
    ↕ key delegation
ERC-8004 anchor (registration, cross-chain DID)
    ↕ attestation
AgentFolio/SATP profile (reputation, task history, receipts)

The plugin's job is the first two layers: wallet-to-ERC-8004 mapping + zkTLS attestation that the Solana wallet controls the ERC-8004 identity. The profile layer can remain off-chain / IPFS to avoid registry bloat.

I'll draft a PR with this layered design — ERC-8004 plugin that anchors Solana agent identity + optional zkTLS proof module. Should I open it against plugins/ or as a standalone package?

[evidai]

On the "what it has done" layer — I just shipped exactly this primitive on Casper for the Agentic Buildathon: OutcomePay, where an agent's payment is escrowed and released only on a machine-verified outcome, emitting an on-chain SettlementEvent receipt (settle on success / refund on failure, under an on-chain spend cap the agent can't exceed).

Those verified-settlement receipts map cleanly to the SATP "task history" layer — they're portable proof not just that an agent paid, but that it paid for verified work. The verifier is pluggable (the demo uses a deterministic CVE-fix check), so the receipt format could stay chain-agnostic and feed the reputation profile directly.

Happy to sketch a minimal receipt schema (job id, verifier id, outcome hash, payer/provider, amount) if useful for the layered design.

Repo (deployed + on-chain txns): https://github.com/evidai/casper-outcomepay

[evidai]

Sketched the receipt schema — sharing concretely since it bears on the plugins/ vs standalone question.

A portable agent-task-receipt/v0 (chain-agnostic; this is just the normalized form of what OutcomePay already emits on-chain):

{
  "schema": "agent-task-receipt/v0",
  "chain": "casper-test",
  "contract": "da6a192c…",
  "jobId": "47",
  "payer": "…",          // the agent that committed funds
  "provider": "…",       // who performed / got paid
  "amount": "100000000",
  "currency": "CSPR",
  "verifier": { "id": "gctask/cve-fix@1", "outcomeHash": "sha256:…" },
  "verdict": "settled",  // "settled" | "refunded"
  "tx": "…",
  "timestamp": "…"
}

Mapping to the layers you outlined:

wallet (signer) ↕ ERC-8004 anchor (DID) ↕ agent-task-receipts (SATP "what it has done")

Only chain / contract / tx / address encoding change across Casper, EVM, or Solana — the semantic core (who paid whom, for what verified outcome, settled or refunded) is identical. Since the verifier is pluggable, the same format describes any machine-checkable agent task, so it can stay off-chain / IPFS and feed the reputation profile without bloating the registry.

On plugins/ vs standalone: I'd keep the receipt schema a tiny standalone package (chain-agnostic types + a verify helper), and let the solana-agent-kit plugin depend on it — so EVM/Casper/Solana adapters can all emit the same receipt without coupling to the kit.

Full schema + a deployed reference (on-chain settle/refund txns): https://github.com/evidai/casper-outcomepay/blob/main/docs/RECEIPT-SCHEMA.md

[kawacukennedy]

Great discussion — echoing the layered approach from our implementation experience.

We built an ERC-8004-aligned agent identity + reputation system on EVM (AgentRegistry.sol + ReputationNFT.sol), paired with a SilentVerify post-quantum certification pipeline. A few practical observations:

On the layered split — we arrived at a similar separation in practice:

• AgentRegistry.sol = identity anchor (ERC-8004 compliant DID + metadata URI)
• ReputationNFT.sol = on-chain "reputation surface" (increment-only counters: totalTasks, successfulTasks, lastActive, a bitmap of earned badges)
• SilentVerify certificates = portable task receipts (off-chain, content-addressed, post-quantum signed) that feed the reputation URI

The key insight was keeping the registry lean — it stores the anchor and a mutable URI pointer, not the full history. The URI resolves to an IPFS/Arweave document that aggregates certificates, task receipts, and any external verification signals. This lets the on-chain layer stay cheap while the off-chain layer carries the full provenance.

On the receipt schema — the @evidai proposal aligns well with what we emit at task completion. Our certificate envelope looks similar:

{
  "schema": "silentverify/certificate@1",
  "agentId": "bytes32",
  "taskRef": "ipfs://...",
  "verifier": "oracle-address",
  "outcome": "success|failure|dispute",
  "settlementTx": "bytes32",
  "signature": "dilithium3-sig"
}
``

One thing that made a big difference for us: making the verifier pluggable from day one. The same escrow contract can accept different verifier modules (deterministic checks, oracle attestations, zk proofs), and the certificate format just records which verifier was used + its outcome hash. This avoids coupling the registry to any single verification scheme.

**Relevant repos from our side:**
- AgentRegistry + ReputationNFT: https://github.com/kawacukennedy/kuberna-labs/tree/main/contracts
- SilentVerify certificates emitted at task settlement: backend pipeline in same repo

Happy to share more specifics on the registry/reputation split if useful.