How do I mock the WalletConnect (Relay Protocol v2) API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:walletconnect-style), and run stunt up. You get a local, stateful stand-in for WalletConnect (Relay Protocol v2) 2.0 — 7 routes over rest — with no remote account, no network, and no bills.

Is the WalletConnect (Relay Protocol v2) mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of WalletConnect (Relay Protocol v2) (routes, status codes, pagination, webhooks), never real records.

← all adapters

walletconnect-style

simulates WalletConnect (Relay Protocol v2) 2.0

restadapter v0.1.07 routes

verification

VMVM tier — no SDK suite yet· surface 7 · not implemented 3 · differs 5

use it

# add to stunt.yaml
services:
  walletconnect:
    adapter: embedded:walletconnect-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the WalletConnect (Relay Protocol v2) API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of WalletConnect (Relay Protocol v2). It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real WalletConnect (Relay Protocol v2) 2.0 surface — the data is fake, the behavior is real.

backing stores

pairingssessions

api surface (7)

generated from the adapter manifest — exactly what boots, nothing more

7 routes

POST/v1/pairings

POST/v1/sessions

GET/v1/sessions

POST/v1/sessions/{topic}/approve

POST/v1/sessions/{topic}/request

POST/v1/sessions/{topic}/extend

DELETE/v1/sessions/{topic}

VM-verified behaviors (11)

✓every route demands a projectId — body, query, or bearer all pass
✓a wc: URI pairing round-trips its topic, relay protocol, and symKey
✓an auto pairing mints a fresh topic and a 64-hex symKey
✓proposing requires pairingTopic — and accepts one never paired
✓approve acknowledges the session and derives eip155 namespaces
✓the session list is a bare array capped by limit
✓the approval gate is missing: an unacknowledged session still answers
✓wallet requests answer in a JSON-RPC 2.0 envelope with monotonic ids
✓signing and transaction methods return synthetic 0x-hex hashes
✓extend echoes the fixed session TTL without persisting anything
✓disconnect retires the topic and every later call 404s

Not implemented (3)

No WebSocket relay; the real IRN protocol is WSS JSON-RPC pub/sub, not HTTP REST
No session update, ping, or event emission (chainChanged/accountsChanged)
No pairing list, expire, or ping operations

Differs from the real API (5)

Pairing, session approve, and JSON-RPC requests are auto-approved (no wallet device)
personal_sign and eth_sendTransaction return synthetic hashes; nothing is signed
Any non-empty projectId passes the gate — no validation against a project registry
Expiry fields are TTL constants, not absolute unix timestamps; extend persists nothing
Unacknowledged sessions serve JSON-RPC requests immediately (no approval gate)

full scorecard →

want more of the WalletConnect (Relay Protocol v2) surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.