Access Gate reference

The on-chain access_gate contract, its gateway, and the client SDK. The contract reference is imported from the Move package (below); the TypeScript SDK reference is auto-generated.

Deployed identifiers (testnet)

Thing	ID
access_gate package	0xd7ddaa94b74330979b2b618fc81206d160a264f1c9ca148a77fa2144301388c9
PlatformConfig object	0x3f81489df58233d96798f34ad44de325e1b4df7e4d615affe72ca181969ee7b5

Mainnet identifiers are pending.

On-chain contract

The Move contract's objects, functions, events and abort codes are documented with the Move package itself and imported into these sites at build time, so they always match the deployed source:

• On-chain overview — objects, pass flavours, money flow and trust boundaries.
• Using passes and gates — what you can do, who can do it, and what to watch for.
• On-chain API reference (developer site) — every function, event and abort code.

Event pruning

Public Sui full nodes keep only a short window of events (about 5½ days on testnet when measured on 2026-10-08; the operator sets it and it can change). Systems that need a reliable gate list should read AdminCap ownership → Gate rather than replaying GateCreatedEvent (this is what the Treasury console does).

Gateway (access-gate-gateway)

Any HTTP service can be placed behind a gate using the access-gate-gateway reverse proxy. It verifies a signed proof and on-chain pass ownership, failing closed on any ambiguity.

• Challenge: GET /v1/challenge returns { "nonce": "…", "expiresAt": … }.

• Personal message signed by the wallet (v2, audience-bound): ASCII, one key:value line each:

  access-gate-gateway:access:v3
  origin:<canonical gateway origin>
  gate:<0x + 64 lower-case hex gate id>
  network:<localnet|devnet|testnet|mainnet>
  nonce:<nonce>
  consume:<base58 transaction digest>      (single-use gateways only)

  The gateway rebuilds the message from its own origin, gate and network, so a signature is useless at any other gateway, gate or network (and, for single-use passes, for any other consumption).

• Proof token (Authorization: Bearer … or X-Access-Proof): base64 of

{ "address": "0x…", "nonce": "…", "signature": "…", "consumeDigest": "…" }

consumeDigest is present only for single-use passes. The token is strict canonical padded base64 of that JSON; a gateway refuses any other encoding.

The gateway consumes the nonce immediately (single-use replay protection) and, for single-use passes, verifies the on-chain consumption by digest. Two wire-identical implementations exist (Cloudflare Workers and Rust). Running one is covered in the developer guide Deploy the access-gate gateway; the exact message construction is in the generated personalMessage reference.

SDK API

Two SDKs, each with a generated reference:

• Access-gate client API — @meddleware/access-gate-client: transaction builders (create_gate, purchase, consume, airdrop, admin setters), ownership and gate reads, typed events, abort messages, and the deployed ids per network.
• Gateway wire-protocol API — @meddleware/access-gate-gateway-client: the challenge and access-proof helpers a gateway verifies.

Deploying the gateway or integrating the SDK?

See the Access Gate integration guide on the developer site — SDK setup, purchase/verify flow, challenge/proof protocol, and Rust/Worker gateway deployment.