Permissions

Thirty-four keys, all seeded by the platform's permissions seeder, all beginning dex. They follow the standing convention: the admin path with / as . and - as _. /admin/dex/chain is access.dex.chain; the read and write keys on the same screen are view.dex.chain and edit.dex.chain.

Two different gates enforce them, and both have to pass:

• The access. key gates reaching the screen at all. It is what frontend/middlewares/permissions.json matches the URL against, and it is what the megamenu entry carries.
• The view. / create. / edit. / delete. keys are declared on each backend route and on the DataTable's own permissions prop. They are what actually decide whether a request succeeds.

A role holding access.dex.chain and not edit.dex.chain can open the chain console, read every row, and have every save refused.

The eleven access keys, and the thirteen screens

Three of those cover more than one screen on purpose:

• Requirements and Wallets sit under access.dex.chain. Requirements is the diagnosis half of the same decision the chain console is the fix half of, and a separate key would let a role reach the fix and not the diagnosis. Wallets edits nothing the chain console does not already edit — the fee recipient is a dexChain column — so minting a separate wallet key would be a second gate on one decision, and the two would eventually be granted differently.
• The pool and position detail screens share their list's key. Without that, the detail path matched nothing in the manifest and fell back to the broad access.admin, so a role scoped to the Swap console could open the register and not any row in it.
• The fee accrual ledger shares access.dex.fee. It is the same screen's detail view.

Read

Ten view. keys. Each is declared on the list endpoint behind its console.

Two POST routes deliberately sit on a view. key because they write nothing: pair discovery returns candidate pools, and POST /api/admin/dex/revenue/reconcile scans the chain and reports. Neither is audited, because an audit log full of probes buries the writes that matter.

Write

Seven edit. keys, three create. and three delete..

Chains and providers have no create. or delete. key at all — both registries are code, so the console configures rows it cannot make or destroy. Positions have no edit. key either: a position is opened by a receipt and closed by a receipt, and nothing on that screen may write one.

The four keys to treat as privileged

edit.dex.chain — where your revenue lands, and which endpoints are trusted

This is the one to reason about the way you would reason about a withdrawal-approval permission. It writes dexChain.feeRecipient, which is the only address the integrator fee on that chain is paid to — there is no global fallback and no second approval step. A holder can point every future swap fee on Ethereum at an address you do not control, and nothing about the saved row looks wrong afterwards.

It also writes both RPC fields — including the server-side override, which is never returned to a browser and can be pointed at any endpoint.

What it does not reach is the router allowlist. That list is the static code list, plus every registered AMM deployment, plus dexChain.metadata.extraRouters[] — and metadata is written by no admin route in this addon. The chain PUT accepts six columns and ignores everything else, so holding this key cannot add a contract address to the list that is checked against the to and the approval spender of a quote before a user is asked to sign it. Changing that list is a direct database edit today.

Two mitigations exist and neither is a substitute for granting the key carefully: feeRecipientUpdatedAt is stamped only when the address actually changes, so "when did our revenue destination move" is answerable; and the audit trail records the zero-fee acknowledgement in words rather than as a boolean.

edit.dex.fee — the key that credits your books

The revenue console shows accrued, swept and on-chain figures. Reading them takes view.dex.fee. Recording a sweep — POST /api/admin/dex/revenue/sweep — takes edit.dex.fee, and that is the action that starts the settlement chain: the covered accruals move to SWEEP_SUBMITTED, and the settlement cron waits for the recorded transaction to confirm and then books an adminProfit row.

The platform holds no key here and signs nothing; the route records a transfer the operator made themselves. But an incorrect record is a credit to your own books against a transaction that did not carry what it claims, so grant it to whoever is accountable for revenue rather than to everyone with access.dex.fee.

create.dex.pool and edit.dex.pool — the operator's own capital

These two are the only keys in the addon that let somebody commit your money. Registering a pool is inert. edit.dex.pool is not: it covers the seed verification and the withdraw verification, which is to say the whole of taking and unwinding a market position.

Seeding is not a configuration change. The operator holds the impermanent loss and becomes the counterparty to everyone who trades against the pool, and on a V2 pool the LP fee can never be withdrawn as revenue at all. See Direct pools and Liquidity positions.

dexPoolRiskAckRequired (on by default, Super Admin only) means a seed with no current, unrevoked acknowledgement is refused; switching it off removes the dialog but not the record — the seed still writes an attributed waiver naming the admin who allowed it.

edit.dex.settings — and the five keys it does not reach

Saving the Swap settings screen takes edit.dex.settings. Five settings are protected and need the Super Admin role, resolved server-side on every request, in addition to the permission:

A payload touching any of them from a caller without the role is refused with a 403 and nothing is saved — the whole change, not just the protected key, so a save is never half-applied.

What none of these keys does

Nothing here affects what a customer can do. Connecting a wallet, quoting and swapping are gated by the master switch, the token allowlist, the geo list and — where you switched it on — KYC. These keys control the admin side only.

There is also no key that moves funds, reverses a swap or signs anything, because no such route exists. The most a holder of every key on this page can do is stop offering new swaps.

See Roles and permissions for how keys are attached to roles, and The admin surfaces for what each console answers.