Assets

Implementation status (code-audited 2026-07-03): SHIPPED Domain-separated DeriveAssetID + AssetKind confirmed (dex/pkg/dex/assetid.go:47-61,102,149; dexvm mirror chains/dexvm/registry/asset.go:199 with golden test); permissionless admission confirmed (dex/pkg/dex/place.go:222-250). Path note: implementation lives in pkg/dex (not pkg/dexcore).

Source: github.com/luxfi/dex

Abstract

An asset on the DEX is named by where its reality can be proven, not by a ticker. There are two realms: EVM (proven by C-Chain state) and UTXO (proven by an X-Chain assetID). Every asset folds to one 32-byte AssetID. A market over two assets opens permissionlessly once both sides resolve and both are shown to be real on-chain.

Realms

A realm is where an asset's reality is proven.

• EVM — reality is C-Chain state. The EVM realm has two forms, told apart by the reference:
  • native LUX — reference is the EVM zero address (0x0). It is the chain's own coin and is always real; there is nothing to look up.
  • ERC-20 — reference is a 20-byte contract address. It is real iff that address has code.
• UTXO — reality is an X-Chain attestation. The reference is a 32-byte X-Chain assetID.

ERC-20 is EVM. It is not a third realm. The split that matters is the realm — EVM vs UTXO — not the form within it.

The enum AssetKind{EVMNative, ERC20, UTXO} (dex/pkg/dexcore/assetid.go:47) is three settle paths, not three realms. EVMNative and ERC20 settle on the C-Chain; UTXO settles against the X-Chain. The realm axis is orthogonal to the settle path: two of the three kinds live in the EVM realm.

Identity

The AssetID is a domain-separated fold over (networkID, sourceChainID, kind, ref):

domAssetV1 | networkID | sourceChainID | kind | ref

Every field is length-prefixed, so the fold is injective — no two distinct tuples share a preimage. The kind byte separates the classes, so an ERC-20 address can never collide with a UTXO assetID whose low bytes happen to match (dex/pkg/dexcore/assetid.go:23, :149). The reference is normalized per kind before folding (dex/pkg/dexcore/assetid.go:113):

kind	ref
EVMNative	the native marker — 20 zero bytes
ERC20	20-byte contract address, never the zero address
UTXO	32-byte X-Chain assetID

One primitive derives this id. The 0x9999 C-Chain value path and the D-Chain dexvm registry call the same DeriveAssetID, so a registered id and a swap-derived id are equal by construction — no two derivations can drift.

Admission

Markets are permissionless. There is no allowlist and no admin approval (dex/pkg/dexcore/place.go:224). OpenMarketChecked(base, quote) admits each side in order before any state write:

Resolve(base) → Resolve(quote) → VerifyOnChain(base) → VerifyOnChain(quote) → EnsureMarket

• Resolve proves the canonical identity on the node's network. A well-formed real reference resolves; a malformed, wrong-network, disabled, or fabricated reference is refused.
• VerifyOnChain is the authoritative test: is the side backed by live on-chain code in the state this block mutates? A fabricated ERC-20 — an ASCII-ticker address, a self-destructed or never-deployed contract — has no code and is refused. Native LUX is the chain's own coin and is always real (dex/pkg/dexcore/place.go:240).

Both steps run for both sides before any write, so a refused open leaves the store untouched. Admission is identity-then-reality: resolve the name, then verify the asset exists. That is the whole gate.

Rationale

Naming an asset by its realm and reference, not a ticker, means identity is a fact of the chain, not a registry entry. Folding (networkID, sourceChainID, kind, ref) makes the id reproducible from those facts alone, so the matcher and the settlement contract derive the same id without coordination. Permissionless admission needs no allowlist precisely because reality is checkable: an ERC-20 either has code or it does not.

Related LPs

LP	Relationship
LP-9000	DEX core; this LP is its asset model
LP-9027	Wire transport that carries orders over these assets

Copyright

Copyright and related rights waived via CC0.