Intents are too narrow, too closed, and too centralized

The pitch for intents was one of the cleanest ideas DeFi has produced in years: stop specifying the transaction, start specifying the outcome. Don't build the calldata for a three-hop swap, don't pick the venue, don't manage slippage and gas — just sign a statement of what you want to be true afterward and let a competitive market of solvers race to make it true, cheaply and atomically.

That framing is general by construction. "What I want to be true afterward" could be a swap, a leveraged position, a bridged balance, a refinanced loan, a hedged basis trade, a scheduled DCA, a fully-repaid debt across three protocols. The intent is the goal; the solver supplies the path.

Almost none of that generality made it into production. What actually shipped is narrower, more closed, and more centralized than the pitch — and those three compromises are related. This article is about what intents became, why each compromise happened, and what a system would have to look like to avoid all three: modular, permissionless, and running its orderflow on decentralized storage instead of a single company's API.

1. Intents became a signed swap

Look at what the flagship intent protocols actually express. A CoW Protocol order is a token sell amount, a token buy amount, a limit price, and a deadline. A 1inch Fusion order is a Dutch auction over the same shape. A UniswapX order is a signed off-chain Dutch auction — again, one token in, one token out. These are excellent products. They are also, structurally, "trade A for B" with a nicer envelope around it.

That's a big gap from "declare any outcome." The moment your goal has state — a debt position that must stay solvent, a collateral leg that has to be re-supplied in the same transaction, a cross-domain balance, a condition that should trigger later — the signed-swap intent can't hold it. You fall back to building the transaction yourself, which is exactly what intents were supposed to abolish.

There's a reason the swap case won first: it's the one intent where the "outcome" is a single number (did I receive at least minOut?), the settlement is atomic on one chain, and the solver's job is a well-studied optimization (routing). Everything that makes swaps tractable is also what makes them narrow. A general intent — "be 3× long ETH against USDC, and keep me above a health factor of 1.4" — has a multi-step path, touches multiple protocols, and has a success condition that isn't one number. Today's intent formats simply have nowhere to put that.

None of this is because the machinery underneath can't do more. The settlement engines are often perfectly general — CoW's settlement contract, for instance, executes an arbitrary array of on-chain calls, so a solver can build a settlement out of any interactions it likes, not only trades. The narrowness lives one layer up, in the language the user is allowed to sign. The execution layer could express a leveraged, cross-protocol, cross-domain position; the intent format simply has no field in which to ask for one. The generality is present in the system and withheld from the user — which is arguably worse than not having it at all.

The tell is in the order struct. If the only degrees of freedom a user can sign over are sell token, buy token, amount, price, expiry, then the system isn't an intent engine — it's a gasless limit-order book. Useful, but not the general primitive that was promised.

A handful of newer designs are trying to break out of the swap template — declarative, constraint-based intents (Essential), fully general intent-centric architectures (Anoma), a standard whose order payload can carry arbitrary destination-chain calldata (ERC-7683), and general on-chain execution engines that are already live (Enso). So generality isn't unimaginable. The point is narrower and more awkward: the systems with real volume today still speak swap, and the ones reaching past it are mostly early-stage — or, like Enso, general in execution without being permissionless and decentralized in discovery. Nobody has yet combined all three. That combination is the open problem this article is about.

2. Some intents are permissioned on purpose — and cross-chain is why

The second compromise is that a meaningful slice of intent solving is not open to anyone. The clearest case is cross-chain.

A cross-chain intent — "I have USDC on Arbitrum, I want USDT on Base" — has a structural problem that a same-chain swap doesn't: the solver has to spend before it gets paid. To satisfy you, a solver (relayer, resolver, taker — the names differ) sends its own funds to you on the destination chain now, and only later gets reimbursed from your locked funds on the source chain. Between those two events it is carrying settlement risk: a reorg, a failed proof, a bridge delay, or a bug can leave it out of pocket. Solvers front real inventory on the promise of being made whole.

That single fact — fill first, get repaid later — is why the design pressure on cross-chain systems bends toward gating fillers. If anyone can register, an undercapitalized or malicious one can grief the system or fail mid-fill. There are two ways to bound that risk, and today's protocols split across them.

The first is to restrict who is allowed to fill — a whitelist, a KYC gate, a stake, or all of them. 1inch's Fusion+ is the clearest case: its own whitepaper says resolvers are "entities that have passed KYC/KYB procedures and have legally enforced agreements with 1inch Network," and that same permissioned set is what carries orders across chains through escrows, hashlocks, and timelocks. Here the solvency problem is answered with a membership list.

The second is to keep filling open but make cheating expensive — bond the settlement claim, not the filler, and add an optimistic challenge window in which a false claim can be disputed and slashed before funds move. This is roughly what Across and deBridge's DLN do: anyone can run a relayer or solver, and the trust lives in a bonded settlement layer rather than an allow-list. The remaining barrier is economic, not administrative — a filler still has to pre-fund inventory on every destination chain it serves — so in practice these "permissionless" markets concentrate around a handful of professional, well-capitalized solvers.

So the honest read isn't that cross-chain must be permissioned — it's more interesting than that. The solvency problem is real; one common answer is a permission gate, and even the permissionless answer drifts toward a small, capital-rich set. And permission, once introduced for solvency, is sticky: a whitelist that exists for prudent reasons is also, conveniently, one you can use to exclude competitors, extract rent, or satisfy a regulator. That's the trap — the mechanism that starts as risk management ends as a moat, when the same risk can be handled with economics instead. (Hold that thought; it's the crack we pry open later.)

3. The orderflow runs through one company's server

The third compromise is the least discussed and the most consequential: almost every intent system disseminates its orders through a single centralized service. The user signs a gasless order — and then hands it to one off-chain orderbook, operated by the protocol's own team, which decides what solvers see and when.

Walk the three flagships:

• CoW Protocol runs an off-chain orderbook service operated by the CoW team. Users submit signed orders to it; solvers read the auction from it and submit solutions back to it; an operator-run "autopilot" sequences the batch auction. The settlement contract is on-chain and the solver set is decentralizing, but the orderflow — the thing that decides which orders exist and who sees them — is a hosted API.
• 1inch Fusion / Fusion+ distributes orders through a 1inch-operated relayer/API to its whitelisted resolver set. Users don't gossip their orders to a network; they POST them to 1inch.
• UniswapX is the sharpest example of the split. Filling is permissionless on-chain — anyone can call the reactor. But orders are disseminated through an off-chain service run by Uniswap Labs, including an RFQ/quote step where registered quoters get first look before an order decays into open competition. The contract is open; the orderflow is a company endpoint.

The pattern is identical across the board: the settlement layer is decentralized, and the discovery layer is not. Whoever runs the orderbook is a trusted third party with a set of powers users rarely price in. They can go down and halt the market. They can censor an address or a token. They can reorder, delay, or preferentially route an order to a favored solver. They can see every intent before anyone else does — which is the most valuable data in the system, because an intent is a pre-committed trade you haven't executed yet. "Non-custodial" is loudly true and quietly incomplete: nobody can take your funds, but somebody controls whether your intent is ever seen, and gets to look at it first.

This is the compromise that most contradicts the original pitch. We rebuilt the exchange's matching engine as a single server and called the result decentralized because the final transfer happens in a contract.

4. And none of it is modular enough

The fourth problem is architectural, and it's why the first three persist. Each of these systems is a vertically integrated stack: one order format, one auction mechanism, one settlement contract, one orderbook, one solver-eligibility rule — welded together and shipped as a product. That design is why the swap is the only first-class intent, why the solver set has one permissioning policy, and why there's exactly one orderbook: those choices are baked into the stack, not parameters of it.

You can see the cost when you try to extend one. Want a new intent type — a leverage position, a lending action, a conditional order? In a vertically integrated system that's a protocol change: new struct, new verification path, new solver logic, a fresh audit, a governance vote, a redeploy. Want a different settlement venue, a different fee model, a second solver network with its own trust assumptions? Same story. Every axis that should be a plug is instead a fork. The systems aren't extensible; they're rewritable, which is not the same thing, and it's why after years the expressible intent is still "swap A for B."

Modularity here isn't an aesthetic preference. It's the precondition for the other three problems to be fixable at all. You can't get general intents without a pluggable order-type layer. You can't get permissionless cross-chain without a pluggable solvency/settlement layer where bonding is a strategy rather than a hardcoded gate. You can't get decentralized orderflow if the orderbook is fused to the matcher. Narrow, closed, and centralized are the symptoms; monolithic is the cause.

What the alternative looks like

Flip all four. The system we want is modular, permissionless, and gossips its orderflow over decentralized storage — infinitely extensible because every part that today is welded shut is instead a swappable component.

Modular: every welded seam becomes a plug

The core move is to stop shipping one stack and start shipping a set of composable interfaces, each with many interchangeable implementations:

• Order-type modules. An intent is not hardcoded as a swap struct. It's a typed payload against a registered order-type module — swap, leverage, lend, bridge, repay-across-protocols, conditional/scheduled — and adding a new one is registering a module, not forking the protocol. This is the layer that finally lets an intent express state and multi-step goals, killing problem #1.
• Validators. Signature checks, solvency checks, attestations, and filler-eligibility rules are pluggable predicates, not a single baked-in policy. A market that needs a bonded filler set expresses that as a validator module; an open one omits it. Permissioning becomes a per-market choice, not a property of the whole system — which is how problem #2 stops being all-or-nothing.
• Solver strategies. Routing, flash-loan leverage, inventory fills, cross-domain fills are separate, independently deployable strategies competing on the same orders. New strategies show up without anyone's permission.
• Settlement adapters. Same-chain atomic settlement, optimistic cross-chain settlement, escrow-with-timelock — each is an adapter behind one settlement interface, so a solver picks the settlement model the intent requires.

"Infinitely extensible" is just the honest description of this shape: because every axis is a module against a stable interface, the set of expressible intents, eligible solvers, and settlement venues grows by addition, never by rewrite. The system's capabilities aren't a fixed menu — they're an open registry.

Permissionless: replace the gate with a strategy

Modularity is what lets us take problem #2 seriously instead of surrendering to it. The cross-chain solvency problem is real — a filler genuinely does front capital and genuinely can be griefed. But "therefore whitelist the fillers" is only one answer, and it's the one that centralizes.

The permissionless answers are economic, not administrative: a filler posts a bond proportional to the value it fronts, is made whole through an optimistic settlement window where a fraudulent fill can be challenged and slashed, and builds reputation that lets counterparties price its reliability — all expressed as validator and settlement modules rather than a membership list. Anyone can become a filler by putting up capital and following the rules; nobody has to be let in. The gate becomes a smart-contract-enforced strategy that any participant can satisfy. Solvency stops requiring an allow-list.

This isn't hypothetical — it's the crack from section 2. Across and deBridge's DLN already settle cross-chain fills this way: filling is open to anyone, and the honesty of a fill is secured by a bonded, optimistically-challenged settlement layer rather than a whitelist. They prove the economic route works. The unfinished part is that even there the residual barrier — pre-funding inventory on every chain — quietly re-concentrates fillers among a few capitalized professionals, and the orderflow those solvers listen to still comes from a hosted service. Modularizing the validator and settlement layers is how the economic route generalizes beyond bridging to every intent type; decentralizing orderflow (next section) is how you stop the concentration from happening at the discovery layer too.

Decentralized orderflow: the part that has to leave the server

The deepest fix is to move the orderbook itself off any single company's infrastructure. If discovery is the centralized layer, then decentralizing discovery is the whole game — and that means a peer-to-peer, censorship-resistant message layer carrying the orderflow instead of a hosted API.

This is where Waku fits precisely. Waku is a generalized, privacy-preserving p2p messaging protocol — the production successor to Ethereum's Whisper, built on libp2p by the Vac/Logos team and used by projects like Status and Railgun. Its properties read like a spec for decentralized orderflow:

• No central server. Messages propagate through a gossip network of relay nodes. There's no orderbook API to POST to, take down, or subpoena.
• Topic-scoped pub/sub. Intents publish to content topics; solvers subscribe only to the topics — the order types, the chains, the assets — they can actually serve. That's the discovery layer as a subscription, not a query against someone's database.
• Censorship resistance. No node operator can quietly drop an address's orders; peers route around a node that tries.
• Persistence via store nodes. Light clients and late-joining solvers can retrieve recent message history, so you don't need to hold a socket open to a company to have seen the book.
• Privacy. Waku was built for metadata protection, so who is broadcasting an intent isn't trivially deanonymized at the transport layer — the opposite of a single operator that sees every order first.

This isn't purely theoretical. RAILGUN already runs a network of Waku nodes as its broadcaster layer: relayers gossip their fees over Waku, and users anonymously announce transaction requests before a private transaction is submitted on-chain. That's order-shaped message dissemination on Waku, in production today — a privacy-relayer network rather than a full intent book, but proof that the transport already carries exactly this kind of traffic.

Put orderflow on Waku and the most valuable, most centralizing asset in the whole design — first look at every intent — stops belonging to one operator. Intents become a public broadcast to a permissionless network that any solver can listen to on equal footing, which is what "let a competitive market find the path" required all along. The matching engine goes back to being a market instead of a server.

Why this is the harder — and right — path

Vertically integrating a swap intent behind one orderbook is the easy build, which is why it's the common one. A modular, permissionless, gossip-fed system is more moving parts: interface design so modules actually compose, economic security so permissionless fillers stay solvent, and the operational reality that a p2p layer is fuzzier than a database you own. None of that is free.

But every one of those costs buys back something the pitch promised and the shipped products quietly dropped. Modular interfaces buy general intents instead of a swap template. Economic security buys permissionless cross-chain instead of a whitelist. A decentralized message layer buys neutral, censorship-resistant orderflow instead of a company endpoint that sees your trade first. The four problems aren't four separate fixes — they're one architectural stance applied consistently: make every part a module, let anyone provide any part, and never let discovery live on a single server.

One-sentence takeaway

Intents shipped as signed swaps, routed through one company's orderbook, filled by a permissioned set — and the way out of all three is the same move: a modular, permissionless solver system whose orderflow lives on a decentralized message layer like Waku, so the set of expressible intents, eligible solvers, and settlement venues is open-ended by construction.

Where to go next

• Waku — the decentralized messaging protocol, its node types, and content-topic model.
• ERC-7683 — an emerging cross-chain intents standard, and a sign the order format itself is starting to modularize.
• CoW Protocol docs · UniswapX · 1inch Fusion — the current-generation systems this piece measures against.