Become a Market Maker

Step-by-step guide to running a market maker solver on NEAR Intents

Market makers on NEAR Intents are solvers — programs that listen for swap requests, decide whether to fill them, and respond with signed quotes. In this guide, you will set up and run an example solver that connects to the Message Bus, receives live quote requests, and automatically responds to the ones it can fill.

By the end, you will have a working solver running locally and a clear understanding of how to customize it.

Prerequisites

• Node.js v20.18+ with npm
• A NEAR mainnet account
• Liquidity in the Verifier contract (intents.near)
• Basic familiarity with WebSockets and the NEAR account model

---

How it works

When a user wants to swap tokens, they will send a quote request to the Message Bus — a WebSocket-based relay that broadcasts the request to all connected solvers.

The solver evaluates whether the request matches the configured token pair and whether sufficient liquidity is available. If both conditions are met, it calculates a price, signs an intent with the proposed amounts, and sends a quote response back to the Message Bus.

Multiple solvers compete for the same request by offering prices. The Message Bus collects the responses and returns top quotes to the user application. If a quote is selected, it is transmitted to the Verifier contract where the swap settles on-chain.

For a deeper look at this architecture, see the Market Makers introduction and the Message Bus overview.

The following steps show this flow in action.

Run the example solver

The AMM Solver example is a Node.js application that implements everything described above. It uses a simple constant-product AMM formula to price quotes — the same model used by Uniswap-style DEXs.

1. Clone the repository

   git clone https://github.com/defuse-protocol/near-intents-amm-solver.git
   cd near-intents-amm-solver
   npm install
   
2. Configure your environment

   Create your environment file from the provided example:

   cp env/.env.example env/.env.local
   

   Open env/.env.local and fill in these values:

   # Your NEAR account credentials
   NEAR_ACCOUNT_ID=your-solver.near
   NEAR_PRIVATE_KEY=ed25519:your_private_key_here
   
   # The token pair you want to market-make
   AMM_TOKEN1_ID=usdt.tether-token.near
   AMM_TOKEN2_ID=wrap.near
   
   # Network and mode
   NEAR_NETWORK_ID=mainnet
   TEE_ENABLED=false
   
   # Fee margin as a percentage (0.3 = 0.3%)
   MARGIN_PERCENT=0.3
   

   The MARGIN_PERCENT controls your spread — the difference between what you receive and what you give. A higher value means more profit per trade but fewer quotes accepted.

   Other settings like RELAY_WS_URL and INTENTS_CONTRACT have sensible defaults and do not need changing for most setups.

   Get a Message Bus API key:

   The default Message Bus WebSocket endpoint (wss://solver-relay-v2.chaindefuser.com/ws) requires an API key. To get one:

   1. Sign up at partners.near-intents.org
   2. Request an API key through the partner portal

   Once issued, open src/services/websocket-connection.service.ts and add your API key as a Bearer token in the WebSocket connection headers at line 35:

   headers: {
     Authorization: `Bearer ${YOUR_API_KEY}`,
   }
   

   Never commit your private key or API key to version control. The .env.local file is already in .gitignore, but double-check before pushing any changes.

3. Deposit liquidity

   Your solver can only fill swaps if it has token balances inside the Verifier contract (intents.near). You need to do two things: register your solver’s public key on the contract, and deposit tokens.

   Register your public key:

   npx near-cli-rs contract call-function as-transaction intents.near add_public_key \
     json-args '{"public_key":"ed25519:YOUR_PUBLIC_KEY"}' \
     prepaid-gas '100.0 Tgas' attached-deposit '1 yoctoNEAR' \
     sign-as SOLVER_ACCOUNT_ID network-config mainnet sign-with-keychain send
   

   Replace YOUR_PUBLIC_KEY with the public key that corresponds to the private key in your .env.local file, and SOLVER_ACCOUNT_ID with your actual NEAR account ID.

   Deposit tokens using one of these methods:

   • The Passive Deposit/Withdrawal Service — deposit from any supported chain via API
   • near-intents.org — a web interface for swapping and depositing tokens

   The solver needs balances for both tokens in the configured pair. For example, if you are market-making USDT/wNEAR, it needs both usdt.tether-token.near and wrap.near deposited into the contract.

4. Start the solver

   Since the environment file is named .env.local, set NODE_ENV=local so the app picks it up:

   NODE_ENV=local npm start
   

   On startup, the solver connects to the Message Bus WebSocket, subscribes to quote events, and begins polling the Verifier contract for current token balances every 15 seconds. Log output confirms the connection and initial reserves.

5. Verify it is working

   Check the health endpoint to confirm the solver is running:

   curl http://localhost:3000
   

   {"ready": true}
   

   In the logs, look for:

   • Connection confirmed — successful WebSocket connection to the Message Bus
   • Quote requests — incoming swap requests being evaluated
   • Quote responses — signed quotes being sent back for pairs your solver supports

   The solver only responds to requests for the configured token pair. If a request comes in for a different pair, or if reserves are too low to fill it, the solver skips it.

   If quote requests are not appearing, that is normal during low-activity periods. The solver sends responses when matching requests arrive.

Understanding the code

Now that the solver is running, the sections below describe what happens under the hood. The project is organized into focused services, each handling one part of the workflow.

Connecting to the Message Bus

The WebSocket connection service (src/services/websocket-connection.service.ts) manages the link to the Message Bus. On connect, it subscribes to two event types:

// Subscribe to incoming quote requests
this.subscribe(RelayEventKind.QUOTE);

// Subscribe to settlement notifications
this.subscribe(RelayEventKind.QUOTE_STATUS);

When a quote event arrives, the service checks whether the requested token pair matches the configured pair. If it does, it passes the request to the quoter service for evaluation.

Evaluating and responding to quotes

The quoter service (src/services/quoter.service.ts) is where the core decision-making happens. For each incoming request, it:

1. Validates the deadline — rejects requests with unreasonable timeframes
2. Checks reserves — looks up current balances for both tokens
3. Calculates the price — uses a constant-product AMM formula with the configured margin
4. Signs the response — creates a token_diff intent and signs it with the configured NEAR key

The AMM formula follows the classic x * y = k model:

// Calculate how many tokens the user receives for their input
getAmountOut(amountIn, reserveIn, reserveOut, marginBips) {
  const amountInWithFee = amountIn * (10000 - marginBips);
  return (amountInWithFee * reserveOut) / (reserveIn * 10000 + amountInWithFee);
}

If the calculated output exceeds available reserves, the solver skips the request — it does not quote what it cannot fill.

Keeping state fresh

The solver does not only check reserves once. A cron service (src/services/cron.service.ts) refreshes token balances from the Verifier contract every 15 seconds. After a successful trade, the solver updates its position and adjusts future quotes accordingly.

Making it your own

The example uses a constant-product AMM formula, but any pricing logic can be used. The quoter service is the place to start — replace the getAmountOut and getAmountIn functions with a custom strategy, whether that is pulling prices from external APIs, using order books, or applying custom spread models.

A few additional areas to customize:

• Support more token pairs — add additional token IDs in the configuration
• Add position limits — cap how much of a token the solver can allocate
• Implement risk controls — set minimum trade sizes, maximum exposure, or rate limits

The src/configs/ directory is a good starting point for customization. Each config file maps to a specific concern — tokens, margins, WebSocket URLs, and more.

For production deployments, consider running your solver in TEE (Trusted Execution Environment) mode, which provides additional security guarantees. See the repository README for TEE setup instructions.

Next steps

Message Bus API

Full reference for all WebSocket and JSON-RPC methods

Usage Examples

TypeScript patterns for signing intents and responding to quotes

Deposit & Withdrawal

Move liquidity in and out of the Verifier contract via API

Example Repository

Browse the full source code and contribute