How the marketplace works

Five states. No hidden transitions.

1. 1. Pending lock

   You chose a template. The server built an unsigned Lock transaction. Nothing is on chain yet.

2. 2. Locked

   Your wallet signed and submitted the Lock tx. Your ADA is now at the script address. The server has no control over it.

3. 3. Instantiated

   You spawned a workspace from the template. It seeds the documents, diagrams, and GTT nodes declared in the manifest.

4. 4. Validated

   As you bring GTT capabilities to `active`, the platform tracks progress. When every required slug is green, you can trigger Release.

5. 5. Released — or refunded

   Release: you + platform co-sign, seller is paid, platform takes its fee. Refund: after the deadline, you sign alone and reclaim every lovelace.

The full validator source ships in the repo at `contracts/validators/escrow.ak`. It is tiny and deliberately readable. Key facts:

• Two redeemers: `Release` and `Refund`. Nothing else spends the script.
• The Datum binds buyer, seller, platform, price, template hash, purchase id, deadline, and fee bps — all fixed at lock time.
• Fee math is integer-only (`price * bps / 10000`). There's no floating-point rounding and no off-chain math the on-chain code couldn't verify.
• The script ignores anything that isn't a `Spend`. No governance hooks, no migrations, no admin keys.

Read the full validator source

Both conditions must hold on-chain for a Release tx to spend the lock UTxO:

• Buyer AND platform must sign (`extra_signatories` contains both key hashes).
• Output amounts match the fee split: seller receives ≥ `price − fee`, platform receives ≥ `fee`.

The platform's signing rule (off-chain)

The validator allows the platform to co-sign, but the platform itself imposes four guards before producing a signature. These live in `src/lib/cardano/escrow/platform-signer.ts` and are visible in the repo:

1. Purchase status is `locked` — nothing else, not `released` or `refunded`.
2. `acceptance.acceptanceReachedAt` is set — every required GTT slug has reached `active`.
3. The tx pays the buyer-declared seller wallet and the platform wallet — no third-party siphon.
4. The datum's `template_hash` matches the purchase's recorded manifest hash — no hash drift between lock time and release time.

Read the full validator source

The refund path is unilateral — buyer-only. The platform cannot block, delay, or intermediate it.

• The tx is signed by the buyer alone.
• The validity range's lower bound is at or after `validation_deadline` (enforced on-chain).
• The full locked amount returns to the buyer's address.

If this platform vanishes tomorrow, every locked purchase can still be reclaimed by its buyer after the deadline. That's a property of the validator, not of the platform.

Templates are whitelisted exports of a workspace — every collection is filtered against a collection-sharp allow-schema, and a pattern verifier blocks PII leaks before publish. No allow-list, no publish.

• Allow-schemas live in `src/lib/server/template-export/schemas.ts` — one per collection, hand-written, no common defaults.
• The pattern verifier scans every emitted manifest for emails, wallet addresses, database ids, JWTs, UUIDs, phone numbers, and API-key signatures.
• User ids are remapped deterministically to role placeholders (`role:responsible_1`) inside the manifest. The placeholder map itself is never exported.
• Creator identity is opt-in only. Default is fully anonymous.

Read the full validator source