Protocol reference

The marketplace is, at bottom, a small Move contract plus a manifest standard. Everything else is convenience.

#On-chain registry (the canonical API)

registry::register(registry: &mut Registry,
                   package_id: address, service_type: String,
                   manifest_uri: String, manifest_hash: vector<u8>, clock: &Clock)

registry::update(registry, service_type, package_id, manifest_uri, manifest_hash, clock)
                                                                       // publisher only
registry::unlist(registry, service_type, clock)                        // publisher only
registry::attest(registry, service_type, score: u8 /* 1..5 */, comment_uri: String, clock)

• register — permissionless. Records the anchor for a service_type (which is the key). Re-registering the same service-type fails; use update.
• update / unlist — gated to the original publisher (recorded at register time).
• attest — anyone may leave a 1..5 score with an optional off-chain comment uri.

#Events (the discovery surface)

Registered, Updated, Unlisted, Attested. Each carries the service_type, the publisher / attester, and (for listings) package_id, manifest_uri, manifest_hash, version, timestamp_ms. Index these to build a catalog independently of any host.

#On-chain state is anchor-only

The contract stores only: { publisher, package_id, manifest_uri, manifest_hash, version, updated_at_ms } per service-type. No manifest body, no reviews, no usage — those are off-chain (Walrus) or derived (events). This keeps the contract tiny and the data portable.

#Security model

• Anchor-only + hash-pinned. The manifest body lives off-chain but is content-addressed by manifest_hash; a host can't serve a tampered manifest without manifestVerified going false.
• Witness can't be spoofed. service_type is namespaced by the publisher's package id via type_name::with_defining_ids, so no one can register another publisher's witness type and have it resolve to their package. Service-types are globally unique by construction.
• Allowance-bounded use. Using a listed adaptor only ever moves funds the owner granted via grant_service_coin, capped by the per-service and per-coin allowances. A malicious or buggy listing is sandboxed to exactly what you authorized, and you can revoke at any time.
• Reputation from real usage. attest reviews are cross-referenced against on-chain SupWallet::intent events for the same service-type: a reviewer who actually used the adaptor is marked verified, and verified reviews are surfaced over anonymous ones. Anyone can attest; sybils don't get the verified weight.
• Fee transparency. feeBps is disclosed in the manifest, not silently taken. The minOut slippage floor the user signs bounds what an op can actually extract.

#What to check before authorizing a third-party adaptor

• Is the listing manifestVerified? (the off-chain body matches the on-chain hash)
• Does it have real usage and verified reviews?
• Is the package immutable (its UpgradeCap frozen) or upgradeable? An upgrade can change behavior after you've authorized it.
• Anything odd — a high declared feeBps, an unexpected op set, an unfamiliar publisher?

Using it is still bounded by the per-service allowance you grant — but for third-party code, review and a tight allowance are your friends.

#Deployment ids

The registry package + shared object ids per network are returned by GET /api/adaptors/schema. The manifest body is stored on Walrus; resolve a walrus://<blobId> through the configured aggregator.