Mayan

• Name: Mayan
• URL: https://mayan.finance/
• Tags: ethereum-ecosystem solana-ecosystem
• Category: cross-chain route seller / bridge-and-swap wrapper / intent-execution middleware
• Summary: Mayan is a fast route seller over a few deeper rails, not a bridge-security anchor. The useful read is simple: it packages Swift fills, Circle CCTP transfers, and Wormhole-based paths behind one branded quote surface. The real control surface is driver admission, route selection, fallback handling, and what the product decides to show or hide.
• What it does:
  • Provides a consumer app and developer tooling for swapping or bridging assets across Solana and multiple EVM networks
  • Supports three documented transfer methods: Swift for intent-style fast fills, MCTP for Circle CCTP-based stablecoin transfers, and Wormhole Swap for selected asset routes built on Wormhole primitives
  • Runs an onchain auction model in which drivers compete to offer users the best quoted execution rate for cross-chain transfers
  • Exposes SDK, widget, quote and explorer APIs, referral tooling, gas-on-destination support, and explorer surfaces for integrators
  • Publishes security and audit materials covering core contracts and route variants such as MCTP and Swift
• Key claims:
  • Official docs present Mayan as an execution and routing layer with large reported volume and wallet counts, which is why this note belongs with cross-chain packaging and route policy rather than with bridge-verification anchors.
  • The auction docs describe a transparent onchain Solana auction where drivers compete over roughly a three-second English-auction window to offer the best quoted rate.
  • Swift is the main mechanism to understand. The docs describe an intent-style flow where the winning driver fulfills on the destination chain from inventory it already holds there, then uses a receipt to unlock the source-side assets.
  • The Swift docs also make product drift and integration policy visible: Swift v1 is being deprecated in favor of Swift v2, so the live routing surface is not static.
  • Driver admission is not permissionless in practice. The docs tell would-be drivers to request access through a Discord support ticket and note that applications are reviewed case by case.
  • MCTP and Wormhole Swap make the analytical point clearer: Mayan is often a wrapper around deeper rails rather than the rail users should treat as the final trust model.
  • Security claims about trustless contracts do not remove the practical routing question. Users still inherit Mayan’s choices about which path gets exposed, when Swift is preferred over MCTP or Wormhole routes, and how refund or fallback behavior is handled.
  • The note is strongest when it stays on that packaging layer instead of treating Mayan like a canonical interoperability primitive.
• Whitepaper: No classic whitepaper or litepaper was found during this pass. The strongest primary materials were Mayan’s documentation set, architecture pages, audits page, and public GitHub organization; see ../whitepapers/mayan-primary-sources-2026-04-25.md.
• Sources:
  • https://mayan.finance/
  • https://docs.mayan.finance/
  • https://docs.mayan.finance/llms.txt
  • https://docs.mayan.finance/architecture/auction
  • https://docs.mayan.finance/architecture/swift
  • https://docs.mayan.finance/resources/audits
  • https://github.com/mayan-finance

Internal linkages

• Best upward read for routing-and-defaults power: across.
• Settlement-rail contrast worth keeping nearby: cctp.
• Do not spend more graph budget pretending Mayan is a canonical bridge-security anchor.

Control surface

• The leverage is in driver admission, auction design, route exposure across Swift versus MCTP versus Wormhole paths, gas-on-destination packaging, and fallback or refund behavior.

• Read Mayan as a route seller with some real auction machinery, not as the trust anchor beneath the transfer.

• Last reviewed: 2026-06-14 UTC