Levandor

OPEN: multi-wallet liquidity ceiling for copy-trading (brainstorm topic)

12 min read

OPEN brainstorm topic — pick up fresh later

This note is a self-contained starting point for a future brainstorm, not a resolved decision. It captures a strategic/design ceiling we hit while running copy-trading across multiple wallets. We shipped a v1 mitigation (staggered priority tiers) that orders who fires first, but it does not raise the underlying ceiling. The real question — how do we scale client wallets past the per-market liquidity ceiling? — is left open below in the Brainstorm Agenda.

The PM copy-trades the SAME crypto strategy across N wallets into the same thin Polymarket CLOB books. Book depth — not wallet count — caps how many wallets can profitably fill on a given signal. Onboarding more client wallets does not yield proportional fills. This directly constrains the fee/MLM plan.

The Core Issue — Fan-Out Cannibalization

PM uses a fan-out architecture (see pmv2-multi-signer-wallet-2026-07-01): each wallet runs its own durable NATS consumer (pmv2_orders_<wallet_id>, distinct durable name = true fan-out, not a shared queue group). Every wallet receives every entry signal and independently fires a FAK (“fill-and-kill”) buy into the same order book.

When multiple wallets are live, they process the same signal into the same thin book simultaneously and cannibalize each other:

  1. The first wallet’s FAK consumes the available ask-side liquidity.
  2. The remaining wallets hit an already-exhausted book.
  3. They no-match, then grind 2 re-priced FAK retries (see pmv2-fak-no-match-reject-single-line-2026-06-30 and crypto’s crypto-shortterm-fak-nomatch-root-cause-2026-07-02).
  4. They fail → RecordedFailure("other").

Why the error is "other"

The FAK no-match error string is not a recognized class, so it falls through classify_error to "other". A run showing heavy RecordedFailure("other") with the pattern “first wallet Placed, later 2-3 fail” is the signature of this adverse-selection FAK cannibalization — not a generic venue error.

Confirmed on deploy (2026-07-08)

Deploy verified this on-chain and in logs:

  • 4.5× fan-out multiplier observed (each signal fanned out to all live wallets).
  • NO CLOB rate-limiting — 0× HTTP 429s. This was not a rate-limit problem.
  • Heavy RecordedFailure("other") with the “first wallet Placed, later 2-3 fail” pattern = classic adverse-selection FAK.

The perceived symptom was misdiagnosed at first

“PM is slower with 4 wallets” was NOT latency and NOT rate-limiting. It was the wallets fighting over the same few contracts in a thin book. The fan-out was racing itself.

What We Shipped as v1 — Priority Tiers (a MITIGATION, not a solution)

Branch feat/wallet-priority-tiers. Spec docs/superpowers/specs/2026-07-09-multi-wallet-priority-tiers-design.md, plan docs/superpowers/plans/2026-07-09-multi-wallet-priority-tiers.md.

Design: staggered-fire priority tiers.

  • New per-wallet priority column (hot-read).
  • A wallet’s fire is delayed by (priority - 1) * ~400ms.
  • Tier 1 = wallet1 (bandi) / wallet2 (balu) → fire immediately (zero-delay short-circuit, latency guaranteed unchanged).
  • Tier 2 = wallet3 (levi) / wallet4 (gyula) → fire ~400ms later so they take the leftover book instead of racing tier 1.

What it does: it orders who gets first crack at the book and stops the wasted simultaneous racing. Tier-1 latency is provably untouched (zero-delay branch short-circuits before any sleep).

What it does NOT do: it does not beat the underlying liquidity ceiling. If tier 1 empties the book, tier 2 still under-fills — staggering just makes that rarer and stops the wasted contention, it does not create liquidity that isn’t there.

The Deeper Unresolved Issue (the actual brainstorm)

Running the identical strategy across N wallets on the same thin crypto books means book depth caps how many wallets can profitably fill on a given signal — often only ~1-2.

  • Adding more client wallets does NOT yield proportional fills.
  • There is a HARD liquidity capacity limit set by book depth, not by how many wallets you onboard.
  • Later / lower-priority wallets will systematically under-fill.

This constrains the fee / MLM plan directly

The per-wallet fee_rate work and the fee-accounting engine (spec 2026-07-08-pmv2-fee-accounting-engine) assume you can onboard client wallets (levi, gyula, and future MLM downline) and have each mirror the strategy’s returns. You cannot just onboard unlimited client wallets into the same thin markets and expect each to mirror returns — lower-priority wallets will fill less and thus realize different PnL. The fee model may need a capacity notion (a max billable wallets per market/strategy).

Brainstorm Agenda

The open agenda for the fresh brainstorm. None of these candidate directions have been evaluated yet — they are the menu, not a recommendation.

1. How do we scale client wallets past the per-market liquidity ceiling?

Candidate directions (unevaluated):

  • (a) Coordinate fills — one book fetch, split available liquidity across wallets size-aware (instead of each wallet independently racing the same book).
  • (b) Partition signals/sources across wallets — route different signals/sources to different wallets so they aren’t all in the same book at the same instant.
  • (c) Diversify into more markets/sources — spread N wallets across more books so the aggregate liquidity ceiling scales with market count, not wallet count.
  • (d) Size-aware or rotation-based fairness — rotate which wallet gets first crack, or size each wallet’s fill to the depth available, so under-fill is shared rather than always hitting the lowest tier.
  • (e) Accept a hard client cap per strategy/market — and price the fee model around it (explicit capacity limit).

2. Interaction with crypto’s signal/source design + the tiering we just shipped

3. Fairness / economics

  • Lower-priority (client) wallets systematically fill less → their PnL, and thus their 20% performance fee, differ from tier-1.
  • Is that acceptable? How is it communicated to clients (levi, gyula, MLM downline)?
  • Do clients expect to mirror the strategy 1:1? If so, the ceiling breaks that promise for later tiers.

4. Does the fee model need a “capacity” notion?

  • A max billable wallets per market concept?
  • Should the fee-accounting engine model per-market capacity so onboarding beyond it is either rejected or explicitly priced differently?

Known Limitations of the v1 Tiering (carry into the brainstorm)

The v1 tiering is a mitigation — these are its known gaps

  • Tier-2 can still no-match + grind 2 retries if tier-1 fully empties the book. Staggering makes this rarer, it does not eliminate it. A pre-fire book-depth-skip (check depth before firing tier 2, skip if exhausted) is a noted future refinement.
  • The tier delay is a blocking sleep in the per-wallet consumer loop → it serializes the consumer under 5m-boundary signal bursts (many signals arriving at once at the candle boundary). A non-blocking spawn (fire the delayed order on a spawned task so the consumer keeps draining) is a follow-up.

Counter-evidence: price ceiling, not depth? (2026-07-09, crypto session — CONFIRMED)

The depth-exhaustion mechanism above is CHALLENGED — do not build on it yet

Three independent lines of evidence point at a price ceiling (the ask repricing above a frozen, shared max_price) rather than wallets exhausting book depth. This is an inference from code + prior measurements, NOT a fresh measurement. Verify via the Decisive experiment before building any Brainstorm Agenda item on the depth story — agenda directions (a), (d) and (e) all assume depth is the binding constraint.

1. FAK semantics — a hard no-match is a PRICE test, not a size test

A FAK into a thin-but-affordable book yields a PARTIAL fill, not an error. A hard no-match therefore means nothing rested at-or-below our price — a price failure, not a size failure. If wallets were genuinely exhausting depth, tier-2 would show partial fills, not RecordedFailure("other").

PM’s directive_limit_price (position_manager crates/position_manager/src/pricing.rs:58) is min(directive max_price, fresh best_ask) — book depth is never an input to the price we send.

2. Prior measurement — the ask reprices above our limit

crypto-shortterm-fak-nomatch-root-cause-2026-07-02 (babylon #942, ~2,200 fires): the ask side was empty on only 1 of ~2,200 no-matches. The dominant mechanism is the ask repricing ABOVE our limit within ~0.7s — 19-25% of UP fires, 29-38% of DOWN fires.

For Agents

This failure mode predates wallets 3-4 entirely — it was measured before the fan-out was ever a suspect. Heavy RecordedFailure("other") is therefore not, by itself, evidence of cannibalization.

3. Arithmetic — 4 wallets are ~6% of median touch depth

In the exact fire regime (τ ∈ [60,150)s, conviction ≥ 0.30 — see crypto-shortterm-phase0-depthprofile):

QuantityValue
Our total clip4 wallets × 10 shares = 40 shares
Touch depth, median658 shares → we are ~6%
Touch depth, p905,109 shares
3¢ cumulative depth, median6,171 shares

BTC moving in the final 60-150s explains the repricing. Our own fills do not — 40 shares cannot move a 658-share touch.

Consequences if confirmed

  • (a) The v1 400ms stagger may make tier-2 strictly WORSE. It walks tier-2 deeper into the reprice window against the same frozen max_price. Per #942, ~2/3 of repriced asks are still above the old limit at +1-3s — so the delay does not let the book “refill”, it lets the price run away.
  • (b) The strategic ceiling reframes entirely. Capacity ≈ touch depth ÷ clip ≈ ~65 wallets at 10-share clips — if wallets fire within the fresh-price window. The binding constraint becomes fan-out latency spread, not market depth — far less restrictive for the fee/MLM plan than the ceiling described above.

Caveats

Not a settled result

crypto-shortterm-phase0-depthprofile publishes median and p90 but NOT p10 — a thin-tail minority of genuine depth exhaustion cannot be excluded. The claim is about the dominant mechanism, not about every fire.

Decisive experiment

Cheap, and it settles the question. Join RecordedFailure("other") fires against pm_fak_attempts telemetry (ts_ms, best_ask_at_snap, fill_status, fill_price, filled_size) and/or book snaps. Per failure:

ObservationVerdictFix direction
ask_at_fire > directive max_pricePrice ceilingFresh per-wallet pricing; rethink the stagger
touch_size < clip, or partial fills presentTrue depth exhaustionSize-aware coordination / partitioning / capacity caps (agenda a, b, d, e)

Nothing should be built until this query is run.

Provenance: crypto_algo session 2026-07-09 (historian sweep of babylon #942 + crypto-shortterm-phase0-depthprofile + PM pricing.rs); hypothesis raised while picking up this note’s brainstorm.

VERDICT — measured 2026-07-09 (duckdb read-only: pm_fak_attempts × crypto_shortterm.emitted_signals × pmv2_autotrade_orders)

CONFIRMED — the ceiling is PRICE. The depth story is refuted at current clip sizes.

The Decisive experiment was run the same day it was proposed. 90.5% of final retry attempts (4,098 / 4,528) were refused with best_ask_at_snap > repriced_limit — the ask sat avg +5.4¢ above our ceiling, having moved avg +9.7¢ since emit. The depth branch of the verdict table essentially never fired.

The price branch is near-unanimous

Outcome on the final retry attemptCountShare
Refused, best_ask_at_snap > repriced_limit (price ceiling)4,098 / 4,52890.5%
Ask ≤ limit yet no fill (depth-exhaustion candidate)21 / 4,5280.46%

Even those 21 are mostly not depth: they are same-second wallet1+wallet2 pairs in which NEITHER wallet filled — a maker pull in flight, not a sibling consuming the book. Sibling cannibalization would leave the first wallet filled and the second empty; the data shows both empty.

All-or-nothing fills disprove the ~1-2 wallet cap

In the 4-wallet era (since 2026-07-08 20:00Z), fills-per-directive is bimodal, not graded:

Fills per directiveDirectivesReading
0 of 4100ask ran away before anyone got there
4 of 488book absorbed ~60-80 shares without trouble
mixed (1-3)~29% of all directivesthe informative middle

71% of directives are all-or-nothing. The 88 directives where all four wallets filled absorbed ~60-80 shares against a 658-share median touch — this directly disproves this note’s core claim that “book depth caps profitable fills at ~1-2 wallets per signal.” When the price is there, everyone fills; when it isn’t, nobody does.

The stagger is counterproductive as shipped

Within the mixed directives, P(fill) decays monotonically with fire order:

Fire order1st2nd3rd4th
P(fill)72.4%51.3%38.2%28.9%

This is a time-spread-vs-moving-ask gradient, NOT a depth gradient

Consequence (a) above is confirmed. Later wallets lose because the ask has moved against a frozen shared max_price — not because earlier wallets ate the book. The v1 400ms tier-2 stagger therefore makes tier-2 strictly worse: it deliberately buys more of the exact thing that is killing the fill. Reconsider it before any further tiering work.

Latency, not fan-out, is the failure mode

  • PM emit → first retry attempt: p50 ~4-4.5s, p90 ~8s — stable every day since 2026-07-02.
  • Adding the 4th wallet moved p50 only 4.38s → 4.54s. The fan-out is not the bottleneck.
  • Ground truth from pmv2_autotrade_orders: ~50% of live buy orders fail as error_class='other' EVERY day since 2026-07-02 — the failure mode predates wallets 3 and 4, exactly as §2 above predicted.

These are latency-conversion losses at already-validated prices

Every refused directive was fillable at emit by construction — the emit gate guarantees directive max_price ≥ ask_at_emit + 0.02. So the ~50% daily refusal rate is neither the market declining our price nor depth: it is ~4-4.5s of conversion latency spent while an already-validated price walks away.

Strategic implication — the ceiling reframes

Consequence (b) above is confirmed: capacity is LATENCY-bound conversion, not depth-bound.

The fee/MLM "hard capacity cap" premise is UNSUPPORTED at current clip sizes

40-80 shares against a 658-share median touch is not a capacity problem. Brainstorm-agenda directions (a) coordinate fills, (d) size-aware / rotation fairness and (e) accept a hard client cap were all premised on depth being the binding constraint — that premise is now measured false. The live lever is the limit/fill path and end-to-end latency, not wallet coordination. Re-derive the Brainstorm Agenda before building any of them.

Two PM-side flags (for position_manager)

Telemetry gap + error misclassification

  1. pm_fak_attempts stopped writing at ~06:57 (session tz) while pmv2_autotrade_orders kept recording for ~2 more hours — the attempt telemetry has a silent gap; anything treating it as complete will under-count.
  2. classify_error should map the FAK no-match string to its own class instead of letting it fall through to "other". The single most common live failure is currently indistinguishable from a generic venue error — which is precisely what made the original misdiagnosis possible.

Provenance: crypto_algo session 2026-07-09, read-only duckdb join of pm_fak_attempts × crypto_shortterm.emitted_signals × pmv2_autotrade_orders across the telemetry week. Confirms — same day — the hypothesis raised in the section above.

Graph View

Backlinks