When users make a cross-chain swap, they are usually optimizing for two things: price and speed. They want to minimize fees and reach the destination chain quickly.
Delivering both depends on a few core design decisions: how a swap is specified, who executes it, what happens to funds during that process, and how the system confirms each step before moving to the next.
Not all cross-chain bridges are built the same way. This piece is about how Mayan works and the design choices that shaped it.
1. Intent-based execution
On Mayan, the user defines the outcome up front: which asset they are sending, which chain they are moving to, which token they want to receive, and the minimum amount they are willing to accept. That minimum is part of the instruction, and the swap only executes if those conditions are met.
Once the intent is submitted, independent parties called solvers compete to fill it.
Solvers are typically trading firms or automated systems that use their own capital to deliver the requested tokens to the user on the destination chain, earning a fee for doing so. Each order goes to the best competing bid, not a price set by a single intermediary.
What this means: every swap on Mayan is a live auction. The market competes to win your order, and that competition is what drives pricing in your favor and keeps quotes precise.
2. The solver takes the risk
Once a user submits a swap, a solver steps in to fulfill it.
The solver delivers the requested assets to the user on the destination chain first. The solver can only unlock the corresponding funds on the origin chain after delivery of the tokens has been verified through the protocol.
That ordering is very important. The solver is the party taking on the re-org risk on the source chain while the swap is in progress. At no time during a swap is Mayan taking effective custody of funds. The solver takes on the risk of fulling transfers across chains.
This is one of the core mechanics behind Mayan. The solver coordinating the swap is also the party exposed until delivery has been verified.
What this means: When an intent is fulfilled, the user receives their tokens first. The solver later redeems funds they used to fulfill the transfer when the source chain reaches finality. The re-org risk sits with the solver, not the user.
3. Every swap runs through open, audited contracts
Mayan is not an interface sitting on top of opaque fund movement.
The smart contracts on the source and destination chains handle each swap, connected through @Wormhole message passing so delivery on one side can be verified before funds are released on the other.
Every cross-chain message is attested by Wormhole's Guardian network. 13 of 19 independent organizations running separate infrastructure globally must sign off before a message is considered valid.
That makes the execution model easier to inspect and reason about. The contracts are public. The audits are public. The transaction flow is visible onchain and through Mayan Explorer.
For users and partners, this matters. The core Mayan protocol is not a black box.
What this means: the swap is executed through public, auditable contracts, not through undisclosed infrastructure behind the scenes.
Smart contract audits by OtterSec and Sec3: docs.mayan.finance/resources/audits
4. No hidden custody
One of the most important differences between cross-chain systems is what happens to user funds during execution.
In some cases, providers take custody of user funds behind the scenes. In others, execution depends on centralized exchanges or other offchain operators moving funds before the user receives the final asset.
That can produce a fast result, but it also changes the trust model.
Those trade-offs may be acceptable if they are made explicit. The problem is when they are not.
We chose not to build Mayan that way.
Mayan is built around onchain contracts, protocol-level verification, and an execution model that is visible to users and partners. The goal is straightforward: the system should remain transparent underneath the interface.
What this means: Mayan is not built on hidden custody or offchain fund movement that users and partners cannot inspect.
5. Built to be inspected
Cross-chain products are often simpler to use than they are to evaluate.
We think that should change.
Users should be able to understand the system they are using. Partners should be able to assess the system they are integrating. That is especially important in cross-chain, where the mechanics of execution are often more important than the interface suggests.
That is why Mayan is built around public contracts, public audits, and visible transaction flow.
What this means: Mayan is built to be verified, not simply taken on trust.
What these decisions add up to
Users care about price and speed. Those are the outcomes. The harder question is what kind of system produces them.
At Mayan, that has meant building around:
user-defined execution
solver-based fulfillment
audited contracts on both sides of the swap
cross-chain verification before funds are released
no hidden custody or unverifiable fund movement
public visibility for how each swap completes
The tradeoffs are real. Building around a competitive solver network is harder than routing through a single execution provider. Designing for inspectability takes longer than shipping fast and opaque.
We made those choices deliberately. In a moment when cross-chain infrastructure is under close scrutiny, being verifiable has become as valuable as being fast. We have consistently declined to trade user visibility and system integrity for a faster build. What people call a bridge, we built as an intent-based execution layer.
Across $18B+ in volume, 8M+ swaps, and 2.5M+ users inside crypto's most widely used apps, these choices have held.
We are glad to be at the forefront of cross-chain infrastructure and are confident in the foundation we built to get here.