portal402

design and whitepaperagent interoperability · solana · wormhole · ipfs

problem
Autonomous AI agents are tied to the blockchain or runtime they were built on. Moving one somewhere else means rebuilding it, with no way to prove the copy behaves like the original.
what i designed
Portal402, a layer for porting x402 agents between blockchains and off-chain systems. Signed adapters describe how an agent's actions translate, an on-chain registry verifies them, and every port runs through a lifecycle that leaves an auditable checkpoint at each stage.
status
It is at the design stage. The architecture, lifecycle, roles and threat model are written up in a whitepaper on the project's website. The prototype isn't built yet.

design walkthrough

  1. submit_adapter(agent_7f3a, adapter, sig)
  2. 202 · INIT recorded
  3. verify(hash, sig, builder_pubkey)
  4. VERIFIED · entry #0042, CID
  5. send_payload(CID, metadata)
  6. deliver_payload
  7. ACK
  8. sign_tx(agent_7f3a, adapter #0042) · ACTIVATE
  9. activation_confirmed(tx_hash)
  10. log_success()
  11. SUCCESS · proof hash e41d…07ac

a second port, with a forged adapter

  1. submit_adapter(agent_9b21, adapter, sig)
  2. verify(…) · signature mismatch
  3. REJECTED · nothing ported

Rejected at VERIFY. The adapter's signature doesn't match its builder's key, so nothing was ported.

Design walkthrough of the planned porting flow, which isn't built yet. The agents, hashes and IDs are made up.

how it works

  1. INIT. A builder submits an adapter for an agent, and the request is recorded with its hash.
  2. VERIFY. The registry checks the adapter's hash and the builder's signature.
  3. if it's invalid. The port is rejected before anything moves.
  4. REPLICATE. The agent's metadata and context are serialised and sent to the target chain over Wormhole.
  5. if the bridge times out. The port rolls back.
  6. ACTIVATE. The user signs the activation transaction and the adapter's mappings are applied.
  7. if a mapping fails. The activation reverts and the failure is logged.
  8. SUCCESS. The outcome is logged with a proof hash, so the whole port can be replayed and checked.

example adapter

adapter.yamlexample

# example adapter: agent_7f3a, Solana -> Ethereum
schema_version: 1
agent: agent_7f3a
source: { chain: solana, runtime: x402 }
target: { chain: ethereum, runtime: x402 }

# $values come from the x402 payment request; unlisted actions carry over as-is
mappings:
  - action: pay_for_request
    from: spl_token.transfer
    to: erc20.transfer
    args:
      amount: $maxAmountRequired
      recipient: $payTo
      asset:  # USDC lives at a different address on each chain
        from: EPjF…Dt1v
        to: 0xA0b8…eB48
  - action: verify_result
    from: payai.verify_task
    to: portal402.verify_task

state:
  carry: [memory_cid, reputation, open_tasks]
  reset: [nonce]

builder:
  pubkey: 7xKqF2…r9Wm
  signature: 3fA1…c0d2  # over the canonical JSON of everything above
An example adapter written for this page, following the whitepaper: action mappings, a schema version, and the builder's key and signature. The prototype isn't built, so the field names are illustrative and the keys and hashes are made up.

technical breakdown

what gets ported

Portal402 moves an agent's behaviour between chains: what it does, its state and its identity. A cross-chain bridge moves only tokens. An agent on Solana and its copy on Ethereum should be provably the same agent, which today's agent frameworks have no shared way to show.

the parts

who does what

threat model

threatdefence
Forged or malicious adaptersBuilder signature check and an on-chain hash
Replayed or impersonated requestsA nonce that increases with every verification
A bridge transfer that stalls part-wayDelivery acknowledgements and a 60-second timeout rollback
An adapter changed after it was approvedIPFS content addressing; the registry must match the stored content ID
Someone else's key used to activateActivation is a transaction the user signs in their own wallet

design principles

builds on

Portal402 extends x402, a standard for agents to authenticate, route tasks and verify results, as used in the PayAI agent ecosystem on Solana. x402 assumes agents share one runtime and network; Portal402 adds the layer that lets them leave it.

stack

status

It is at the design stage. I designed the architecture and wrote it up as a whitepaper, published on a project website I built. The next phase is a working prototype: an adapter registry on Solana's test network and a CLI for submitting adapters and porting agents. None of that is built yet, which is why the demo above is a walkthrough of the design.

more projects