The Evelyn IOU burner currently burns every positive EVE balance. Small buybacks therefore produce many tiny burns and proof notifications. The owner wants to keep making small buybacks, at most one attempted swap per iteration, while accumulating EVE for fewer, larger burns.
Add two independently configurable EVE-denominated amounts: a minimum amount per burn and a reserve that must remain in the burner wallet. This follows #92 (minimum buyback input amounts), but controls the burn stage separately.
Agreed behavior
After the existing buyback stage, reload the EVE balance and calculate:
Submit a new burn only when amountToBurn > 0 and amountToBurn >= minimumBurnAmount. Equality qualifies.
When the threshold is reached, burn the entire eligible amount above the reserve. The minimum is a threshold, not a fixed batch size or maximum.
Never round up, spend the EVE reserve, or submit a smaller burn to reach the minimum.
Below the threshold, keep the EVE for a later iteration. Do not submit a burn or send a burn notification.
Continue the existing small buybacks independently of this burn threshold. Being below the burn minimum must not suppress an otherwise eligible buyback.
Apply the same rule to all EVE in the wallet, including earlier buybacks and direct deposits. A new swap is not required for a burn.
Acceptance examples
With minimum burn amount 1 EVE and reserve 0.1 EVE:
EVE balance
Result
EVE remaining after a successful burn
0 or 0.05
No burn
Unchanged
0.1
No burn
0.1
1.05
No burn; only 0.95 is available
1.05
1.099999
No burn; available amount is below 1
1.099999
1.1
Burn exactly 1
0.1
1.35
Burn exactly 1.25
0.1
Also verify that multiple small buybacks accumulate across iterations until the threshold qualifies, and that subsequent accumulation starts from the retained reserve. Compare the actual rounded burn amount against the minimum, so precision conversion cannot produce a below-minimum burn or consume the reserve.
These values are the owner's agreed behavioral examples; production values were not explicitly selected and must be set when implementing/configuring the change.
Configuration and implementation scope
Add the minimum burn amount and EVE reserve to the reference implementation's constructor, and supply them alongside the existing production burner arguments in NenjimHubImpl.constructEvelynIOUBurnerProdProcess().
Use existing MoneyAmount values and the canonical EVE currency UUID. No new ValueTags, general configuration framework, or public administration API is needed.
Validate both amounts before worker startup: reject null amounts/values/identities and non-EVE currency UUIDs; require a strictly positive minimum and a non-negative reserve. A zero reserve is valid. Preserve existing configuration validation.
Replace complete-balance burning with eligible-amount burning. Use the actual submitted amount for the pending burn record and notification's EVE amount and value calculation; exclude the retained reserve from both.
Preserve the fresh canonical EVE/USDT price requirement and the existing successful FINALIZED burn notification with transaction proof. Threshold skips produce no proof notification; failed or unresolved burns produce no success notification.
Preserve pending-burn priority and reconciliation of the original signature. A pending burn must not be re-evaluated as a new burn against the threshold, rebuilt, or submitted again. Preserve pending-swap recovery, suspension rules, and non-overlapping iterations.
Verification and boundaries
Update directly affected OpenSpec requirements, constructor/domain JavaDoc and configuration documentation through the normal workflow. Compile relevant sources, perform focused offline checks of threshold boundaries, reserve preservation, precision handling, accumulation, direct deposits, validation, pending-state behavior and notification amounts; run strict validation and whitespace checks. Do not submit live transactions. No permanent automated tests are requested by this issue.
Keep buyback minima/maxima/reserves, currency priority, at most one attempted swap per iteration, scheduling, Jupiter routing, transaction confirmation, Ticker sources/API/history, process lifecycle and private deployment files unchanged. No burn maximum or notification batching service is requested.
Related work: #92 (minimum buyback amounts), #90 (per-currency input limits) and #91 (pending swap recovery). This issue records the agreed change; implementation and deployment are separate tasks.
## Problem and outcome
The Evelyn IOU burner currently burns every positive EVE balance. Small buybacks therefore produce many tiny burns and proof notifications. The owner wants to keep making small buybacks, at most one attempted swap per iteration, while accumulating EVE for fewer, larger burns.
Add two independently configurable EVE-denominated amounts: a minimum amount per burn and a reserve that must remain in the burner wallet. This follows #92 (minimum buyback input amounts), but controls the burn stage separately.
## Agreed behavior
After the existing buyback stage, reload the EVE balance and calculate:
```text
availableForBurn = max(eveBalance - eveReserve, 0)
amountToBurn = roundDown(availableForBurn, eveMintPrecision)
```
- Submit a new burn only when `amountToBurn > 0` and `amountToBurn >= minimumBurnAmount`. Equality qualifies.
- When the threshold is reached, burn the entire eligible amount above the reserve. The minimum is a threshold, not a fixed batch size or maximum.
- Never round up, spend the EVE reserve, or submit a smaller burn to reach the minimum.
- Below the threshold, keep the EVE for a later iteration. Do not submit a burn or send a burn notification.
- Continue the existing small buybacks independently of this burn threshold. Being below the burn minimum must not suppress an otherwise eligible buyback.
- Apply the same rule to all EVE in the wallet, including earlier buybacks and direct deposits. A new swap is not required for a burn.
## Acceptance examples
With minimum burn amount **1 EVE** and reserve **0.1 EVE**:
| EVE balance | Result | EVE remaining after a successful burn |
| ---: | --- | ---: |
| 0 or 0.05 | No burn | Unchanged |
| 0.1 | No burn | 0.1 |
| 1.05 | No burn; only 0.95 is available | 1.05 |
| 1.099999 | No burn; available amount is below 1 | 1.099999 |
| 1.1 | Burn exactly 1 | 0.1 |
| 1.35 | Burn exactly 1.25 | 0.1 |
Also verify that multiple small buybacks accumulate across iterations until the threshold qualifies, and that subsequent accumulation starts from the retained reserve. Compare the actual rounded burn amount against the minimum, so precision conversion cannot produce a below-minimum burn or consume the reserve.
These values are the owner's agreed behavioral examples; production values were not explicitly selected and must be set when implementing/configuring the change.
## Configuration and implementation scope
- Add the minimum burn amount and EVE reserve to the reference implementation's constructor, and supply them alongside the existing production burner arguments in `NenjimHubImpl.constructEvelynIOUBurnerProdProcess()`.
- Use existing `MoneyAmount` values and the canonical EVE currency UUID. No new ValueTags, general configuration framework, or public administration API is needed.
- Validate both amounts before worker startup: reject null amounts/values/identities and non-EVE currency UUIDs; require a strictly positive minimum and a non-negative reserve. A zero reserve is valid. Preserve existing configuration validation.
- Replace complete-balance burning with eligible-amount burning. Use the actual submitted amount for the pending burn record and notification's EVE amount and value calculation; exclude the retained reserve from both.
- Preserve the fresh canonical EVE/USDT price requirement and the existing successful `FINALIZED` burn notification with transaction proof. Threshold skips produce no proof notification; failed or unresolved burns produce no success notification.
- Preserve pending-burn priority and reconciliation of the original signature. A pending burn must not be re-evaluated as a new burn against the threshold, rebuilt, or submitted again. Preserve pending-swap recovery, suspension rules, and non-overlapping iterations.
## Verification and boundaries
Update directly affected OpenSpec requirements, constructor/domain JavaDoc and configuration documentation through the normal workflow. Compile relevant sources, perform focused offline checks of threshold boundaries, reserve preservation, precision handling, accumulation, direct deposits, validation, pending-state behavior and notification amounts; run strict validation and whitespace checks. Do not submit live transactions. No permanent automated tests are requested by this issue.
Keep buyback minima/maxima/reserves, currency priority, at most one attempted swap per iteration, scheduling, Jupiter routing, transaction confirmation, Ticker sources/API/history, process lifecycle and private deployment files unchanged. No burn maximum or notification batching service is requested.
Related work: #92 (minimum buyback amounts), #90 (per-currency input limits) and #91 (pending swap recovery). This issue records the agreed change; implementation and deployment are separate tasks.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem and outcome
The Evelyn IOU burner currently burns every positive EVE balance. Small buybacks therefore produce many tiny burns and proof notifications. The owner wants to keep making small buybacks, at most one attempted swap per iteration, while accumulating EVE for fewer, larger burns.
Add two independently configurable EVE-denominated amounts: a minimum amount per burn and a reserve that must remain in the burner wallet. This follows #92 (minimum buyback input amounts), but controls the burn stage separately.
Agreed behavior
After the existing buyback stage, reload the EVE balance and calculate:
amountToBurn > 0andamountToBurn >= minimumBurnAmount. Equality qualifies.Acceptance examples
With minimum burn amount 1 EVE and reserve 0.1 EVE:
Also verify that multiple small buybacks accumulate across iterations until the threshold qualifies, and that subsequent accumulation starts from the retained reserve. Compare the actual rounded burn amount against the minimum, so precision conversion cannot produce a below-minimum burn or consume the reserve.
These values are the owner's agreed behavioral examples; production values were not explicitly selected and must be set when implementing/configuring the change.
Configuration and implementation scope
NenjimHubImpl.constructEvelynIOUBurnerProdProcess().MoneyAmountvalues and the canonical EVE currency UUID. No new ValueTags, general configuration framework, or public administration API is needed.FINALIZEDburn notification with transaction proof. Threshold skips produce no proof notification; failed or unresolved burns produce no success notification.Verification and boundaries
Update directly affected OpenSpec requirements, constructor/domain JavaDoc and configuration documentation through the normal workflow. Compile relevant sources, perform focused offline checks of threshold boundaries, reserve preservation, precision handling, accumulation, direct deposits, validation, pending-state behavior and notification amounts; run strict validation and whitespace checks. Do not submit live transactions. No permanent automated tests are requested by this issue.
Keep buyback minima/maxima/reserves, currency priority, at most one attempted swap per iteration, scheduling, Jupiter routing, transaction confirmation, Ticker sources/API/history, process lifecycle and private deployment files unchanged. No burn maximum or notification batching service is requested.
Related work: #92 (minimum buyback amounts), #90 (per-currency input limits) and #91 (pending swap recovery). This issue records the agreed change; implementation and deployment are separate tasks.