This proposal updates the 0x1::dex module so that the Skip API indexer can discover and index V3 pools via the existing pool registry / enumeration interface.
As a result, newly created V3 pools become available for bridge/swap routing without requiring Skip API to implement bespoke V3 contract support.
Today, Skip API discovers pools by reading the pool list exposed by 0x1::dex.
With the introduction of V3 pools, Skip API would not see newly created pools unless:
Skip API adds direct support for V3 contracts (new indexing logic, new surface area, more operational coupling), or
0x1::dex is extended to expose V3 pools in the same way it exposes existing pools.
We choose the second approach to:
minimize integration work,
keep the indexing surface stable,
reduce operational risk from multi-service changes.
We will modify 0x1::dex so that:
V3 pool creation can register the new pool with 0x1::dex at creation time.
0x1::dex can return a complete list of pools, including V3 pools, via the same pool enumeration path that Skip API already uses.
V3 DEX Deployer Address:0xd78a3b72c7ef0cfba7286bfb8c618aa4d6011dce05a832871cc9ab323c25f55e
Package Address:0x47c42baa4d5efd7a0f8241597d1df0e6fa84fc87c06d1cc54ecf9d165308b4ff
To minimize the changes required to support V3 pools on our existing bridge/swap routing, we extend the existing 0x1::dex registry behavior:
V3 pools self-register at creation.
Indexers keep a single, consistent source of truth for “all pools”.
This reduces operational risk (fewer moving pieces across services) and speeds up time-to-support for new pools.
February 19 — Forum proposal posted
February 20 — On-chain vote begins
February 21 — On-chain vote ends (proposal executed if passed)
YES — You support upgrading 0x1::dex so V3 pools are discoverable by Skip API.
NO — You do not support this upgrade.
NO WITH VETO — You believe this proposal is harmful, spam, or violates governance principles.
ABSTAIN — You choose not to vote for or against, but want your vote counted toward quorum.