[ swag protocol ]

swag protocol


 ▒▒▓▓▓▓▓▓▓▓▓▓▒▒▓▓▓   ▒▒▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓ ▒▒▓▓▓▓▓▓▓▓▓▓▓
▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▓▓▓   ▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▓▓▓▒▒▓▓▓▒▒▒▒▒▓▓▓
▒▒▓▓▓        ▒▒▓▓▓▒▓▓▒▒▓▓▓         ▓▓▓▓▒▒▓▓▓   ▒▒▓▓▓
▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒▓▓▓▒▓▓▒▒▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓▓
 ▒▒▒▒▒▒▒▒▒▓▓▓▒▒▓▓▓▒▓▓▒▒▓▓▓▒▒▓▓▓▒▒▒▒▒▓▓▓ ▒▒▒▒▒▒▒▒▒▓▓▓
▒▓▓▓▓▓▓▓▒▒▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒▓▓▓▓▓▓▒▒▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓
▒▒▓▓▓▓▓▓▓▓▓▒▒ ▒▒▓▓▓▓▒▓▓▓▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒▓▓▓▓▓▓▓▓▓▒▒
  ▒▒▒▒▒▒▒▒▒     ▒▒▒  ▒▒▒    ▒▒▒▒▒▒▒▒▒▒▒  ▒▒▒▒▒▒▒▒▒  
                                                    

SELL WITHOUT AUTOCRATIC GOVERNANCE

I want to preface this by saying that I’m not looking to make money, but to make an open protocol with no strings attached because I believe in free markets.

This is an early sketch. I’m bouncing ideas around before I go deeper, so feedback, “someone is already working on this” and “you’re wrong about X” are all welcome.

The problem

The world would benefit if we could sell shippable goods for ICP/ckUSDC/ckBTC without a centralized marketplace, without a protocol-mandated arbitrator, and without a privileged operator anywhere in the settlement path.

Bisq (the decentralized BTC<->Fiat exchange) proved this is possible with their “cash-in-mail” and “USPS money order” options. ICP Geeks proved that a decentralized marketplace was possible on the IC with Internet Identities. I think the IC has the potential to make it possible for physical goods as well. Right now, vendors typically pay a 10~15% fee for selling on platforms like Amazon and eBay, and there is a good reason for this.

The problem with the problem

Physical goods are more challeninging to settle than a simple token swap:

  • The seller’s asset is unrecoverable once shipped. You can’t atomically un-ship a box.
  • The buyer’s asset is fully recoverable via escrow. Asymmetric risk.
  • Evidence about physical events is lossy. “Shipped” ≠ “delivered” ≠ “delivered in the described condition.” No cryptography proves what was in the box.

Design consequence: Arbitration is necesarry, but should as much as possible be a last resort, not a first resort. Bisq routed every dispute to a human and it strained them (see Proposal #220, the Refund Agent collapse). The goal here is that the vast majority of trades never touch arbitration — the protocol should raise the cost of lying, lower the friction of honesty, and makes cooperation the dominant strategy.

Core stance

A few opinions that shape the rest of this:

  • The protocol is the interface, not the implementation. Arbitration, reputation, punishments, marketplaces, gating, commission splits — all extension points with well-defined shapes. Anyone can ship their own implementation.
  • Every extension-point choice is negotiable. A listing declares the seller’s preferred arbitrator, punishment module, terms, commission split, gate, etc, but the buyer can counteroffer on any of them. Nothing in the protocol locks a trade to the seller’s defaults — the parties agree on the full stack before any funds move. This is how the buyer applies pressure back on things like commission rates.
  • Canisters are the seller’s storefront. A seller deploys a canister that broadcasts their listings. Marketplaces are pure indexers — they discover, filter, and vet, but never sit in the settlement path.
  • Funds enter escrow at offer time, held by the canister — not by any human. The buyer approves and the canister pulls into escrow in the same offer call. The seller never has custody. If the seller doesn’t accept, or a counteroffer supersedes it, or the offer expires, funds refund automatically. This is a departure from Bisq-style “allowance until settlement” — that model was built for atomic token swaps that finish in seconds, and doesn’t survive our offer → counteroffer → arbitrator-accept → accept lifecycle, which can span days.
  • Assume every human role will quit. Arbitrators, moderators, referrers — all replaceable, all bond-backed, none in the critical path by default. (Direct lesson from Bisq’s Refund Agent collapse.)
  • Reproducible builds. Every storefront canister publishes a wasm hash and a source pointer. Buyers can rebuild and verify. Non-reproducible storefronts get shunned by marketplaces.
  • Blackholed at deploy. Storefronts have no controllers, ever. Bugs are fixed by migrating to a new canister, not upgrading a live one. This removes the rug-pull vector entirely.

The shape

                      ┌────────────────────┐
                      │  Seller principal  │
                      └────────┬───────────┘
                               │ deploys
                               ▼
   ┌────────────────────────────────────────────────┐
   │              Storefront Canister               │
   │   - listings (SKUs, prices, terms)             │
   │   - offers / counteroffers                     │
   │   - trades in-progress                         │
   │   - Arbitration: <extendable>                  │
   │   - Punishments: <extendable>                  │
   │   - Metadata schema: <extendable>              │
   │   - Commission split: <extendable>             │
   └───────────┬────────────────────┬───────────────┘
               │ broadcasts         │ ICRC-2 pull to escrow at offer
               ▼                    ▼
   ┌────────────────────┐   ┌──────────────────┐
   │ Marketplace(s)     │   │  Buyer wallet    │
   │ (indexers, vetters)│   │  (allowance)     │
   └────────────────────┘   └──────────────────┘

One canister per storefront, multiple listings are possible per canister. Each listing picks its own arbitrator, punishment rules, metadata schema, gate, and terms — the storefront holds an array of registered modules and the listing references what it uses.

Extension points

Each of these is a choice the seller declares on the listing and the buyer can counteroffer against. Nothing here is fixed by the protocol — the parties pick the stack together.

  • Arbitration — single principal, multi-sig committee, DAO, AI arbiter, or Bisq-style timelock-to-burn (no arbitrator, mutual failure destroys deposits). Paid opt-in role, not a passive fallback.
  • Punishment — how a verdict maps to a payout. Slashed deposits can go to the counterparty (Bisq-ish), get burned, feed an insurance pool, or split. Seller picks a default, buyer can counter.
  • Metadata schema — versioned and extensible. A usedElectronics/v1 schema is different from apparel/v1. Marketplaces render whatever schemas they understand.
  • Commission split — seller, referrer marketplace, arbitrator, slashing sink. No enforced max. If a marketplace tries to take eBay-scale rake, the buyer counteroffers it down or walks to a cheaper indexer. The market disciplines the split; the protocol doesn’t.
  • Reputationnot protocol-computed. The canister emits a signed TradeEvent stream and marketplaces compute their own scores from whichever events they trust.
  • Gating (visibility) — open (default), NFT-gated, region-gated, allowlist. Enables B2B, invite-only, and local/regional commerce without a protocol change.
  • Terms — natural-language clauses frozen at acceptance (“if UPS marks the package lost, seller refunds”). Standard clauses live in the protocol git repo, hash-verified. Custom clauses are allowed but marketplace-discouraged.

Deployment

No factory canister, no template canister, no swag foundation, no swag token, no swag DAO. Deployment is done from a client-side tool (static HTML page, self-owned Neutron app, open-source wallet etc.) that talks directly to the IC management canister and blackholes the storefront immediately.

Sensitive data

Shipping addresses, private notes, and dispute evidence are all encrypted with IC vetKeys before touching the canister. No plaintext is ever stored on-chain. Encrypted blobs live in the storefront’s stable memory (the IC is the storage layer — no IPFS/Arweave/S3 dependency) and are zeroed after the dispute window closes.

What I’m not trying to build

  • A protocol token, a DAO, or a foundation.
  • A mandated arbitrator or a global reputation database.
  • A central order book or matching engine.
  • Fiat rails. Crypto in, physical out.
  • Storefront upgrades. Migrate to a new canister to fix bugs.

Things I’d genuinely like feedback on

  1. Is one canister per seller (not per listing) the right topology? Per-listing config is committed to the certified-data tree so buyers still get per-listing verification without the operational cost of a canister per SKU. But I might be wrong about the tradeoffs.
  2. Bond sizing. The current rule is bond ≥ total in-flight payment value with no fractional discount. Too tight for real sellers? Too loose against a determined adversary?
  3. Reputation as marketplace policy, not protocol. The protocol only emits a signed event stream. Is this enough of a Schelling point for marketplaces to converge on comparable scores, or does it just fragment reputation across every indexer?
  4. AI arbitration. Reference implementation would use HTTPS outcalls to an LLM with canonical clauses (hash-verified) in the prompt to reduce injection surface. Anyone tried this on ICP with real disputes?
  5. Buyer privacy. Current v1 leaks the buyer’s principal in the TradeEvent#accepted stream, which means any indexer can reconstruct a buyer’s full purchase history. Fixing it (per-trade blinded commitments) breaks cross-trade reputation correlation. I’d rather ship with the leak documented and add opt-in blinding in v2. Push back on this if you disagree.
  6. What’s the smallest first version I could actually ship end-to-end? Right now I’m aiming at: single seller, ICP-only, one named arbitrator principal, on dfx, with counteroffer support in from day one (since it’s the mechanism the whole “negotiable extension points” claim rests on). Then open the extension points one at a time.
  7. What’s missing? What am I not seeing that will bite me later?

This is just an overview, but the full design doc is in a markdown file on my computer if anyone is interested in further details. Just looking for initial feedback at the moment. Also looking to see if anyone is interested in helping shape the protocol.

Yes, I am well aware of your attempted SNS launch.

With all due respect for your SNS launch, when someone takes the time to create a post or start a discussion, I think it’s a bit disrespectful to immediately reply with a promotion for a different project. It can easily overshadow the original post and the effort that went into it.