Money path. This changes when a deposit becomes spendable. Read the
money-path rule in CONTRIBUTING.md
first. Labelled help wanted rather than good first issue: the code is
small, the policy question is the work.
Confirmations are per asset, not per amount. Every BTC deposit waits the same
number of blocks whether it is worth a coffee or a car.
docs/runbook-reorg.md:155
names this directly: per-amount confirmation tiers are Phase 2; a cheap
approximation today is a per-asset delay.
The cost of getting it wrong is asymmetric, which is the whole point:
- Too few confirmations on a large deposit and a reorg orphans a credit the
user has already spent. The money is gone and only a human can unwind it —
that is what the reorg runbook is for.
- Too many on a small deposit and the user waits, complains, and the
platform looks slow.
What to build
Confirmation requirements that scale with the amount. Something like: below
some threshold, one confirmation; above it, the current count; above a second
threshold, more.
The hard parts, which are not code
- Where the thresholds live. Per-asset columns on
assets follow the
pattern migration 0006 established and let an operator retune without a
deployment. A settings-only version is simpler and needs a restart. Argue
for one.
- What "the amount" means when a deposit takes several payments. An
on-chain deposit address accepts more than one payment, and each arrives with
its own confirmation count. Is the tier chosen per payment, or by the running
total? Per payment is simpler; by running total is harder to game by
splitting.
- It must not be possible to lower a requirement after the fact. A deposit
that has already been credited under one rule must never be re-evaluated
under a looser one.
Where the code is
src/crypto_processing_api/services/deposits.py decides when a payment is
credited. services/asset_registry.py is where per-asset behaviour lives now,
and is the natural home for a policy object. docs/runbook-reorg.md needs
updating with whatever lands.
Start by proposing the policy in this issue. A pull request that picks the
thresholds silently is a pull request that cannot be reviewed.
Confirmations are per asset, not per amount. Every BTC deposit waits the same
number of blocks whether it is worth a coffee or a car.
docs/runbook-reorg.md:155names this directly: per-amount confirmation tiers are Phase 2; a cheap
approximation today is a per-asset delay.
The cost of getting it wrong is asymmetric, which is the whole point:
user has already spent. The money is gone and only a human can unwind it —
that is what the reorg runbook is for.
platform looks slow.
What to build
Confirmation requirements that scale with the amount. Something like: below
some threshold, one confirmation; above it, the current count; above a second
threshold, more.
The hard parts, which are not code
assetsfollow thepattern migration
0006established and let an operator retune without adeployment. A settings-only version is simpler and needs a restart. Argue
for one.
on-chain deposit address accepts more than one payment, and each arrives with
its own confirmation count. Is the tier chosen per payment, or by the running
total? Per payment is simpler; by running total is harder to game by
splitting.
that has already been credited under one rule must never be re-evaluated
under a looser one.
Where the code is
src/crypto_processing_api/services/deposits.pydecides when a payment iscredited.
services/asset_registry.pyis where per-asset behaviour lives now,and is the natural home for a policy object.
docs/runbook-reorg.mdneedsupdating with whatever lands.
Start by proposing the policy in this issue. A pull request that picks the
thresholds silently is a pull request that cannot be reviewed.