> For the complete documentation index, see [llms.txt](https://docs.surgecardano.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.surgecardano.com/strategies/cadence-volume.md).

# Cadence (volume)

A Cadence strategy executes a pre-planned schedule of buys and sells of one token over 12, 24, 48 or 72 hours, spread across up to five of your strategy wallets. You set the total buy volume, the total sell volume and a trade-size range; Surge plans every order's size, time and wallet up front and then asks you to sign each one as it comes due.

Cadence is a **volume-executing** strategy. It does not read the market or take a view on price; its purpose is to put a specified amount of trading through a pool on a schedule. Its entire cost is fees and price impact, and it has no offsetting profit mechanism by design.

### What it is and when to use it

Use Cadence when you need a defined amount of buy and sell activity in a token over a defined period, with the trades spread out in time and distributed across several wallets. Set buy and sell totals equal if you want to end roughly where you started in token terms; the ADA difference will be the fees.

### How it works

**Planning (once, at creation).** Surge divides the duration into 30-minute windows (47 windows for 24 hours) and plans at most 10 orders per window, so a 24-hour schedule holds at most 470 orders. It then:

1. checks the request is feasible — both totals fit within the trade-size range and the order ceiling — and tells you which constraint binds if not;
2. splits each side's total into individual order sizes inside your min–max range that add up exactly to the total, shuffled;
3. interleaves buys and sells so neither side clumps, deals them into windows (about five per window, never more than ten), and shuffles within each window;
4. spaces the orders inside each window evenly (at least 3 minutes apart), starts the first window one minute after creation, and varies the gaps between windows;
5. assigns wallets round-robin: order 1 sends from wallet 1 to wallet 2, order 2 from wallet 2 to wallet 3, and so on around the ring, so each order's sender is the previous order's receiver. With one wallet every order sends to itself.

The plan is deterministic for a given configuration, which is why the **Required balance** preview matches the schedule that actually runs.

**Running (on Surge's servers, every 15 seconds).** When an order's time arrives and your tab is connected to the strategy, Surge builds the swap — including a sweep of the sending wallet's remaining funds to the receiving wallet — and pushes it to your tab. Rules:

* one order in flight per strategy at a time;
* a 2-minute settle pause after each submitted order so the wallet-to-wallet sweep can land;
* if the funds are not where the plan expected (because an earlier order failed or was skipped), the order's sender and receiver are re-pointed to where the funds actually are;
* an order waits **2 minutes** for your signature, then is released and retried later; you can also **Decline** it;
* a build failure is retried with growing delays (30 s, 60 s, 2 min …); after **5** failed attempts the order is marked failed and you get a warning email and notification;
* an order more than **30 minutes** past its scheduled time is **skipped** permanently;
* when every order is completed, skipped or failed, the strategy is marked **Completed**.

### Set up Cadence

| Field              | What it means                          | Default | Limits and guidance                                                                                                              |
| ------------------ | -------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Asset              | The token, against ADA                 | —       |                                                                                                                                  |
| Duration           | Length of the schedule                 | 24 h    | 12, 24, 48 or 72 hours                                                                                                           |
| Total buy (₳)      | ADA of buying to execute               | —       | 0 or more; at least one side must be non-zero                                                                                    |
| Total sell (₳)     | ADA-equivalent of selling to execute   | —       | 0 or more                                                                                                                        |
| Min trade size (₳) | Smallest single order                  | —       | At least 1; a non-zero side must be ≥ this                                                                                       |
| Max trade size (₳) | Largest single order                   | —       | ≥ min; the order ceiling × max must cover each side                                                                              |
| Wallets            | 1–5 strategy wallets to rotate through | —       | All must be yours, unique, on this network                                                                                       |
| DEX                | Venue                                  | Minswap | `[VERIFY: whether the builder lets you pick another DEX; the create request has no DEX field and the server default is Minswap]` |

**Preview** shows the estimated order count, seconds between orders, estimated fees, net ADA (buy total − sell total − fees) and orders per wallet. If the request is infeasible it returns zeros with the reason instead.

**Required balance** walks the actual schedule to find the peak ADA the ring will need at any moment (peak of cumulative buys minus sells) and adds fees, deposits for the orders that can be in flight at once, and the pool fee on the total; for the sell side it converts the peak into a token quantity. Fund the *first* wallet in the ring with that.

### While it runs

* The detail page shows the schedule (windows and orders), each order's status, the linked wallets and the trade log.
* Order statuses: **pending** (planned, not due or waiting for a slot), **awaiting signature** (built and pushed to your tab), **submitted** (on chain, outcome pending), **completed**, **skipped**, **failed** (with a reason).
* **Pause** and **Resume** are server-side and persist across browsers — the only strategy where this is true. A paused strategy dispatches nothing; orders keep ageing and are skipped past 30 minutes. `[VERIFY: after Resume, reopen or refresh the strategy page so your tab rejoins the strategy; otherwise orders may not be pushed.]`
* Because signing is required, if your tab is closed the orders age out and are skipped with no notification. Keep the tab open for the whole duration.

### Fees example

A 2,000 ADA programme (1,000 buy, 1,000 sell) with trade sizes 40–90 ADA, about 31 orders of \~65 ADA:

| Per order                          | On-chain cost                  | Shown in history             |
| ---------------------------------- | ------------------------------ | ---------------------------- |
| Surge fee 0.2% × 65                | 0.13 ADA                       | 0.978 ADA (recorded minimum) |
| Batcher fee (Minswap)              | 2.00 ADA                       | 2.00 ADA                     |
| Network fee                        | \~0.20 ADA                     | 0.20 ADA                     |
| Pool fee \~0.3% (inside the price) | \~0.20 ADA                     | —                            |
| Deposit                            | 2 ADA locked, returned on fill | —                            |

Over 31 orders: about **78 ADA** of real fees (≈ 98 ADA as recorded), plus price impact on every order in whichever direction the pool moves against you. With equal buy and sell totals the expected end state is roughly the same token position and about 78 ADA less. See [Fee breakdown](/fees-tiers-and-staking/fee-breakdown.md).

### Wallet interaction

Funds walk around the ring: each order's proceeds and change are delivered to the next wallet, which sends the following order. Your browser wallet only funds the first wallet. Fill detection watches the *receiving* wallet, since that is where the batcher pays. When the strategy completes, the funds sit in whichever wallet the last order paid; use Send or Sweep to consolidate.

### Edge cases and failure modes

* **You miss a signature while connected.** The order returns to pending with an attempt counted and is retried; five attempts fail it. With the tab closed nothing is sent for signing at all — orders simply age out and are skipped after 30 minutes.
* **An order fails to build.** Usually funds are not in the expected wallet; Surge realigns to where they are and retries.
* **An order parks (non-Minswap).** The schedule order shows *submitted* and, after about 30 minutes, *completed* — because its placing transaction is on chain — even though the swap has not executed. Use the trade log's fill status (Open) to see it is parked, and cancel it there. The settle pause and the one-in-flight rule mean the schedule stalls behind it meanwhile.
* **Chain rejects a submission.** The order is failed immediately.
* **Editing a running strategy.** Volumes, duration and bounds can be edited, but the existing schedule is **not** re-planned — the plan and the settings diverge. Prefer stopping and creating a new strategy.
* **Dense schedules.** At 10 orders per window the schedule allows 3 minutes per order and the settle pause uses 2 of them; slow signing makes the schedule fall behind and orders start being skipped.
* **Archiving.** Pause first (a running strategy cannot be archived); delete removes the schedule and its orders.

### FAQ

**Why were orders skipped?** They were more than 30 minutes past their time with no signature — almost always a closed tab or a stalled parked order.

**Why did the sender/receiver change from the plan?** A previous order failed or was skipped, so the funds were still in an earlier wallet; Surge re-pointed the order so the ring stays intact.

**Does Cadence make money?** No. Its expected result is the fee bill plus price impact. The strategy page's P\&L shows realized cash flow from filled orders only.

**Can I use one wallet?** Yes; then every order sends to itself and there is no rotation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.surgecardano.com/strategies/cadence-volume.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.