The Evelyn IOU burner currently attempts an otherwise eligible buyback without checking whether EVE is cheap relative to Evelyn's reference price. The owner wants purchases for burning to reduce circulating supply specifically while the Evelyn Price Index is below zero.
Gate new buybacks only on that price condition. Skipping a purchase must still allow the iteration to continue to the existing EVE-balance and burn steps.
Price condition and authoritative source
The Overview chart in Evelyn Mission Control displays EvelynStatusIndexPoint.evelynPriceIndex(), calculated as:
com.r35157.evelyn.service.status.EvelynStatusService.getReferencePrice(Instant timestamp) returns an AssetPrice for the reference curve, not the index itself. Therefore the agreed buyback condition is:
actual EVE/USDT price < getReferencePrice(decisionInstant).price()
Equality does not qualify. Apply this comparison when the iteration is ready to submit a new buyback, using a fresh canonical EVE/USDT observation from the existing TickerService and the reference price for the current decision instant. Use the existing configured maximum price age; do not add another freshness setting.
Supply the corresponding EvelynStatusService to the burner through the existing Hub composition. Reuse its public reference-price operation. Do not duplicate curve constants or growth calculations, read chart objects, or use the last stored history point as the purchase decision.
Agreed iteration behavior
Preserve pending-burn priority and the existing read-only reconciliation of pending swaps. The price condition governs new purchases, not checking an already submitted transaction.
When a new swap is otherwise permitted and its input candidate is eligible, evaluate the price condition before invoking Jupiter.
Below reference: permit the existing buyback, subject to all existing input minimum/reserve/maximum, precision, suspension and transaction rules. This condition grants permission; it does not require a purchase if another condition prevents it.
At or above reference: submit no new swap from any configured input in that iteration.
If either required price is missing, stale where applicable, invalid, unavailable or cannot be obtained, submit no new swap. Validate the canonical trading pair and usable positive prices, and log why the purchase was skipped.
A price-condition skip must continue to processCompleteEveBalance(); it must not return from the entire iteration or suppress the later burn evaluation.
Existing EVE, including tokens from earlier buybacks and direct deposits, remains eligible for burning under the existing burn minimum, retained reserve, precision, fresh valuation price and transaction rules. A successful purchase in the current iteration is not required for a burn.
Re-evaluate eligibility on the next scheduled iteration. A price skip must not become a permanent suspension.
Acceptance examples
With a reference price of 15 USDT per EVE and an otherwise eligible input:
Current EVE/USDT price
New buyback
Subsequent EVE burn evaluation
14.99
Permitted
Continues
15.00
Skipped
Continues
15.01
Skipped
Continues
Missing, stale or invalid
Skipped
Continues under its existing requirements
Also verify that an unavailable reference-price lookup skips only the purchase; an eligible existing EVE balance can still be burned when its own requirements are met. A pending swap must still be reconciled while price is at or above reference, and any newly permitted purchase after reconciliation must pass the current price condition. Preserve pending-burn priority and at most one new swap attempt per iteration.
Implementation scope and verification
Update the directly affected OpenSpec requirements, constructor/domain JavaDoc and operating documentation through the normal project workflow. Compile relevant sources and perform focused offline verification of below/equal/above boundaries, unavailable prices, continued burn processing, subsequent iteration recovery and pending transaction behavior. Validate the affected OpenSpec change strictly. No live financial transactions are needed to verify this issue.
Keep the existing input configuration, scheduling, Jupiter execution, burn thresholds/reserve, confirmation, notifications and lifecycle behavior. No new Ticker sources, history storage, configuration framework or ValueTags are needed.
Related work: #88 (reference-price API), #91 (pending swap recovery), #92 (minimum buyback inputs) and #93 (burn minimum and reserve).
This issue records the agreed change. Implementation and deployment are separate tasks.
## Problem and outcome
The Evelyn IOU burner currently attempts an otherwise eligible buyback without checking whether EVE is cheap relative to Evelyn's reference price. The owner wants purchases for burning to reduce circulating supply specifically while the Evelyn Price Index is below zero.
Gate **new buybacks only** on that price condition. Skipping a purchase must still allow the iteration to continue to the existing EVE-balance and burn steps.
## Price condition and authoritative source
The Overview chart in Evelyn Mission Control displays `EvelynStatusIndexPoint.evelynPriceIndex()`, calculated as:
```text
Evelyn Price Index = ((actual EVE/USDT price / reference EVE/USDT price) - 1) * 10
```
`com.r35157.evelyn.service.status.EvelynStatusService.getReferencePrice(Instant timestamp)` returns an `AssetPrice` for the reference curve, not the index itself. Therefore the agreed buyback condition is:
```text
actual EVE/USDT price < getReferencePrice(decisionInstant).price()
```
Equality does not qualify. Apply this comparison when the iteration is ready to submit a new buyback, using a fresh canonical EVE/USDT observation from the existing `TickerService` and the reference price for the current decision instant. Use the existing configured maximum price age; do not add another freshness setting.
Supply the corresponding `EvelynStatusService` to the burner through the existing Hub composition. Reuse its public reference-price operation. Do not duplicate curve constants or growth calculations, read chart objects, or use the last stored history point as the purchase decision.
## Agreed iteration behavior
- Preserve pending-burn priority and the existing read-only reconciliation of pending swaps. The price condition governs new purchases, not checking an already submitted transaction.
- When a new swap is otherwise permitted and its input candidate is eligible, evaluate the price condition before invoking Jupiter.
- Below reference: permit the existing buyback, subject to all existing input minimum/reserve/maximum, precision, suspension and transaction rules. This condition grants permission; it does not require a purchase if another condition prevents it.
- At or above reference: submit no new swap from any configured input in that iteration.
- If either required price is missing, stale where applicable, invalid, unavailable or cannot be obtained, submit no new swap. Validate the canonical trading pair and usable positive prices, and log why the purchase was skipped.
- A price-condition skip must continue to `processCompleteEveBalance()`; it must not return from the entire iteration or suppress the later burn evaluation.
- Existing EVE, including tokens from earlier buybacks and direct deposits, remains eligible for burning under the existing burn minimum, retained reserve, precision, fresh valuation price and transaction rules. A successful purchase in the current iteration is not required for a burn.
- Re-evaluate eligibility on the next scheduled iteration. A price skip must not become a permanent suspension.
## Acceptance examples
With a reference price of **15 USDT per EVE** and an otherwise eligible input:
| Current EVE/USDT price | New buyback | Subsequent EVE burn evaluation |
| ---: | --- | --- |
| 14.99 | Permitted | Continues |
| 15.00 | Skipped | Continues |
| 15.01 | Skipped | Continues |
| Missing, stale or invalid | Skipped | Continues under its existing requirements |
Also verify that an unavailable reference-price lookup skips only the purchase; an eligible existing EVE balance can still be burned when its own requirements are met. A pending swap must still be reconciled while price is at or above reference, and any newly permitted purchase after reconciliation must pass the current price condition. Preserve pending-burn priority and at most one new swap attempt per iteration.
## Implementation scope and verification
Update the directly affected OpenSpec requirements, constructor/domain JavaDoc and operating documentation through the normal project workflow. Compile relevant sources and perform focused offline verification of below/equal/above boundaries, unavailable prices, continued burn processing, subsequent iteration recovery and pending transaction behavior. Validate the affected OpenSpec change strictly. No live financial transactions are needed to verify this issue.
Keep the existing input configuration, scheduling, Jupiter execution, burn thresholds/reserve, confirmation, notifications and lifecycle behavior. No new Ticker sources, history storage, configuration framework or ValueTags are needed.
Related work: #88 (reference-price API), #91 (pending swap recovery), #92 (minimum buyback inputs) and #93 (burn minimum and reserve).
This issue records the agreed change. Implementation and deployment are separate tasks.
minimons
self-assigned this 2026-10-06 13:41:05 +02:00
minimons
added this to the Nenjim project 2026-10-06 13:41:09 +02:00
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 attempts an otherwise eligible buyback without checking whether EVE is cheap relative to Evelyn's reference price. The owner wants purchases for burning to reduce circulating supply specifically while the Evelyn Price Index is below zero.
Gate new buybacks only on that price condition. Skipping a purchase must still allow the iteration to continue to the existing EVE-balance and burn steps.
Price condition and authoritative source
The Overview chart in Evelyn Mission Control displays
EvelynStatusIndexPoint.evelynPriceIndex(), calculated as:com.r35157.evelyn.service.status.EvelynStatusService.getReferencePrice(Instant timestamp)returns anAssetPricefor the reference curve, not the index itself. Therefore the agreed buyback condition is:Equality does not qualify. Apply this comparison when the iteration is ready to submit a new buyback, using a fresh canonical EVE/USDT observation from the existing
TickerServiceand the reference price for the current decision instant. Use the existing configured maximum price age; do not add another freshness setting.Supply the corresponding
EvelynStatusServiceto the burner through the existing Hub composition. Reuse its public reference-price operation. Do not duplicate curve constants or growth calculations, read chart objects, or use the last stored history point as the purchase decision.Agreed iteration behavior
processCompleteEveBalance(); it must not return from the entire iteration or suppress the later burn evaluation.Acceptance examples
With a reference price of 15 USDT per EVE and an otherwise eligible input:
Also verify that an unavailable reference-price lookup skips only the purchase; an eligible existing EVE balance can still be burned when its own requirements are met. A pending swap must still be reconciled while price is at or above reference, and any newly permitted purchase after reconciliation must pass the current price condition. Preserve pending-burn priority and at most one new swap attempt per iteration.
Implementation scope and verification
Update the directly affected OpenSpec requirements, constructor/domain JavaDoc and operating documentation through the normal project workflow. Compile relevant sources and perform focused offline verification of below/equal/above boundaries, unavailable prices, continued burn processing, subsequent iteration recovery and pending transaction behavior. Validate the affected OpenSpec change strictly. No live financial transactions are needed to verify this issue.
Keep the existing input configuration, scheduling, Jupiter execution, burn thresholds/reserve, confirmation, notifications and lifecycle behavior. No new Ticker sources, history storage, configuration framework or ValueTags are needed.
Related work: #88 (reference-price API), #91 (pending swap recovery), #92 (minimum buyback inputs) and #93 (burn minimum and reserve).
This issue records the agreed change. Implementation and deployment are separate tasks.