📌 Description
deregister_anchor only flips the Anchor(address) flag to false via set_anchor_flag; it does not touch Balance(anchor, asset) entries, per its own doc comment ("Existing pool liquidity is unaffected; the anchor simply cannot open new positions"). There is no explicit regression test confirming a deregistered-then-re-registered anchor's balance/anchor_balances are exactly what they were before deregistration, with no double-counting in pool.providers from the re-registration.
🧩 Requirements and context
- Add a regression test: provide liquidity as an anchor, deregister it, confirm
balance/anchor_balances are unchanged and pool.providers still counts it, then re-register the same anchor and confirm balance/anchor_balances/pool.providers remain exactly as they were (no reset, no double-count).
- Confirm the anchor can immediately withdraw its pre-existing balance after re-registration without needing to provide liquidity again first.
- Confirm the anchor cannot
provide_liquidity/open_settlement while deregistered, per existing AnchorNotRegistered behavior.
🛠️ Suggested execution
- Add the test to
src/test.rs, likely adjacent to the existing 're-registered anchor doesn't inherit stale fee-waiver state' test tracked in this repo's backlog, but scoped to balance/pool-provider bookkeeping instead of fee-waiver state.
- No production code changes expected given
deregister_anchor's documented scope; this closes a test-coverage gap on already-intended behavior.
- Reuse existing anchor registration/deregistration test helpers.
✅ Acceptance criteria
🔒 Security notes
If deregistration ever accidentally touched balance state in a future refactor, an anchor's funds could become temporarily or permanently inaccessible purely from an administrative registration action — a serious fund-availability risk this test explicitly guards against.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
deregister_anchoronly flips theAnchor(address)flag tofalseviaset_anchor_flag; it does not touchBalance(anchor, asset)entries, per its own doc comment ("Existing pool liquidity is unaffected; the anchor simply cannot open new positions"). There is no explicit regression test confirming a deregistered-then-re-registered anchor'sbalance/anchor_balancesare exactly what they were before deregistration, with no double-counting inpool.providersfrom the re-registration.🧩 Requirements and context
balance/anchor_balancesare unchanged andpool.providersstill counts it, then re-register the same anchor and confirmbalance/anchor_balances/pool.providersremain exactly as they were (no reset, no double-count).provide_liquidity/open_settlementwhile deregistered, per existingAnchorNotRegisteredbehavior.🛠️ Suggested execution
src/test.rs, likely adjacent to the existing 're-registered anchor doesn't inherit stale fee-waiver state' test tracked in this repo's backlog, but scoped to balance/pool-provider bookkeeping instead of fee-waiver state.deregister_anchor's documented scope; this closes a test-coverage gap on already-intended behavior.✅ Acceptance criteria
🔒 Security notes
If deregistration ever accidentally touched balance state in a future refactor, an anchor's funds could become temporarily or permanently inaccessible purely from an administrative registration action — a serious fund-availability risk this test explicitly guards against.
📋 Guidelines