Build with Membrane.

Target install — not published yet

Membrane will ship as a library plus a CLI. You will install the SDK in TypeScript or Python; the kwi-verify CLI comes with it. Verification is designed to run offline against public chain state — there is no Membrane service to sign up for.

# Target API — packages not on npm / PyPI yet
# TypeScript / Node
$ npm install @kwi/membrane

# Python
$ pip install kwi-membrane

# planned offline verifier — no trust in Membrane
$ kwi-verify bundle.json
# (illustrative — not a live run)

Wrap a tool call, emit an attestation

The SDK's job (planned) is to sit in the path of an action your agent already takes, capture the pieces, and emit a Membrane attestation. One import, sane defaults. Sample below is the target surface.

import { Membrane } from "@kwi/membrane";

const m = new Membrane({
  chain: "avalanche-fuji",        // anchor target
  issuer: "erc-8004:eip155:1:0x…/4217",  // agent identity
  policy: "./spending_policy.yaml",
});

// wrap the action — intent in, attestation out
const att = await m.attest({
  intent:   intentMandate,        // AP2 or Membrane-native
  call:     mcpToolCall,          // the tool-call envelope
  receipt:  x402Receipt,          // optional payment receipt
  response: result,               // hashed, not stored
  memory:   memoryEntry,          // commitment + provenance
});

await m.anchor(att);   // batched → Merkle root → on-chain

The Python SDK is planned to mirror this surface exactly. Both will expose the same attestation shape, the same verification routine, and the same chain config — so a bundle produced by one verifies with the other.

kwi-verify — offline, independent (planned)

The verifier is designed to be chain-config-driven. It will read the bundle's CAIP-2 chain id, resolve the right RPC and anchor contract, confirm the root is on-chain and past finality, check the Merkle inclusion proof, and verify issuer signatures. Nothing in the path trusts Membrane.

$ kwi-verify bundle.json
# target checks — not a live Fuji run
intent mandate signature
spending policy — not violated
payment receipt — matches policy
response hash — matches output
memory entry — commitment matches
anchor — home chain · past finality
# bundle verified when packages and sample anchors ship

Chains will be declared in membrane-chains.yaml, shipped with the SDK and overridable. Each entry carries the CAIP-2 id, the anchor address, RPC endpoints (with mandatory fallbacks), and a per-chain finality_blocks value — so a root is never trusted before its chain has finalised it.

Attestation as a one-server add

The Membrane MCP server is planned to expose attestation as MCP tools. Any MCP-aware agent — a coding agent, a desktop assistant, an autonomous worker — gets Membrane attestation by adding one server to its config. This is a major distribution lever in the roadmap, because MCP is the de-facto tool-call plumbing.

Receipt-format pluralist

Membrane does not pick a winner in the payments-rail war. Every rail's receipt is an equivalent input into the same attestation. Whoever wins, Membrane is still useful.

On-chain anchoring

Two contracts, ~250 lines of Solidity, zero external dependencies — by design. Built toward Foundry. Full design rationale is in the architecture page.

# Target: Foundry suite (unpublished until repo is public)
$ forge install foundry-rs/forge-std
$ forge build
# solc 0.8.24 / paris target
$ forge test
# MembraneAnchorTest + MembraneRootRegistryTest (unit + fuzz)
# Pass counts published with the public repo and CI

What a proof bundle looks like

A bundle is a flat, content-addressed object. Sample bundles will ship in the public repo under samples/ so anyone can verify offline with kwi-verify — the samples will be the documentation.

{
  "intent_anchor":  "0x9f3c…a17",   // ap2:intent-mandate
  "policy_id":      "0x71b2…0e4",
  "issuer":         "eip155:1:0x…/4217",  // erc-8004
  "parent_call":    "mcp:call:7a1f…",
  "payment_receipt":"x402:0x4e1d…b02",
  "response_hash":  "0xc7a9…3f1",
  "memory_entry":   "0xe520…9ac",
  "anchor": {
    "caip2":  "eip155:43113",         // avalanche-fuji
    "root":   "0x8d44…c10",
    "block":  41208917
  },
  "commitment":     "0x2fae…b88"    // the bundle's own hash
}

Verifiable USDC spend, end to end

The reference design for the wedge: an agent on Avalanche Fuji buys an API key with USDC through an x402 endpoint, and Membrane emits one composite proof. Not a public runnable artifact yet — strangers cannot verify a sample bundle today.

• Intent. "Buy a 30-day API key from Provider X if it's under $20" — signed as an intent mandate.
• Call & pay. The agent hits the x402 endpoint, gets a payment-required challenge, signs and broadcasts a USDC payment within the active policy.
• Receipt & response. An x402 receipt and the API key come back; the response is content-hashed.
• Memory. "Purchased API key for Provider X, expires <date>" is written with full provenance.
• Bundle & anchor. Intent, policy, receipt, response hash, memory entry — bound into one attestation and anchored to Fuji.
• Verify (target). kwi-verify bundle.json → six checks, offline.

Built to be public

Membrane is developed by Kwizerana Finance toward an Apache-2.0 public release. The contracts, the SDK, the verifier, and these docs will live in one repository when published.

• Repository (when published). github.com/kwizeranafinance-kind/KWI_MEMBRANE — contracts, docs, and site.
• Near-term workstreams. The wedge-demo proof bundle, the MCP server scaffold, and the AP2-mandate adapter.
• Standards. Membrane aims to contribute openly to the x402, AP2, A2A, ERC-8004, and MCP communities rather than compete with them.