Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
hpmaxi
marked this pull request as ready for review
October 17, 2026 05:16
luchobonatti
approved these changes
Oct 21, 2026
luchobonatti
left a comment
Member
There was a problem hiding this comment.
This is L-01's suggestion as written, and reduce covers the clamping half of L-08. One doc thought: the design doc only states the rounding rule for wind-down rounds; the epoch rule (remainder stays in the reserve as fund money) lives in kit-spec alone. Could it get a line in the pricing section too?
| - **Settlement**: pricing records what each epoch promised (`shares_promised`, `assets_promised`, see `get_epoch_settlement`). Claims floor one by one, so together they pay at most that. When the last request of a priced epoch settles, the remainder leaves `pending_mint_shares` and `committed` and the vault publishes `EpochReconciled { epoch, share_dust, cash_dust }`. The cash stays in the reserve, owed to nobody, and reaches every holder through the NAV. A running total that would go below zero fails with `AccountingMismatch` (6070) instead of clamping. | ||
| - **A request that can never settle** keeps its epoch open, and the two cases leave different amounts behind. A zero-asset redemption whose holder the share token refuses (`a_request_that_cannot_settle_keeps_its_epoch_open`) leaves only the epoch's ordinary rounding remainder in `committed` — fewer units than the epoch has open requests of that kind — because that request was never owed any cash. A priced deposit whose mint a compliance module refuses (`a_refused_mint_keeps_a_priced_deposit_epoch_open`) is not rounding dust: the mint reverts, so that deposit's whole share entitlement stays in `pending_mint_shares`, on top of the epoch's own remainder, until the mint is allowed. Either way it is still owed to nobody. | ||
|
|
||
| **Settlement and upgrades.** The settlement record counts a request only from the moment it exists. A vault upgraded in place to this version while any request is open would under-count its open epochs: claims in epochs priced before the upgrade would revert, and a mixed epoch could reconcile early. This version must therefore be deployed fresh, or reached by upgrade only once no request is open anywhere in the vault. |
Member
There was a problem hiding this comment.
apply upgrades without checking for open requests, so this rule is enforced only by the doc. Could apply_upgrade refuse while any request is open, or could the migration count them?
This branch was successfully deployed
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.
Summary
Closes #283
Flooring the epoch total and then each claim left a remainder that was never reconciled. It is now. Each epoch records what pricing promised and what has been paid; when its last request settles, the remainder leaves
pending_mint_sharesandcommitted, stays in the reserve as fund money, andEpochReconciledsays how much. Every subtraction from a running total is checked.Changes
get_epoch_settlement, eventEpochReconciled.AccountingMismatch, 6070).Deviations
owed"the same treatment on the last claim". That is not safe: a later round needs those units. The remainder stays (at most one unit per holder), and a test shows why.Acceptance criteria
EpochReconciledTest plan
Automated tests
SOROBAN_SDK_BUILD_SYSTEM_SUPPORTS_SPEC_SHAKING_V2=1 nix develop -c cargo test --locked -p async-vault settlement wind_downManual verification
None.
Breaking changes
None for callers; a new view and a new event. This version must be deployed fresh, or reached by upgrade only when no request is open: the settlement record counts requests from the moment it exists, so upgrading a vault in place while a request is open would under-count its open epochs, reverting claims from epochs priced before the upgrade and risking an early reconcile of a mixed epoch.
Checklist
Screenshots
None.