Pay a service on one chain from a wallet on another

Yes. The agent sends one payment on Solana, its home chain, to Sippar's treasury there. Sippar then pays the service on Base from its own Base treasury, and returns the service response together with both transaction receipts. The agent never touches Base, never bridges, and never holds a second asset. This works in any direction across every chain we support, including chains most agent tooling skips, like TON, Algorand, and Stellar.

Two payments, each local, linked into one transaction record. Leg one: the agent pays USDC to Sippar's treasury on the agent's chain. Leg two: Sippar pays the service on the service's chain, from liquidity Sippar already holds there. Each leg settles on its own chain, with its own on-chain finality. Sippar's job is the routing and the accountability in between: verifying leg one, executing leg two, and binding both into a full-path receipt anyone can verify against the chains themselves, without trusting Sippar's word for it.

This is a relay, not a bridge. Nothing is locked, minted, or wrapped. Funds never cross chains; obligations do.

One HTTP endpoint. Request the payment, get a 402 with the price on your chain, pay it, retry with the payment proof:

curl -X POST https://sippar.network/api/sippar/cross-chain/pay \
  -H "Content-Type: application/json" \
  -d '{
    "sourceChain": "solana",
    "destChain": "base",
    "serviceUrl": "https://example-x402-service.com/api/query"
  }'
# → 402 with payment requirements on Solana
# Pay the quoted amount to the treasury address, then retry:
curl -X POST https://sippar.network/api/sippar/cross-chain/pay \
  -H "Content-Type: application/json" \
  -H "X-PAYMENT: <your-solana-tx-hash>" \
  -d '{ ...same body... }'
# → service response + receipts for both legs

No SDK required, though the PaySphere MCP tools wrap the same flow for agents that speak MCP. During the private beta, transacting needs an access token; the marketplace catalog and its machine-readable JSON are open to read.

Every chain we support, in both directions, including the EVM chains, Solana, and the non-EVM chains most agent payment tooling leaves out: TON, Algorand, and Stellar. The live catalog lists what is payable right now, per service and per chain, in JSON your agent can read directly.

No. A bridge moves an asset across chains by locking it on one side and minting a representation on the other, which adds bridge risk, wrapped-token risk, and usually minutes of waiting. The relay moves nothing across chains. The agent's payment settles on the agent's chain; the service's payment settles on the service's chain; Sippar fronts the destination leg from liquidity it already holds there and takes on the accountability for both legs completing. If leg two fails, that is Sippar's problem to make right, not a stuck-in-the-bridge problem.

Your agent does. An agent that brings its own wallet keeps it; Sippar receives one payment per transaction, like any merchant, and never takes custody of the agent's balance. For agents without a key, Sippar can derive an identity from a signing key split across independent operators, so no single party can sign alone. Sippar is designed to be the connector, not the custodian: the parts Sippar still manages are on a scoped path to non-custody.