Endpoint Details
Mobula now provides two dedicated WSS endpoints Why? Because EVM and Solana work very differently under the hood. If we tried to send both through a single WebSocket channel, things would get messy:- The event queue would get backed up under heavy traffic
- Messages would arrive slower or even drop
- Scaling would be harder since both ecosystems compete for the same resources
- Faster and more reliable streams
- Independent scaling (EVM traffic won’t affect Solana, and vice-versa)
- Stable event delivery, even when network activity spikes
EVM Chains
- Endpoint:
wss://stream-evm-prod.mobula.io/ - Supported events:
swap,transfer,swap-enriched - Subscription Payload:
The EVM address in the filters must be lowercase.
SVM Chains
- Endpoint:
wss://stream-sol-prod.mobula.io/ - Supported events:
swap,transfer,swap-enriched - Subscription Payload:
Perpetuals (Perps) Chains
- Endpoint:
wss://stream-perps-prod.mobula.io/ - Supported events:
order - Supported chains:
lighter:301,lighter:304,evm:42161(Arbitrum for Gains Network)
order event captures perpetual trading activity including market orders, liquidations, limit orders, take profits, and stop losses. See the Perps Data Model for full field reference.
Subscription Payload:
MARKET_BUY- Market buy ordersMARKET_SELL- Market sell ordersLIQUIDATION- Liquidated positionsLIMIT_BUY- Limit buy ordersLIMIT_SELL- Limit sell ordersTAKE_PROFIT- Take profit executionsSTOP_LOSS- Stop loss executionsUPDATE_TP- Take profit updatesUPDATE_SL- Stop loss updates
Usage Examples
Before diving into the examples, make sure to check the data models:- EVM Data Model - Blocks, transactions, logs, traces, transfers
- Solana Data Model - Solana-specific events
- Perps Data Model - Perpetual orders, liquidations
- Curated Data Model - Enriched swaps and transfers
Pro Tip for Devs: Dive into these data models and experiment with filters — your imagination is the only limit! Mix
and / or, combine keys, and watch your streams come alive!- Explore
poolType,poolAddress,transactionFrom,transactionTo, and other keys in the data models. - Combine multiple conditions using
and/oroperators to capture exactly the events you want. - Mix and match filters across swaps and transfers to suit your application needs.
Filter Swaps by Pools
This stream captures all swaps from eitherraydium or raydium-clmm pools.
Filter Swap-Enriched by Pools
This stream captures allswap-enriched events from either raydium or raydium-clmm pools. The returned data is enriched, including:
- Derived swap view
- Base and quote token details
- Token metadata
Filter Transfer by Contract Address
This stream captures all swaps for a specificpoolAddress and poolType.
Filter Transfers by Sender
This stream captures all transfers sent to a specificaddress.
Filter Transfers From Sender and Receiver
This stream captures all transfers sent from or received by specificaddresses.
Filter Swaps by Pool Address (Batch)
This stream listens for all swap events associated with one or more specificpoolAddress values.
- Using the
"in"filter lets you efficiently capture swaps where thepoolAddressmatches any address in your provided list. - You can also apply similar logic to other fields such as
from,to, orpoolType— depending on what aspect of the swap you want to track.
Filter Swaps by Pool Type and Sender Address
This stream tracks all swap events that match specificpoolType values and originate from one or more given swapSenderAddress values.It’s perfect if you want to monitor swap activity from certain wallets while limiting results to specific pool categories (like Uniswap pools). By combining
"in" filters inside an "and" block, you can precisely define your tracking logic:
- Only capture swaps from specific wallet addresses
- AND make sure they belong to one of your target DEX pool types
Filter Perps by Order Type (Liquidations)
This stream captures all liquidation events from Lighter perpetuals.Filter Perps by Exchange
This stream captures all perpetual orders from a specific exchange.Filter Large Market Orders
This stream captures market buy and sell orders - useful for whale watching.Parameters
chainIds(required): Array of blockchain identifiers - See supported chainsevents(required): Array of event types -swap,transfer,swap-enriched,order(perps)filters(optional): Filter conditions for events - See filter documentationsubscriptionId(optional): Unique identifier for your WebSocket connection. Auto-generated if not providedsubscriptionTracking(optional, default:false): Include subscription details in response logs for debugging
Implementation Example
Connection Keepalive (Ping/Pong)
To maintain active WebSocket connections and prevent timeouts, you can use the ping/pong mechanism: Send ping:Unsubscribing from the Stream
Unsubscribe from All Streams
To terminate all active subscriptions on the current WebSocket connection:Unsubscribe from Specific Subscription
To unsubscribe from a specific subscription using its ID:If you didn’t provide a
subscriptionId when subscribing, one is auto-generated. To retrieve it, set "subscriptionTracking": true in the subscription payload.