Skip to main content

​
Returns

​
MakerEventConnection
See MakerEventConnection

​
Arguments

​
Int
The maximum number of events to return.
​
MakerEventsQueryInput!
required
The query filters to apply to the results. See MakerEventsQueryInput
​
String
The cursor to use for pagination.
​
RankingDirection
The order to receive the token events. Can be DESC (default) or ASC. See RankingDirection

​
Example

Test this query in the Explorer →

​
Usage Guidelines

  • Specify a desired eventType (eg: Swap, Mint, Burn, etc.) to suit your needs on any supported network and timeframe
  • Narrow results by specific network, token address, and combine with filters such as priceUsdTotal for more targeted results.
  • To fetch all trades for a wallet on a specific token, pass maker plus tokenAddress in query — no timestamp range is required.
  • Set limit: 200 (the maximum) when you want complete results over an open-ended range. The default is 10, and because results are paginated through database slices, a page may return fewer items than your limit even when more exist — a low limit can force many near-empty cursor calls. Smaller or default limits work fine when you scope the query with a tight timestamp range.
  • Note: Token transfer events are not supported
  • Multi-hop transactions will show each intermediate transaction separately (see troubleshooting tip below for details)

​
Troubleshooting Tips

No — the cursor pages through the database in slices, so a single page can return fewer items than limit even when more results exist. Keep requesting with the returned cursor until it comes back null to collect everything. To minimize round trips over an open-ended query, set limit: 200 (the maximum — higher values return an error): a wallet with 15 trades returns in one response at limit: 200, but can take ~10 cursor calls at the default limit of 10. If you’re querying a finely scoped timestamp range, smaller limits are fine since there are fewer slices to walk.
Yes this is expected behavior for a multi-hop transaction, where a maker will initiate a transaction from Token A -> Token B -> Token C, for example. We understand that Token B is likely of zero interest, however, it is still a legitimate transaction that we must index. Using the transaction hash to disambiguate on the client side is really the only way to attempt to simplify the swap down to just Token A -> Token C.
The transaction most likely occured on a protocol that we do not support. While we endeavor to support as many dexes as possible, including thousands of Uniswap forks, there are some we may not have yet. You can reach out to our team to inquire about specific exchanges you would like to see supported in a future update.
Look at the signs of amount0 and amount1 in the data field:
Negative amount = Token received (bought)
Positive amount = Token spent (sold)This rule is consistent for ALL transactions:
Positive = what they gave up (OUT of wallet)
Negative = what they received (INTO wallet)The eventDisplayType “Buy”/“Sell” indicates the primary action from the user’s perspective (buying or selling the non-native token), while the amount signs show the actual token flows.
  • Events: Build a token swap list with filtering, pagination, and real-time updates
  • Wallets: Analyze wallet performance, discover top traders, and build portfolio views