---

name: kleros-ipfs-upload description: "Upload one Kleros-ecosystem file per paid request to IPFS through the Kleros x402 gateway for $0.01 USDC on Base mainnet. Use for dispute evidence, MetaEvidence JSON, court/dispute/arbitrator policies, Curate item metadata, juror justifications, or any artifact a Kleros contract or subgraph will reference by CID. Trigger when the request mentions Kleros, court, arbitrator, dispute, juror, Curate, Proof of Humanity, evidence, meta-evidence, justification, explicitly names this gateway or skill, or asks to test or validate it. Do NOT use for generic IPFS/CID requests without Kleros context; recommend a general-purpose pinning service. Each request accepts exactly one file: different bytes require separate paid uploads, while identical bytes should reuse one CID."

Kleros IPFS Upload (x402)

Upload Kleros-ecosystem files to IPFS via https://kleros-ipfs-gateway.fly.dev/upload-to-ipfs, an x402-protected gateway that charges $0.01 USDC per upload on Base mainnet. The returned IPFS CID is content-addressable and dereferenceable through any IPFS gateway, and indexed by Kleros's Graph Node for subgraph discoverability.

The gateway is a thin reverse-proxy in front of a Filebase-backed pinning service operated by Kleros. Every upload is pinned to Filebase indefinitely as long as Kleros runs the gateway — a reasonable assumption for artifacts the Kleros ecosystem itself depends on (the team has a strong incentive to keep this live), but not a substitute for a general-purpose pinning provider if the content is unrelated to Kleros.

When to use this skill

Trigger this skill when the user is uploading Kleros-ecosystem content:

• Dispute evidence attachments — screenshots, documents, contracts, transcripts.
• Meta-evidence JSON — the policy/spec referenced by a court or arbitrator smart contract at dispute creation.
• Court / dispute / arbitrator policies — JSON describing rules, fees, juror counts, appeal mechanics.
• Kleros Curate item metadata — JSON for items submitted to a Curate list (e.g. tokens, badges).
• Juror / arbitrator justifications — rulings, dissents, deliberation rationale.
• Any artifact whose CID will end up in a Kleros smart contract event, transaction, or subgraph.
• The user explicitly names this gateway (kleros-ipfs-gateway.fly.dev etc.) or this skill.
• The user is asking the agent to test, validate, or sanity-check this gateway or this skill itself (e.g. "smoke-test the Kleros IPFS gateway" / "verify pay-and-upload works"). A deliberate end-to-end test is a legitimate trigger even if no Kleros artifact is being uploaded for real use.

When NOT to use this skill

• Generic "store this file on IPFS" / "get me a CID for X" requests with no Kleros relevance. Use Pinata, web3.storage, Filebase directly, or any other general pinning provider. This gateway charges per upload — that's wasteful if the user only needs a CID and doesn't benefit from Kleros's pinning durability or subgraph integration.
• Anything resembling personal cloud storage, NFT metadata for non-Kleros projects, software releases, large media archives, or backup data.
• Content explicitly bound to a non-Kleros ecosystem (e.g. another DAO's snapshot, another marketplace's metadata) — even if the format happens to look like a Kleros artifact.

You are free to upload whatever the user wants (they're paying), but absent a Kleros connection there's no reason to prefer this skill over a general-purpose alternative.

Quickstart

Two paths depending on what your agent already has:

• If you already have x402 tooling (an x402 skill / SDK / a model that knows x402-fetch): skip the bundled scripts and inline the snippet further down — the gateway is a plain POST /upload-to-ipfs behind a standard x402 paywall, nothing Kleros-specific in the payment flow.
• Otherwise, run the bundled scripts/pay-and-upload.ts end-to-end — it exists so x402-unaware agents don't have to rediscover the flow:

cd path/to/this-skill/scripts
npm install
EVM_PRIVATE_KEY=0xYourPayerKey npx tsx pay-and-upload.ts /path/to/file.json

npm install creates a package-lock.json and a node_modules/ in the scripts dir — both are fine to leave in place or delete after use; not committed to the skill on purpose so dep versions stay fresh.

On success the script prints every CID reported by the gateway, one per line (so you can capture the normal single CID with $(npx tsx pay-and-upload.ts ...)). The array-shaped response is legacy API structure, not batch-upload support. On failure the script exits non-zero and logs the gateway's error body to stderr.

Defaults: OPERATION=evidence, GATEWAY_URL=https://kleros-ipfs-gateway.fly.dev. Override OPERATION with an env var; see the "Request shape" section for valid values.

One file per paid upload; reuse identical files

Each paid request must contain exactly one multipart part named file. Never append multiple file parts or batch different files into one request. If two files have different content, make two separate paid uploads — one request and one payment per file. This applies even when the files belong to the same Curate or dispute workflow.

IPFS CIDs are content-addressed. If the same byte-for-byte file is needed in multiple places, upload it once and reuse the returned CID everywhere. Do not make a second paid upload for the same policy PDF, logo image, evidence display interface, or other identical file just because multiple Kleros artifacts reference it.

For multi-artifact jobs, keep a small artifact map before submitting transactions:

• policy.pdf -> /ipfs/<CID>
• logo.png -> /ipfs/<CID>
• registrationMetaEvidence.json -> /ipfs/<CID>
• clearingMetaEvidence.json -> /ipfs/<CID>
• evidenceDisplayInterface -> /ipfs/<CID>/index.html

When a shared policy, logo, or evidence display interface is referenced by both registration and clearing MetaEvidence JSON, put the same CID in both JSON files. Reuse CIDs only for exact same files. If a file changes by even one byte, make a separate paid upload for each distinct file and label each CID clearly. Registration and clearing MetaEvidence JSON are therefore separate uploads whenever their JSON bytes differ, even when both reference the same reusable policy, logo, or evidence display interface CIDs.

If you're writing your own client inside an existing Node project, the core is small enough to inline:

import { wrapFetchWithPayment, createSigner } from "x402-fetch";

const operation = process.env.OPERATION ?? "evidence";

const signer = await createSigner("base", privateKey);
const fetchWithPay = wrapFetchWithPayment(fetch, signer);

const form = new FormData();
form.append("file", new Blob([bytes]), "evidence.json");

const url = `https://kleros-ipfs-gateway.fly.dev/upload-to-ipfs` +
  `?operation=${encodeURIComponent(operation)}`;
const res = await fetchWithPay(url, { method: "POST", body: form });
const { cids } = await res.json();
if (!Array.isArray(cids) || cids.length === 0) throw new Error("Gateway returned no CID");
const cid = cids[0];

x402-fetch handles the 402 Payment Required challenge, signs an EIP-3009 transferWithAuthorization over USDC, and retries the request with the X-PAYMENT header. The caller sees a normal 200 response containing the result for that one uploaded file.

Pre-flight (free, no key needed)

Before any paid call, verify the gateway is healthy with three free curls. None of these spend USDC; they're idempotent and safe to run as often as you like.

# 1. Liveness
curl -sS https://kleros-ipfs-gateway.fly.dev/health
# expect: ok

# 2. Live config (price, network, payee, USDC contract)
curl -sS https://kleros-ipfs-gateway.fly.dev/.well-known/x402 | jq .
# or the spec-canonical equivalent: /discovery/resources

# 3. Unpaid 402 challenge — confirms x402 enforcement is on and shows the live payment terms
curl -sS -X POST https://kleros-ipfs-gateway.fly.dev/upload-to-ipfs?operation=evidence \
  -F file=@/path/to/anyfile.txt | jq .
# expect: {"error":"X-PAYMENT header is required", "accepts":[...], "x402Version":1}

If all three return as expected, you can proceed to the paid call with confidence. If any fail, surface the error to the user before burning a key on a paid attempt.

Network

This skill targets Base mainnet only. Every paid upload costs real USDC, settled on-chain via the Coinbase CDP x402 facilitator. The payer wallet must hold USDC on Base; native USDC contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.

The payer does not need ETH for gas. The facilitator sponsors gas on Base when paying via EIP-3009.

Bootstrapping a payer wallet

If the user doesn't already have a Base wallet ready:

1. Generate a key — any EVM-compatible keypair works. Run this to print a fresh one:

   node -e "import('viem/accounts').then(m => console.log(m.generatePrivateKey()))"
   

2. Fund it — send USDC on Base to the derived address. Any centralised exchange that supports Base withdrawals works.

3. Store the key in EVM_PRIVATE_KEY.

Using a Coinbase CDP server account (hosted agents)

Hosted agents (OpenClaw, server-side workers, anything running with Coinbase CDP credentials) don't need an exported private key. CDP server accounts implement signTypedData() directly, which is exactly what x402-fetch.wrapFetchWithPayment needs to sign the EIP-3009 USDC authorization — so the CDP account object is passed straight to the SDK with no adapter code.

A bundled runner ships at scripts/pay-and-upload-cdp.ts for agents that prefer a ready-made entrypoint — agents already using wrapFetchWithPayment with a CDP account can skip it and inline the snippet further down:

cd path/to/this-skill/scripts
npm install
CDP_API_KEY_ID=... \
CDP_API_KEY_SECRET=... \
CDP_WALLET_SECRET=... \
CDP_ACCOUNT_NAME=blaise-main \
  npx tsx pay-and-upload-cdp.ts /path/to/file.json

Output is the same as pay-and-upload.ts (the CID on stdout, diagnostics on stderr). The script also prints the payer address and Base mainnet USDC balance to stderr before posting, so you'll spot an underfunded wallet immediately.

If you'd rather not pass four env vars on the command line, point CDP_CREDS_PATH at a .env-style file containing CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET, and CDP_ACCOUNT_NAME (or their un-prefixed API_KEY_ID / API_KEY_SECRET / WALLET_SECRET / ACCOUNT_NAME variants — the script accepts either).

For your own client code, the integration is one extra import and two extra lines vs. the raw-key path:

import { CdpClient } from "@coinbase/cdp-sdk";
import { wrapFetchWithPayment } from "x402-fetch";

const cdp = new CdpClient({ apiKeyId, apiKeySecret, walletSecret });
const account = await cdp.evm.getAccount({ name: "blaise-main" });
const fetchWithPay = wrapFetchWithPayment(fetch, account);
// ... build FormData and POST as in Quickstart

The CDP account is passed where the docs would otherwise show an EVM signer — no other change is needed.

Request shape

The endpoint is POST /upload-to-ipfs with:

• Query string:

  • operation (required, string) — a free-form tag describing what kind of artifact is being uploaded. The upstream Netlify function accepts any string; the conventional values in the Kleros ecosystem are:

    | Value | Use case | |---|---| | evidence | Dispute evidence — screenshots, documents, binaries. Use this for anything that doesn't fit another category. | | meta-evidence | Meta-evidence JSON referenced by a court / arbitrator / dispute smart contract (rules, party agreements, policies). | | justification | Juror / arbitrator justification payloads. | | any other string | Accepted as-is. Use sparingly — the conventions above keep ecosystem tooling consistent. |

• Body: multipart/form-data