fix(#444): a maintenance-rate raise is no longer retroactive

[dcccrypto]

Decision C — both halves. Half (A) is implemented; half (B) turns out to have no safe place to sit, and that's a finding rather than an omission. Detail below.

Stacked on #463 — both grow AssetOracleProfileV16. Merge #463 first.

The bug

last_fee_slot is anchored at account creation and advanced only by SyncMaintenanceFee. While the rate is 0 nobody cranks, so it stays pinned at creation for the market's whole life — and the moment marketauth raises the rate, the next permissionless crank bills new_rate × (the account's entire age), including every slot the rate was 0, capped only by capital.

A small-looking rate takes up to 100% of a flat account, and the rate change and the crank bundle atomically so the victim never gets a turn. That defeats #428's safety argument, which Live-gated the change assuming a user could withdraw first.

My first attempt was in the engine, and the spec rejected it

I capped dt inside sync_account_fee_to_slot_not_atomic and broke v16_spec_tests.rs:

spec.md §981 — charges "exactly once over [last_fee_slot_i, anchor]" … and advances last_fee_slot_i = anchor.

The retroactivity is specified. But §981 governs what the engine does with a given anchor — and choosing the anchor is the wrapper's job, constrained only by "Live anchors must be <= current_slot". A smaller anchor is fully compliant.

So the fix is two spec-compliant engine calls instead of one:

[last_fee_slot, checkpoint]  at the PREVIOUS rate   ← what was actually owed
[checkpoint,    now]         at the CURRENT rate    ← ordinary accrual

UpdateMaintenanceFeePerSlot records (slot, previous_rate) when — and only when — the rate actually changes, so a no-op re-assert can't move the checkpoint and silently forgive owed fees.

State: two fields on AssetOracleProfileV16, asset 0's copy holding the market-wide value (the existing precedent: asset 0's profile carries market-wide oracle state the config mirrors). ASSET_ORACLE_PROFILE_LEN 408 → 432, still inside the fixed 512-byte slot, so no offset moves. It isn't in WrapperConfigV16 because that's exactly 576 and growing it shifts MARKET_GROUP_OFF, bricking every deployed market.

(B) has no safe place to sit

The decision asked for a max_accrual_dt_slots per-crank bound as belt and braces. I implemented it. Once (A) exists it cannot go anywhere useful:

• On the post-checkpoint leg it under-collects ordinary accrual from any account that simply hasn't been cranked lately — legitimately owed fees, not hostile ones. Six existing tests assert those exact amounts and were right to; all six failed with the cap in.
• On the pre-checkpoint leg it's worse than useless: the leg stops short of the checkpoint, and the second call then bills the remaining pre-change window at the new rate — re-creating the exact confiscation (A) prevents. The new test fails with the account drained to zero.

With (A) there's no unbounded hostile window left. A cap would only defer legitimately-owed fees, so it's deliberately absent, with the reasoning in-source rather than in a commit message someone would have to find.

Verified

check	result
new test	rate 0 for ~900 slots, then raised and cranked immediately (the bundled attack) — only the 10 post-raise slots are billed, capital 950
negative control	checkpoint leg disabled → test fails with capital 0, fully drained; restored → 950
full CI suite	605 passed / 21 failed — "OK: failing set matches the allowlist exactly". The six accrual tests pass untouched.

Upstream

sync_account_fee_to_slot_not_atomic exists at av (tip 8eb7142a) with the same retroactive shape — not a divergence we introduced, and worth filing upstream, since spec.md is Toly's and upstream's own engine carries the same exposure.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NgoNgagkvw7i5SSRC3FJ8D

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 6fcc4ecf-cc0d-4b98-80aa-e12c677793a6

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}