Start

Sup Adaptor Marketplace

An open, permissionless on-chain registry of Sui wallet adaptors.

#What problem it solves

A Sup Wallet is a smart-contract vault. To do anything useful with a protocol — swap on a DEX, lend on a money market, stake, pay a subscription — the vault needs code that knows how to talk to that protocol while staying inside the owner's typed, revocable allowances. That code is an adaptor: a small Move package that wraps an external protocol behind the SupWallet::intent flow.

Historically each adaptor was hand-integrated by the core team. The marketplace removes that bottleneck: anyone can publish an adaptor, and any app or AI agent can discover, authorize, run, and even publish one — without asking permission, and without anyone holding your keys.

#How it fits together

   Publisher                Sup host (this app)                 Consumer (dApp / agent)
   ─────────                ───────────────────                 ───────────────────────
   deploy a Move    ──▶     /api/adaptors/draft   ◀── introspect + MINE past calls
   adaptor package          (build manifest)          → unsigned register()
        │                        │                            │
        │ sign register()        │  on-chain anchor:          │  GET /api/adaptors
        ▼                        ▼  {publisher, pkg,          ▼  (discover) → authorize
   AdaptorRegistry  ◀────────────  witness, uri, hash}        → run op  (user signs)
   (Sui Move)        events: Registered/Updated/Unlisted/Attested
        │
        └─ manifest body on Walrus (hash-verified)

There are two halves, deliberately split:

  • On-chain (the anchor). The registry contract stores the minimum per listing — the publisher's address, the deployed package id, the adaptor's witness service-type, and a pointer to the manifest (manifest_uri) plus its content hash (manifest_hash). That's it. Discovery happens by indexing the contract's events, so any indexer or frontend sees the same registry.
  • Off-chain (the body). The rich manifest — display name, summary, category, the operations and their call specs, declared fees — lives on Walrus (Sui's blob storage). It is verified against the on-chain manifest_hash, so a host can't serve you a tampered manifest. Reviews are off-chain; usage is derived from on-chain events.

This mirrors the ERC-8004 "trustless agents" pattern: a tiny on-chain identity/anchor, rich content off-chain, integrity guaranteed by a hash.

#The lifecycle of a listing

  1. Publish — a publisher deploys an adaptor package, then signs register() with the package id, witness type, manifest uri + hash. (Helpers draft the manifest for you.)
  2. Discover — anyone reads GET /api/adaptors (or indexes the events).
  3. Authorize — a wallet owner grants the adaptor a coin via grant_service_coin. This is the consent step and the security boundary.
  4. Use — the owner (or their agent, within allowance) calls an adaptor op. Funds move only through intent, bounded by the allowance.
  5. Review — anyone can attest a 1–5 score; reviews from real users are weighted higher.

Building a protocol? Listing is permissionless and first-come — you claim the service-type, start accruing on-chain reputation, and can declare an integrator fee. The marketplace is early, so listing now is cheap and compounds: Why publish?

#Why "open" matters here

The real interface is the on-chain register() contract plus the manifest standard. The HTTP API, SDK, CLI, MCP server, and this docs site are all convenience layers on top. If this host disappears, the registry keeps working: anyone can call the contract directly, and any other frontend can index the same events. It's a protocol, not a platform.

#Where to go next

Concepts →