Repository navigation
docs: align the automatic deposit flow documentation with the implementation - #292
Merged
Merged
Conversation
Replace the outdated section 3.1.1, which described per-transaction crediting with getSignaturesForAddress and quotas replenished by the removed process_deposit endpoint, with a design that builds on the balance sweep of deposit_sol: a free registration endpoint, a scan timer reading watched deposit addresses in batches with getMultipleAccounts, a schedule adapted from the ckETH minter, a fixed fee in SOL deducted from the minted amount, and a watchlist persisted only as a bounded snapshot at pre_upgrade. Every change to the interface, the arguments and the event log is additive, since the minter is deployed on mainnet. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
State that a re-armed account is reported as watching again, that the main account receives the sweepable amount minus the fee share, correct the worst-case cost arithmetic and state its success assumption, and distinguish a failed upgrade from a reinstallation. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ring Move the sequence diagram of the automatic flow ahead of its explanation, remove the semicolon that broke the mermaid parser on GitHub, and define the deposit id where it is first used in the section. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…he constraint State that scan ticks are guarded like the other timers so that they never overlap, and base the automatic deposit fee constraint on the single-signature fee share that a pending mint actually bears. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Drop the separate status query: calling the registration endpoint again returns the stored registration or the id of the deposit in flight, as deposit_eth does in the ckETH minter. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… signature lookup Spell out that scan ticks never overlap, that the fee derivation is a single-attempt estimate with re-arm costs absorbed by the minter, and that only manual deposits are retried by the caller. Remove getSignaturesForAddress from the RPC inventory and cost tables, since the minter no longer uses it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A re-armed entry restarts its schedule from the first gap, bounded by the remaining window, and a re-arm only ever follows a detection. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Record the watchlist snapshot on every upgrade so that an older one cannot be replayed after the watchlist emptied, and let the transaction submission section account for deposits queued by the balance scan. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The window ends with the last scan, and the next registration call starts a new window rather than reporting a registration without a next scan. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…it ids Follow the ckETH minter: a registration freezes neither the minimum deposit amount nor the automatic deposit fee, both are quoted and the values in force at detection apply, the fee being recorded with the queued deposit. deposit_sol compares the latest deposit id of the account before and after its balance read, and a registration is allowed while a deposit_sol call is in progress. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…edule Measure gaps from the previous scan as before, but end the window at a fixed 24 hours after registration, as the ckETH minter does, so that the accumulated tick and call delays have slack and clients and the re-arm share one unambiguous boundary. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ence Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…owner rationale The fee recorded at detection matters for deposits an upgrade finds not yet credited; a credited deposit has its mint amount in CreditedSweep. The minter's principal is excluded as a deposit owner because its default account is the ledger's minting account, not because of an address collision. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…xample with the automatic flow Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…er a concurrent scan Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…n delay and the fee worst case Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…or to new registrations Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…vents the automatic flow adds Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…tric to alert on Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… of chaining gaps Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The re-arm registers the account again instead of restoring the original window, so the queued deposit carries only the automatic deposit fee. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… classification from deposit_sol Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…between tests Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ics' into DEFI-2780-automatic-deposit-flow-impl
…ad advances A registration removed, replaced or expired while the read was in flight was counted, unlike after a successful read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t of the automatic flow Qualify when the id of the latest deposit is returned, list the user-visible changes of the stack in the changelogs, and enable the flow in a second upgrade. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…hen the watchlist is full Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ept together The minter's interval timers keep the schedule of its installation, so after a plain advance of time the next sweep tick could come anywhere within a minute and split the four deposits over two sweep transactions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ntation Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
|
✅ No security or compliance issues detected. Reviewed everything up to f2d0a26. Security OverviewDetected Code Changes
|
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues remain in the documentation and API-comment updates for the automatic deposit flow.
No open issues 🎉
What changed in this PR
Aligns documentation and API comments with the automatic deposit flow introduced in #274. No runtime behavior or interface definitions change.
Changes:
- Updates the design to reflect typed RPC support, balance-based deposit eligibility, and shared sweep processing.
- Clarifies automatic-flow enablement and watchlist persistence during upgrades.
- Aligns quarantine descriptions, cycle-cost comments, and the repository layout documentation.
| File | Description |
|---|---|
minter/src/constants.rs |
Aligns RPC cycle-cost comments with the design estimates. |
minter/cksol_minter.did |
Documents both causes of deposit quarantine. |
minter/CHANGELOG.md |
Clarifies that empty watchlists are not recorded before upgrades. |
libs/types/src/lib.rs |
Aligns Rust quarantine documentation with Candid comments. |
docs/src/development/repository-structure.md |
Adds the automatic deposit module to the layout. |
docs/src/development/design.md |
Updates deposit diagrams, RPC availability, sweep descriptions, and cost-estimate wording. |
docs/src/development/deployment.md |
Clarifies how setting the automatic deposit fee enables the flow. |
Review effort: Balanced
eichhorl
reviewed
Nov 11, 2026
… in the sweep event Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Base automatically changed from
DEFI-2780-automatic-deposit-flow-impl
to
main
November 11, 2026 14:33
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
eichhorl
approved these changes
Nov 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #274, from a consistency pass over the design, the deployment guide, the changelog and the Candid comments of the automatic deposit flow. It only touches documentation and comments.
getMultipleAccountsas not yet offered by the SOL RPC canister, while the flow already uses the typed method.watch_deposit_address, the crediting of a sweep is not specific to the manual flow, theQuarantinederror ofdeposit_solnames only one of the two causes, the cycle figures in the constants differ from the design, and the repository structure omits the automatic flow.🤖 Generated with Claude Code