A wallet that wanted to support five bridges used to integrate five SDKs. Five fee oracles, five sets of error codes, five ideas about what "the transfer went through" means. Multiply that by every wallet and every app, and you get the state of cross-chain UX for most of the last five years: enormous duplicated effort spent on plumbing nobody wanted to think about.

Intents were the fix, and ERC-7683 is the standard that grew out of them. It is worth understanding what it did and did not solve, because the part it deliberately left alone is the part that decides whether your money arrives.

Short Version For Newcomers

An intent is a signed statement of what you want rather than how to get it. "I have 10,000 USDC on Arbitrum, I want USDC on Base, expire in five minutes". You sign that sentence. You do not pick a bridge, a route, or a relayer.

A solver is whoever reads that statement and makes it true. Solvers are off-chain actors, usually market makers running bots, who deliver the assets on the destination chain out of their own inventory and then claim payment from the origin chain. Competition between them is what gets you a good price.

The important structural detail: the solver fronts the capital and gets paid afterwards. Every risk that used to sit with the user, waiting to see whether a bridge delivered, now sits with the solver. That relocation is what makes the UX feel instant, and it is also where all the interesting problems went.

Five Bridges, Five Integrations

The fragmentation was never only a wallet problem. It hit solvers harder.

The standard's motivation section is blunt about the cost. Every solver has to integrate separately with each protocol's payload format, execution flow and payment semantics, and new protocols then struggle to attract competitive execution, because no existing solver can serve them without engineering work first.

So you get a market that looks competitive from the outside and is actually a set of walled gardens, each with its own small set of solvers, each quoting worse prices than it would if it could aggregate demand across all of them.

Standardizing Consumption, Not Settlement

ERC-7683 is still marked Draft, so what follows is where the specification stands rather than a description of any one deployment.

A protocol keeps its own order encoding, whatever that is, and publishes a resolver contract on-chain. A solver calls `resolve` on that resolver off-chain, through `eth_call`, and gets back a general-purpose description of the order: a list of steps to execute, variables it gets to choose (where it wants to be paid, on which chain), the payments it will receive, and a list of named assumptions the resolver can’t verify on its own.

Resolution happens off-chain, so the translation is not constrained by gas costs. A resolver can do rich, complicated decoding work that would be unaffordable inside a transaction.

The resolver is explicitly the point of trust. Solvers whitelist resolver addresses they have vetted through audits and time, and once vetted, they follow its instructions without needing to understand the protocol behind it. The standard's phrase for the goal is programmable solvers: add support for a new protocol by reviewing its resolver, not by writing an integration.

Whose Finality Are You Trusting

How does the origin chain learn that a fill happened on the destination chain? ERC-7683 does not say. Across uses an optimistic oracle. UniswapX uses off-chain attestations. You could use a validity proof. The standard is agnostic, which means the trust assumption behind any given transfer belongs to the settlement contract and the messaging layer underneath it, not to the standard. Two transfers can be equally ERC-7683-compliant and have nothing in common in terms of what could go wrong.

The security considerations are refreshingly direct about where that lands.

Notice where the window starts. Not when the order appears, but when the solver spends its own money on the strength of it. The solver looks at an event on the origin chain, decides it is real, and delivers on the destination chain. If the origin chain reorgs that event away, the solver has handed over goods against a payment instruction that no longer exists. Nobody at the standards layer can fix this, because it is not a formatting problem. It is a question about which chain's version of history you are willing to act on before that history is settled. 

The standard handles it the only honest way available: it makes the assumption explicit. Conditions a resolver cannot verify get surfaced as named assumptions that the solver must validate before filling. Payments carry an `estimatedDelaySeconds` field, so the expected wait until money is actually spendable is part of the order rather than folklore. That does not remove the risk. It writes it down, which is a real improvement over five SDKs with five undocumented opinions.

Same Trade, Made Once

Reactive contracts react to events on other chains, which means our sequencer faces the solver's question on every single event it observes: act now on something that looks true, or wait for the origin chain to be certain. Our answer is a distinction we call origin finality. An event observed on an origin chain is treated as canonical for the purpose of triggering reactive logic, even if that origin chain later reorganises and unwinds it. That is a deliberate trade, made once at the protocol level and documented, rather than left to each application to rediscover.

A solver makes the same bet per order, priced into its spread and managed by its own risk model. We make it once, in the open, as a property of the network. Neither approach is obviously right.

The vocabulary is converging too. ERC-7683 gives solvers a way to read origin-chain logs, returning each one as a struct of emitter, topics, data, block number, transaction hash and log index. Anyone who has written a reactive contract will recognise that shape immediately, because it is nearly our own log record. When two designs converge on the same data structure without coordinating, it is usually because the underlying problem has only one sensible decomposition. Which raises the question worth sitting with: if everyone building across chains eventually needs a name for "true enough to act on", should that be a per-protocol choice, or the next thing somebody tries to standardize?

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts — event-driven smart contracts for cross-chain execution. It runs on CometBFT consensus, providing deterministic finality with roughly one-second block times while maintaining full EVM compatibility. Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, issuing cross-chain callback transactions when their conditions are met.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!