Permissionless
Permissionless use — anyone may list a real asset, trade, deploy, and delegate without an allowlist — and the line where gated operation (validators, high-security chains) begins.
LP-0012: Permissionless
Abstract
No gatekeeper sits between a participant and using the network: anyone may list a real asset, submit a trade, deploy a contract, and delegate stake — without an allowlist or admin approval. Operating the network is a separate concern with a separate answer: validators, and the high-security chains they run — bridge, DEX, MPC — and threshold consensus, are gated to the genesis validator-NFT set, deliberately. This LP states the use invariant, names the code points that enforce it, and draws the line where permissionless use ends and gated operation begins.
Motivation
"Permissionless" is claimed everywhere, enforced almost nowhere, and overclaimed — stretched to cover operating critical infrastructure, which is gated here on purpose. A single admin allowlist on any use point — listing, trading, deploy, delegation — quietly converts the chain into a permissioned one. The property holds only if enforced at each use point and auditable. This LP makes the use points explicit, and is equally explicit about the one place operation is gated, so the two are never conflated.
Specification
The use invariant: the protocol admits a well-formed use action — list, trade, deploy, delegate — from any party. It refuses only for a reason intrinsic to the action (malformed, unfunded, not real on-chain), never for the identity of the party or its absence from a list. Operating a chain is not a use action; it is gated (§5).
1. Delegation is open; validation is gated
Delegating stake is open — any holder may delegate to any validator (LP-145, permissioned-validators-open-delegation). Running a validator on the primary network is not: the validator set is the holders of the genesis validator NFT, kept deliberately small (LP-145, LP-048). You may always back the network permissionlessly; operating it is gated. A sovereign L1 sets its own validator policy on ascension — fee-based open entry is one option (AscendToSovereignTx, LP-3820).
2. Asset listing
Any market over two real assets is created by anyone. There is no listing committee and no approval step.
The enforcement is OpenMarketChecked in dex/pkg/dexcore/place.go:224. Its own comment states the invariant: there is "NO allowlist and NO 'approved-by-admin'". A market open admits each side through two orthogonal checks before any state write:
Resolve(base) -> Resolve(quote) -> VerifyOnChain(base) -> VerifyOnChain(quote) -> EnsureMarket
- Resolve proves the side's canonical identity on the bound network. Permissionless: a well-formed real native/ERC-20 reference always resolves; only a malformed, wrong-network, disabled, or fabricated reference is refused.
- VerifyOnChain proves the side is backed by live on-chain code in the state this block mutates. A synthetic ERC-20 — an ASCII-ticker address, a self-destructed or never-deployed contract — has no code and is refused.
Both checks run for both sides before any write, so a refused open leaves the store untouched. The refusal is never "you are not approved"; it is "this asset is not real". Any real (base, quote) pair yields a market.
3. Trade submission
Order submission carries no allowlist. An order is admitted on the asset identity and balance it asserts, refused only for an intrinsic defect — unresolved asset, insufficient custody, malformed order — through the same admission path that backs listing. There is no per-account permission to trade.
4. Contract deploy
Deploy is open by default. The deployer allowlist precompile exists for chains that choose to restrict deploy, but it is opt-in per chain, not a network default. An unconfigured chain admits a contract from any address.
5. Operating a high-security chain is gated
Using the DEX, bridge, or MPC is permissionless (§2, §3). Operating them is not. A node activates a high-security chain only if two conditions hold, checked before it tracks the chain (node/chains/manager_authz.go:90, authorizeChainActivation): the operator opts in (e.g. dex-validator), and its staking address holds that chain's authorization NFT (ChainAuthorizations, manager.go:381; holdsAuthorizationNFT, :51). The D-Chain "activates only if DexValidator is true AND the NFT" is held (manager.go:390); bridge (B) and MPC (M) gate the same way.
This is deliberate. These chains move custody and run threshold ceremonies — security-sensitive and still hardening — so operation is restricted to the genesis validator-NFT set: small, accountable, by design. The DEX in particular runs as a local, operated, high-frequency venue, not a public primary-network chain.
It is not a permissionless violation. Permissionless is a use property (§2–§4): anyone trades on the DEX. Operating the matcher is gated. The two never touch — admission to trade checks the asset, not the trader; admission to operate checks the NFT, not the order.
The line you must not cross
The ERC-20 strict-tokens set in LP-9999 §9 — "an allowlist of strict tokens (no rebasing / fee-on-transfer / callback)" — is not a listing gate. It is a settlement-safety guard: a token that rebases or takes a fee on transfer breaks the observed-delta accounting the settlement precompile relies on to move exactly the named counterparties' value and nothing else. An arbitrary token is not refused a market — it is wrapped to a canonical AssetID balance first, then settled safely.
Two distinct properties live in two distinct places:
| Property | Question | Where | Refuses |
|---|---|---|---|
| Permissionless listing | May this market exist? | dexcore/place.go:224 | only a non-real asset |
| Settlement safety | Can value move atomically? | LP-9999 §9 | a token whose transfer breaks delta accounting |
Conflating the two reads the settlement guard as a listing allowlist and concludes, wrongly, that the DEX is permissioned. It is not. The strict-tokens set constrains how value settles, never which markets may open.
Rationale
Each use point refuses on an intrinsic property of the action, never on identity, so the points can be checked independently: delegation open (LP-145), listing against one function (place.go:224), trade against the same admission path, deploy against an opt-in precompile that defaults off. Operation is the one gated axis (§5) — checked against the validator NFT, never against the action. The two axes are kept apart on purpose: use is open, operation of critical infrastructure is earned.
Backwards Compatibility
This LP states existing properties. No code changes.
Security Considerations
Permissionless listing depends entirely on VerifyOnChain being authoritative: if a fabricated asset could pass the reality check, a market over a phantom asset would open. The check is fail-closed — no verifier wired means refuse, not admit (ErrNoOnChainVerifier). The operate gate is likewise fail-closed: a node without the opt-in and the authorization NFT declines to track the chain (authorizeChainActivation), so a non-operator cannot run the matcher, the bridge signer, or an MPC share. Permissionless deploy on a chain that has not configured the deployer allowlist is intentional; a chain wanting restricted deploy opts in.
Copyright
Copyright and related rights waived via CC0.