Vida DEX — Public Proof Record

Last updated: 2026-10-01 · Network: Kaspa mainnet
Every transaction id on this page is a full 64-character id, verified accepted on-chain at publication time. Verify any of them at explorer.kaspa.org or the public API https://api.kaspa.org/transactions/<txid> (field is_accepted).

What Vida DEX is

Vida DEX is a decentralized exchange whose core logic — pool reserves, fees, every payout — runs inside Kaspa covenants: programs enforced by the Kaspa blockchain itself, not by a website or a company. The exchange never takes custody of a trader's keys. The covenant can only move funds through transitions that satisfy its own published rules.

What makes it different from other Kaspa DEXs: the price is attested. Swaps that depend on an external price are gated by an oracle signature the covenant verifies on-chain — with a confidence grade, a nonce, and a freshness window enforced inside the covenant logic. A stale or mispriced attestation fails the transaction; the covenant rejects it, closed.

Live system components

How to verify pool state without trusting us

• The pool's entire state (reserves, LP supply, fee, nonce, height) is baked into the redeem script of its unspent transaction output.
• The API recomputes the pool's P2SH address from the claimed state; if the chain shows a live UTXO at exactly that address, the claimed state is byte-exact.
• Every state response includes state_proof: "P2SH byte-match" and the state_address so you can confirm on the explorer yourself.

The verified lifecycle (all txids chain-confirmed accepted)

Pool 1 — genesis through full lifecycle

Pool 2 — second pool, cross-pool routing

Batch settlement — uniform-price auction covenant

Agent-executed swap — no escrow, agent's own keys

The agent operated with keys generated for it, discovered the pool on the public registry, priced its trade from the public quote API, signed an intent (amount, slippage guard, payout address, expiry), and signed the swap transaction with its own key. The operator never held agent funds — the agent's KAS went directly into the covenant transaction, and the payout went directly back to the agent's address. This transaction is the covenant accepting a third-party caller, on mainnet, with the oracle attestation verified in-covenant.

Honest boundaries

• Single-signer oracle seam. The oracle network polls multiple independent nodes off-chain; the covenant currently verifies one aggregated signature. The covenant sees one key, not the quorum. Pinning N keys with an on-chain threshold is a designed, costed, pending upgrade — the honest term for today's model is a well-operated signer, not a threshold oracle.
• Notional side. Pool side B is an internal accounting unit, not a redeemable token. The pools trade real KAS against an internal price ratio. We will not describe this as a two-asset AMM until a real token occupies side B under the same covenant.
• Audits. Accepted mainnet transactions prove the code runs and the rules bind. That is not a substitute for a formal third-party security audit, which is planned before scale-up.
• Operator role today. Discovery, pricing, state-verification, and swap execution are agent- or self-serve; the oracle attestation service is the remaining operator-run component on the critical path.

All materials on this site use city/region names only for infrastructure locations. Internal system codenames are never published.