Design principle
Ordex separates the four concerns that centralized marketplaces tend to collapse: submitting an order, verifying its chain state, distributing discovery data, and settling a trade. Each concern has an explicit owner and an observable record.
Artifacts are portable
PSBT evidence is not locked inside the database of the market that first observed it.
Verification is local
A gateway checks the chain and indexer it is configured to trust, then reports a time-bound result.
Distribution is signed
A publisher uses their own Nostr signer to make a discovery event independently attributable.
System map
Solid paths are verification calls or explicit imports. The relay path announces signed discovery events; it is not settlement. A gateway does not subscribe to relays: what you browse comes from the gateway you are connected to, so adding a relay changes where your own listings are announced, not what you see for sale.
The evidence path
- An order artifact is supplied.A direct import, a supported market adapter, or a signed OpenOrdex-compatible event introduces a PSBT plus context.
- The gateway normalizes it.Strict parsing derives deterministic inputs, digest, protocol metadata, and a safety classification.
- Configured services verify it.Core checks each required UTXO.
ordchecks any claimed inscription location. Each outcome is recorded as a lifecycle state. - The projection becomes searchable.Markets and users filter a normalized inventory by protocol, token, state, source, safety, price, and side.
- A publisher announces it.A NIP-07 signer signs the prepared kind-802 envelope and the publisher offers it to the relays they chose. Accepted, refused, and unreachable relays are reported separately. The signed event is then handed back to the gateway, which verifies its signature before recording it as evidence.
Trust boundaries
| Component | Can assert | Cannot assert |
|---|---|---|
| Bitcoin Core | Current availability of a queried UTXO at check time. | That a UTXO stays available after the response. |
| ord | Current indexed location of a claimed inscription. | Settlement intent, price, or wallet ownership. |
| Ordex gateway | Parser result, normalized metadata, local check result, event validity, and which key owns a listing. | Control of a wallet, private key, or another gateway's policy. |
| Nostr relay | That it acknowledged a signed event submission. | Universal delivery, active UTXO state, trade completion, or what a gateway shows you. |
| Market client | Which gateway and relay evidence the user sees. | Trust beyond the selected sources and current verification time. |
Market discovery without a central listing gate
A compatible market can operate a gateway for its users, accept signed events its publishers hand to it, and expose the same protocol and token filters as any other market. A user can instead connect the client to their own gateway; the client checks that the address really answers with the Ordex contract, on the expected network, with a recent node observation, before it uses it. This makes listings portable while preserving different market interfaces, moderation policies, and liquidity experiences.
Portability does not erase market choice.
Ordex lets markets share inspectable evidence. It does not require a market to display every event, remove its own safety policy, or route settlement through a third party.
Failure behavior is explicit
If a gateway cannot reach Core, the order is PENDING_NODE, not implicitly live. If the ordinal index is incomplete or behind the chain, the order is PENDING_ORD and the gateway reports that it cannot verify listings at all rather than claiming readiness from configuration. An unconfirmed spend of the source output is MEMPOOL_CONFLICTED, which can still be replaced or dropped; a confirmed spend is SPENT, and a confirmed spend by the transaction the gateway preflighted for this order is SETTLED. A reorganisation that returns the output puts the order back to LIVE. These states make different gateway results explainable instead of hiding uncertainty behind a single green badge.
A background reconciler rechecks every order whose state can still change, under a single lease so one deployment reconciles rather than one process per release. Nothing depends on a customer pressing a button to keep the orderbook truthful.
Continue with the troubleshooting guide for the operational diagnosis flow.