[FEATURE] Automation: Volume-based triggers for DEX pools #330
Conversation
|
Warning Review limit reached
Next review available in: 22 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (10)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Implements volume-based automation triggers for Stellar DEX liquidity
pools, allowing the automation engine to fire when a pool's rolling 24-hour
trade volume exceeds a configurable threshold (roadmap item #48, issue #303).
Closes #303.
Files
packages/core/automation/src/triggers/volume-trigger.ts— trigger + typespackages/core/automation/src/test/volume-trigger.test.ts— unit testsDesign
API surface (matches issue spec)
trackPoolVolumereturnsbooleanas specified.checkreturns the fullVolumeCheckResultwithvolume24h,tradeCount,threshold,triggered,and
checkedAtfor callers that need observability beyond a boolean signal.Volume computation
Horizon has no single "pool volume" endpoint. Volume is derived by:
/trades?liquidity_pool_id={poolId}&trade_type=liquidity_pool&order=desc&limit=200Date.now() - windowMs, default 24 h)base_amountacross all matching tradestrade_type=liquidity_poolensures only AMM trades are counted — orderbooktrades that happen to involve the same assets are excluded.
Threshold semantics
Strictly greater-than (
volume > threshold) — matching the issue's "exceeds"wording. A volume equal to the threshold does not trigger.
Dependency injection
HorizonFetcheris the only external I/O boundary. ADefaultHorizonFetcherwraps the real
fetchAPI for production. Tests inject ajest.fn()mock —no global patching needed. This mirrors the pattern used by
PriceTrigger(injectable
OracleAggregator) andEventTrigger(injectableContractEventMonitor).Input validation
threshold24hmust be a non-negative numeric string — throws otherwisepoolIdmust be a non-empty, non-whitespace string — throws otherwisebase_amountvalues in Horizon responses are skippedgracefully (treated as 0) rather than throwing
Tests
All tests use
jest.useFakeTimers()+jest.setSystemTime()fordeterministic rolling-window boundary assertions.
Acceptance criteria
/trades?liquidity_pool_id=…&trade_type=liquidity_poolthreshold to return
trueHorizonFetcheris injectable for testingand future protocol changes
PriceTrigger,EventTrigger) in the same package