DEX Settlement Badges

info

Active portfolio classification — 2026-07-25 [D]. DEX Settlement Badges is a pre-launch settlement-evidence capability inside Skyzai Work, not an independent SKU, package, exchange, settlement rail, insurer, or authority source. Product, pricing, commercial-page, and standalone-launch language below is preserved design history; route names and local fixtures do not prove external replayable settlement.

Status: pre-launch. This page describes target design; this document does not establish a deployed service.

Scope: proposed settlement-evidence display within the Skyzai Work app/commercial package, concerning LIQUID exchange/payment terms. A badge does not settle a trade. Personal and Work are package routes for seven product owners, not two owners themselves. This is not a standalone SKU. See The Product Family.

Surface: dex.skyzai.com (declarative) Catalog route: skyzai.com/products/dex-settlement-badges/ Status: SPEC Evidence tier: [D] — badge taxonomy ratified; first external counterparty verification is the proof gate (re-tiered [B]→[D] 2026-07-03 per TIER_MERGE_GATE: a spec/draft is not an observed run; [B] requires a dated reproducible receipt) Source canon: (private, unpublished)

---

What DEX Settlement Badges Are

DEX Settlement Badges are verifiable status indicators for settlement legs. A badge is:

• Evidence-based — derived from on-chain or adapter proof, not reputation
• Replayable — can be re-verified against current chain state
• Tier-tagged — evidence tier visible, no claim above proof
• Non-attestational — we verify what happened, not what will happen

Critical boundary: We do not guarantee settlement, insure against failure, or replace legal contract enforcement. We verify evidence.

---

Badge Types

Badge	Meaning	Evidence Required
SETTLED	Successfully executed and final under the applicable rail	Expected asset, amount and recipient; rail-specific finality and replay checks
CONFIRMED	Evidence received but final settlement not yet established	Provider/rail receipt with its exact assurance scope
PENDING	Required evidence absent or incomplete	Submission is not execution
FAILED	Failure evidenced under the relevant rail	Revert or other scoped failure proof
DISPUTED	Challenge raised, under review	Challenge and review state

No status upgraded without the required evidence. Inclusion, signatures and a fixed confirmation count alone do not establish settlement; a badge name is not an evidence-tier upgrade.

---

Verification Architecture

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Settlement │────▶│  Receipt    │────▶│  Verifier   │────▶│   Badge     │
│  Request    │     │  Capture    │     │  Engine     │     │   Issued    │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘
                                              │
                    ┌─────────────────────────┼─────────────────────────┐
                    ▼                         ▼                         ▼
              ┌─────────┐              ┌─────────┐               ┌─────────┐
              │   DLT   │              │ Adapter │               │  Replay │
              │  Chain  │              │ Receipt │               │  Check  │
              │ Verify  │              │ Verify  │               │         │
              └─────────┘              └─────────┘               └─────────┘

Verification Process

The preserved example is incomplete and must not infer settlement from inclusion or a fixed confirmation count. A settled label requires rail-specific successful execution, expected asset, amount and recipient, applicable finality and replay checks. These are evidence requirements, not a tested implementation.

Historical incomplete verification sample — not implementation instructions

class SettlementVerifier:
    def verify(self, receipt: SettlementReceipt) -> Badge:
        # 1. Receipt integrity
        if not receipt.verify_signature():
            return Badge.FAILED("invalid_signature")

        # 2. Chain state verification
        if receipt.chain_receipt:
            tx = self.w3.eth.get_transaction(receipt.tx_hash)
            if tx.blockNumber and self.confirmations(tx) >= 12:
                return Badge.SETTLED(receipt)
            elif tx.blockNumber:
                return Badge.CONFIRMED(receipt, confirmations=self.confirmations(tx))

        # 3. Adapter verification
        if receipt.adapter_receipt:
            adapter = self.get_adapter(receipt.adapter_id)
            if adapter.verify(receipt.adapter_receipt):
                return Badge.CONFIRMED(receipt)

        # 4. Pending
        return Badge.PENDING(receipt)

    def replay(self, badge: Badge) -> Badge:
        """Re-verify a badge against current chain state."""
        return self.verify(badge.receipt)

---

Settlement Receipt Schema

Illustrative incomplete receipt — not settlement evidence. Placeholder identifiers and confirmation counts do not demonstrate settlement, replay or valid authorization.

{
  "settlement_id": "set_2026_abc123",
  "type": "dex_swap",
  "status": "confirmed",
  "badge": "CONFIRMED",
  "evidence_tier": "S",

  "trade": {
    "from": {"asset": "USDC", "amount": "1000.00"},
    "to": {"asset": "ETH", "amount": "0.5"},
    "rate": "2000 USDC/ETH"
  },

  "chain_evidence": {
    "tx_hash": "0x...",
    "chain": "base",
    "block_number": 12345678,
    "confirmations": 15,
    "timestamp": "2026-05-09T12:00:00Z",
    "receipt_verified_at": "2026-05-09T12:05:00Z"
  },

  "adapter_evidence": {
    "adapter_id": "uniswap_v3",
    "adapter_receipt": "0x...",
    "adapter_verified": true
  },

  "replay": {
    "replayable": true,
    "last_replay": "2026-05-09T12:10:00Z",
    "replay_result": "confirmed"
  },

  "ofn_receipt": "ofn:2026:set_abc123...",
  "authorization_receipt": "receipt:..."
}

The active schema uses a typed authorization_receipt; a public-DAV consequence requires the signer(s) required by applicable law, the entity's governing instrument, or a valid competent mandate to bind the exact consequence in a complete valid bound PRISM decision receipt. PRISM records and verifies only; agents stage unsigned proposals, whose IDs cannot substitute for the receipt; deterministic settlement is limited to that exact receipt-bound consequence.

---

API Specification

POST /v1/verify

Submit settlement for verification.

Request:

{
  "tx_hash": "0x...",
  "chain": "base",
  "expected_trade": {
    "from": "USDC",
    "to": "ETH",
    "amount": "1000"
  }
}

Response:

{
  "badge": "SETTLED",
  "settlement_id": "set_2026_abc123",
  "evidence_tier": "B",
  "chain_confirmations": 15,
  "replayable": true,
  "ofn_receipt": "ofn:2026:..."
}

POST /v1/replay

Replay a settlement verification.

POST /v1/batch

Batch verify multiple settlements.

GET /v1/badges/{id}

Retrieve badge status and history.

GET /v1/export

Export settlement proof for regulatory/compliance use.

---

Adapter Support

Adapter	Type	Chains	Status
Uniswap V3	DEX	Ethereum, Base, Arbitrum	Planned
Curve	DEX	Ethereum, Base	Planned
1inch	Aggregator	Multi-chain	Planned
Circle CCTP	Bridge	Ethereum, Base	Planned
Custom	Generic	Any	Enterprise

---

Evidence Tiers

Evidence description	What would support it
Design/specification [D]	Badge taxonomy and incomplete verification sample
Local tests	Dated reproducible tests; a stub is not a settlement receipt
Observed run [B]	Reproducible successful execution/finality/replay evidence
Independent verification [E]	Independently verified authorized rail use within scope

Current documented status: design/specification [D]. No higher status is established merely by a stub or an audit label.

---

What This Service Is NOT

• Not a DEX operator
• Not custody — no funds, tokens, or assets held at any point
• Not a settlement guarantee — we verify rail evidence; we don't coordinate settlement through any automated intermediary or AMM
• No finality claim before the source rail's evidence resolves
• No compliant badge before replay passes against source data

---

Regulatory Export

Settlement proof can be exported in regulator-ready format:

{
  "export_type": "regulatory_settlement_proof",
  "period": {"from": "2026-05-01", "to": "2026-05-09"},
  "settlements": [...],
  "audit_trail": "...",
  "attestation": {
    "signed_by": "0x...",
    "timestamp": "...",
    "tier": "B"
  }
}

---

η = 0 Compliance

Chargeable	Not Chargeable
Verification API calls	Settlement itself
Replay tooling	Chain state access
Dashboard and analytics	Badge claim (truth is free)
Regulatory export package	Export format itself

---

Cross-links

• Product page: /products/dex-settlement-badges/
• Buyer deck: /products/dex-settlement-badges/deck/
• Resource room: /products/dex-settlement-badges/resources/
• Access form: /products/dex-settlement-badges/access/
• Adjacent canon: API Pay (P0), OFN Receipts (P1), Merkle Bridge (47), Evidence Tiers (14)
• Source markdown: (private, unpublished)
• Listener code: (private, unpublished)

---

Historical predecessor wording — retained on 2026-09-27, not active rules

The displaced passages are preserved verbatim for lineage. This retention date is not their original authorship date.

Predecessor passage 1

| SETTLED | DLT-confirmed, replayable | [B] On-chain receipt with ≥12 confirmations | | CONFIRMED | Adapter-confirmed, not yet DLT-settled | [E] Provider receipt, pending chain finality | | PENDING | Awaiting confirmation | [I] Submitted, no receipt yet | | FAILED | Reverted or invalid | [B] Revert receipt or failure proof | | DISPUTED | Challenge raised, under review | [I] Dispute filed, review pending |

No badge upgraded without proof. SETTLED requires [B] receipt with replayable chain evidence.

Predecessor passage 2

Tier	Claim	Required Evidence
[I]	Badge architecture is defined	Design document
[B]	Verification stub + badge taxonomy ratified	Internal stub-test green
[E]	Live settlement verified and replayed	Mainnet receipt, replay proof
[A]	Settlement badges used in audited financials	External audit report

Current status: [B] — verification stub exists; first external counterparty verification is the proof gate.