Overview
Every Garantor trade lives inside its own smart contract — a vault — deployed fresh per trade and destroyed once it's fully settled. The DAO never custodies funds at any point; a vault only ever moves money when its own coded conditions are met.
- V1 — Native Escrow. The original protocol: peer-to-peer escrow paid directly in TON.
- V2 — Jetton Escrow. The same audited lifecycle, extended to stablecoins (USDT first) using TON's token standard.
- V3 — Oracle Marketplace. Turns single trades into listings with inventory, and lets delivery of real-world goods settle automatically from cryptographically signed carrier data instead of requiring both parties to manually confirm. Beta · Pre-audit.
Later generations don't replace earlier ones — V1, V2, and V3 vaults all run side by side, and each new generation reuses the prior one's dispute resolution, timeout backstops, and pull-payment logic rather than rewriting it.
V1 — Native Escrow
Peer-to-peer escrow settled directly in native TON. Two parties agree on a trade, a dedicated vault holds both sides' funds, and the vault releases them only once delivery is confirmed — by the parties themselves, or by the DAO council if they can't agree.
Vault lifecycle
The Escrow Factory deploys a brand-new vault contract for every trade, keyed to that trade alone. Nothing is shared between trades — a bug or dispute in one vault can never touch another.
Create
Buyer and seller agree on terms; the Factory deploys a fresh vault for the trade and waits for deposits.
Deposit
The buyer deposits the trade value; the seller posts a smaller guarantee bond so both sides have skin in the game.
Confirm
The seller submits a hash of the delivery paperwork; the buyer checks it and confirms. Two independent confirmations release the funds — no single party can move them alone.
Withdraw
Funds owed to each party sit as a claimable balance. Each side pulls their own share — the vault never pushes a payout it wasn't asked for.
Close
Once every claimable balance is zero, the vault self-destructs and refunds any unused gas back to whoever created it.
Disputes & timeouts
Either party can raise a dispute at any point before confirmation. From there, a trade resolves one of three ways:
- Mutual settlement. Buyer and seller propose a split to each other directly — no council involved.
- DAO arbitration. A 2-of-3 council multisig reviews the evidence and sets the final split.
- 30-day timeout backstop. If a dispute sits unresolved for 30 days, the vault auto-splits the pool 50/50 — funds are never permanently stuck, even if the council goes quiet.
A settlement commission is taken on successful trades and shared with the Commissionaires DAO, a token-gated group that helps facilitate settlement. The DAO's fee share is hard-capped and can never exceed that ceiling, regardless of governance votes.
Milestone escrow
For larger or staged work, a milestone vault splits the trade into two independently confirmable — and independently disputable — stages, so a disagreement on stage one doesn't have to hold up funds already earned on stage two.
V2 — Jetton Escrow
The same lifecycle, dispute resolution, and timeout guarantees as V1 — extended to stablecoins. USDT is live today; USDe is planned next. Assets move as TON jettons (TON's token standard) instead of native TON, which changes how deposits and payouts are plumbed under the hood.
Wallet discovery
A jetton doesn't move by simple value transfer — it moves wallet-to-wallet, and every holder (including a vault) has its own dedicated jetton wallet contract. Before a V2 vault can safely accept a USDT deposit, it has to ask the USDT token contract for its own wallet address and wait for the answer, rather than trusting an address supplied by a user. Deposits sent before that lookup completes are never credited — the frontend simply waits for it before enabling the deposit button.
Deposits & payouts
- Sending more than the required amount refunds the difference automatically — the same over-deposit protection V1 offers in native TON.
- Only DAO-approved, whitelisted jetton assets can be escrowed. Adding a new one goes through the same timelock that guards every other protocol parameter.
- Every other rule — the state machine, two-phase confirm, disputes, the 30-day timeout backstop — carries over from V1 unchanged.
Gas & fees
Because every jetton payout itself costs a small amount of network gas, each V2 vault is loaded with a small TON reserve at creation to cover it. Whatever's left when the vault closes is swept back to whoever created it — it's a prepayment for operating costs, not a fee.
| Fee | What it covers |
|---|---|
| Deployment fee | One-time cost to create a vault. |
| Referrer fee | Paid once per trade to whoever referred it — only if the seller ends up getting paid. |
| Milestone dispute fee | Prefunded by the buyer, fully refunded at close unless the council actually had to arbitrate. |
V3 — Oracle Marketplace
Beta · Pre-auditV3 turns a single trade into a marketplace. A seller lists a product with inventory; every purchase spins up its own escrow vault automatically. For real-world goods, delivery can be verified from cryptographically signed carrier data instead of relying on both parties to manually agree.
Listings & purchases
A Marketplace Listing holds price, remaining supply, and how delivery gets verified for that product. When a buyer purchases, the listing decrements its supply and deploys a dedicated escrow vault for just that purchase — the buyer's deposit flows into it through the same jetton path V2 uses.
Two settlement rails
Every listing is pinned to exactly one settlement mode — never both — so buyers know upfront what guarantee they're getting:
- Oracle-only. Delivery is verified automatically by a decentralized oracle report. The manual confirm path is disabled entirely.
- Manual-only. The classic two-party document-hash confirm from V1/V2. No oracle involved.
The oracle path
A decentralized oracle network reaches consensus on a real-world outcome off-chain, then a bridge service re-signs that consensus as a single cryptographically-signed report. The important design choice: trust lives in the signature, not in whoever sends the message. Anyone can relay a report — the on-chain Oracle Registry only forwards it if the signature checks out.
A "delivered" report never pays out instantly. It opens a 72-hour objection window during which either buyer or seller can still raise a dispute. Only once the window elapses with no objection can anyone trigger the final payout — permissionless, but never unilateral or instant.
If delivery is instead reported as failed, the buyer is refunded and the seller's guarantee bond is slashed to the buyer as compensation. A "partial" report routes straight into the standard dispute process for the DAO council to resolve.
V3 — Settlement Flow
A closer look at how a single oracle-settled trade moves end to end, and the money math behind each outcome.
Trade flow, stage by stage
| Stage | Actor | What happens |
|---|---|---|
| 1. List | Seller | Sets price, supply, settlement rail, and commercial terms; terms are hashed and anchored on-chain. |
| 2. Buy | Buyer | Verifies the on-chain terms hash, purchases N units, a vault is deployed, and the buyer deposits. |
| 3. Fulfil | Seller | Ships the goods (oracle rail) or exchanges delivery documents directly with the buyer (manual rail). |
| 4. Settle | Oracle / both parties | A signed "delivered" report opens the objection window and auto-settles after it, or matching document hashes release funds immediately. |
| 5. Dispute | DAO council | If either side objects, a 2-of-3 multisig resolution sets the final buyer/seller split, net of fees. |
Settlement math
Worked example: a 1,000 USDT trade with a 2% seller guarantee bond and a 1.5% commission.
| Outcome | Buyer receives | Seller receives | DAO / commission |
|---|---|---|---|
| Delivered | 0 | 1,005 (1,000 payment + 20 bond returned − 15 fee) | 15 |
| Failed | 1,020 (refund + slashed bond) | 0 (bond forfeited) | 0 |
| Partial | No automatic split — the DAO council sets a buyer/seller split net of the DAO fee. | ||
Payouts are always pull payments applied only after the objection window closes (or instantly if the buyer chooses to accept delivery early) — the contract sets each party's claimable share and each side withdraws it independently, so one failed transfer can never trap everyone else's funds.
V3 — Shipping Oracle
Beta · Pre-auditFor physical and commodity goods, "delivered" is verified against real carrier tracking data — not either party's word.
How delivery is verified
Seller submits shipment details
Container / bill-of-lading number and carrier, plus an optional B/L document pinned to IPFS.
Relayer checks the carrier
An ocean-freight tracking aggregator is polled for the shipment's real status: delivered, failed, or still in transit.
Verdict is signed
The outcome is bound to the shipping document and signed — the report can't be swapped to point at a different shipment after the fact.
Objection window, then settle
Same 72-hour window as any oracle report; either party can still object before the vault pays out.
Only an explicit carrier verdict of "returned / lost / undeliverable" ever settles as a failure. Anything ambiguous — a customs hold, a network hiccup, an "exception" status — is treated as still pending rather than triggering a refund. An escrow should never refund on an unclear signal.
To stop anyone but the real seller from submitting tracking for a vault, submission requires a cryptographic wallet proof — the caller must prove they control the exact wallet address registered as that vault's seller.
Settling without a carrier feed
A live carrier subscription only automates the "did it deliver?" check — it's never required to settle a trade. Three subscription-free paths always exist:
- Manual rail. On manual-only listings, seller and buyer simply confirm matching document hashes — no oracle at all.
- Direct release. On any vault, the buyer can release funds to the seller directly at any time.
- Dispute → DAO. Either party can escalate to the council for a manual resolution.
A manual verdict is never less safe than an automated one — it still only opens the objection window and can't skip it; the buyer can always object within the 72 hours either way.