# Automations and sniping

Automations run against explicit owned wallets. Create them with a master key and an idempotency key, then monitor the returned state and any resulting trades.

## DCA and Pulse strategies

| Method | Path | Purpose |
| --- | --- | --- |
| `POST` | `/v1/trading-strategies` | Create one DCA or Pulse strategy |
| `GET` | `/v1/trading-strategies` | List strategies, optionally filtered by `walletId` |
| `POST` | `/v1/trading-strategies/dca/batch` | Create DCA buys for up to 30 wallets |
| `POST` | `/v1/trading-strategies/:strategyId/pause` | Pause a strategy |
| `POST` | `/v1/trading-strategies/:strategyId/resume` | Resume a paused strategy |
| `POST` | `/v1/trading-strategies/:strategyId/stop` | Stop a strategy |

A strategy binds `walletId`, `chain`, a token descriptor, `allowanceMicros`, `intervalSeconds`, and slippage. DCA buys use `amountPerCycleMicros`; DCA sells use `side: "sell"` with `amountPerCycleRaw` in the held token's native units. Pulse uses price-step and circuit-breaker percentages. Use the [OpenAPI schema](/openapi.json) for each request's fields.

States are `active`, `paused`, `completed`, and `stopped`. Inspect `pauseReason`, `lastAction`, `pendingTradeId`, and `consecutiveFailures` when available. Follow a pending trade through [Market trades](/docs/trades). A failed refresh does not mean that the strategy stopped.

DCA batch creation returns one outcome per wallet, with `status: "created"` and a strategy or `status: "failed"` and an error. Preserve the original body and idempotency key when recovering an interrupted request.

## Sniper rules

Create rules through `POST /v1/sniper-rules`, list them with `GET /v1/sniper-rules`, and cancel an eligible rule with `POST /v1/sniper-rules/:ruleId/cancel`.

A rule identifies the chain, a deployer or ticker target, optional launchpad, watch duration, slippage, and wallet allocations. Settlement-funded allocations use `amountMicros`; native-funded allocations use `amountRaw`. Keep `funding` and `feePayment` explicit when the payment source matters.

Read the returned versioned `feePolicy`. Sniper fees have their own policy and payment terms. `payPonsAntiSniperTax` explicitly opts into early Pons execution under its tax policy; inspect those terms before enabling it.

Each wallet uses its own transaction, including grouped snipes and automatic sells. Monitor allocation-level `state`, `tradeId`, `sellTradeId`, and `error` as well as the rule's overall state. A rule can finish as `partial_failed` when only some allocations succeed. Cancellation does not reverse an already submitted trade.

## Token launches

The deployment API supports Pons V2 launches. Read `GET /v1/deployments/pons-v2/terms` before constructing a launch. `POST /v1/deployments` includes the reviewed `expectedTerms` together with the wallet, token identity, pairing, and launch settings. If terms change, review the new terms before submitting another operation.

Use `GET /v1/deployments` and `GET /v1/deployments/:deploymentId` to follow the result. Asset upload and X-post lookup have separate endpoints in [OpenAPI](/openapi.json). Preserve the original deployment request and idempotency key while a launch is unresolved.