Two ways to build on Mayflower EVM

The Mayflower EVM package is live. The AVM gives every market a guaranteed floor price by holding a reserve that covers the full price curve at all times. It now ships as published npm packages, with a local development harness, generated Solidity interface references, and two quick-start guides on mayflower.systems.

There are two guides: create your own market, and build on a listed one. Which you need depends on where your market comes from. Building a launchpad? Run the first guide, then the second, because creating a market is only half the job and the second guide is where trading, borrowing, and product live. Building a treasury tool on a market that already exists? Skip straight to the second. The first guide is a prequel for teams that operate markets, not a prerequisite for building on them. This post walks through both.

The packages

Four packages cover the surface:

• @mayflower-sys/evm-avm-sdk packs issuance, redemption, and market-creation calls into { to, data } payloads. It never touches the network itself. You send the payloads with viem, which means the SDK slots into whatever transport, signer, or account abstraction setup your app already uses.
• @mayflower-sys/evm-avm-interfaces-gen provides generated viem bindings for the full on-chain interface surface: snapshots, collateral, floor raises, and the borrow path.
• @mayflower-sys/avm-calc is a client-side calculator. Hydrate it from on-chain market state and it quotes issuance and redemption locally, to roughly 0.1% relative accuracy, without a quoter contract round-trip. On-chain settlement stays authoritative.
• @mayflower-sys/evm-avm-client-demo ships a preloaded anvil node with a golden state: a fully wired AVM deployment, one provisioned tenant, and a manifest of contract addresses. One command and you have a complete Mayflower deployment running on localhost.

Local development works today against the anvil harness. Hosted, testnet, and mainnet deployments will publish under the Addresses page as they go live, with tenants provisioned through Mayflower onboarding.

Path one: create your own Mayflower market

This path is for teams building launchpads, treasuries, or white-label market products. You operate markets rather than just consuming them.

Every EVM deployment follows one topology: Tenant → MarketGroup → Market. A tenant admin opens market groups. Each group carries a fee schedule that every market under it inherits, with each fee leg capped at 10% on-chain. A group admin, a wallet the tenant designates per group, creates markets and collects group revenue.

Market creation takes a reserve asset and a pricing curve. The reserve is an ERC-20 your users already hold, though fee-on-transfer tokens are not supported. The new market inherits its decimals for AVM and option tokens. The pricing engine that ships end-to-end today is the linear curve, configured with five parameters at creation: slope, starting floor, ramp scalar, ramp end supply, and ramp width. Together these define how marginal price rises with supply and where the guaranteed floor sits underneath it. The math is documented in The Assured Value Machine.

Then comes the part that separates an AVM market from every other bonding-curve design: raising the floor.

Floor raising is not permissionless. Only the active group admin can call raiseFloorFromExcessLiquidity or raiseFloorPreserveArea, and both require a strictly increasing floor price. Anyone can donate reserve into a market with donateLiquidity, but donation alone moves nothing; the admin must execute the raise. In practice this is an internal operation, run by a bot or an admin dashboard rather than exposed to end users. The quick start walks through the full loop locally: buy, donate, then consume the surplus in a floor raise.

The result after the guide: a market group under your tenant, a linear market with your chosen reserve and curve, a TypeScript frontend reading live curve state, and a working floor-raise flow. Read the operator guide.

Path two: build on a listed Mayflower market

This path is for building on any market that exists: vaults, portfolio tools, yield strategies, consumer apps, or the frontend for a market you just created in path one. It is market-agnostic. You need a market address and nothing else, and it does not matter whether you deployed that market or someone else did.

The guide builds a vanilla React app step by step, and the shape of the integration is straightforward:

1. Read. One batched helper pulls snapshot(), state(), and netIssuedSupply(): price, floor, flags, balances, and everything the quote step needs.
2. Quote. Hydrate avm-calc from that state and quote reserve in to AVM out locally, applying the group buy fee on top. Users see accurate previews before any wallet prompt opens.
3. Issue and redeem. Approve the ERC-20 pull, then send the SDK’s packed issuance or redemption call. Redemption burns AVM the holder already owns.
4. Cash advance. Pledge AVM as collateral with depositCollateral, then draw reserve against the floor with borrow. On-chain the action is named borrow. In product copy, cash advance is the better frame: zero interest, non-recourse, capacity tied to the floor. Draw capacity is bounded by collateral valued at the floor price, and the floor cannot fall.

The guide closes with an error-handling checklist covering the failure modes builders actually hit (allowances, stale quotes, disabled flags, borrow capacity) and an optional Tailwind theme that styles the whole app in Mayflower tokens. Read the integration guide.

Beyond the quick starts

The interface reference holds more than the two guides cover. Three pieces stand out for anyone evaluating the surface at contract level.

Floor-strike options. Markets can carry call-option tokens struck at the floor. The exercise fee prices the premium, current price minus floor, so the fee is zero when the market sits at its floor and only the strike enters liquidity.

Atomic leverage. ILeveragedPositionManagement composes a cash advance and a spot trade into one transaction. Expand a position by opening debt and buying collateral in a single call, or shrink by selling collateral, repaying debt, and receiving the residual, with slippage bounds on every leg.

Quotes that cannot drift. The quoter and the market-actions implementation ship in one artifact and rotate together, so the price a UI quotes and the price the chain executes cannot diverge across an upgrade. Market addresses are also deterministic: CREATE2 with the market id as salt, predictable via predictMarketAddress before deployment.

Why the split matters

Most protocol integrations blur the operator and the consumer into one surface, and both suffer for it. The Mayflower EVM package separates them cleanly at the permission level. Operator surfaces carry tenancy, fee schedules, curve configuration, and floor management. Consumer surfaces carry reads, quotes, issuance, redemption, and cash advances against any listed market, with no operator permissions required. The same team often sits on both sides of that line: a launchpad creates markets through the admin surface and serves its users through the permissionless one.

The same separation shows up in the reference material. The interface reference publishes the full ABI surface with NatSpec and cross-linked types, from IAvmFactory and IMarket down to the pricing-curve and fee-policy libraries. Everything a contract-level integrator needs to verify behavior is on the page.

Start building

With Foundry installed and anvil on your PATH, install the packages and start the local node, and you are working against a complete AVM deployment in minutes:

npm install @mayflower-sys/evm-avm-sdk @mayflower-sys/evm-avm-interfaces-gen viem
npm install --save-dev @mayflower-sys/evm-avm-client-demo tsx
npx tsx node_modules/@mayflower-sys/evm-avm-client-demo/scripts/start-anvil.ts

Pick your path at mayflower.systems/integrate/evm. Testnet and mainnet addresses publish as deployments go live. Teams that want a provisioned tenant on a public network can reach the team through Mayflower onboarding.