RFC: List expiring futures on EP3 with maturity T+7, not T

Date: 2026-07-30

Status: Draft

When we list a dated future on EP3, we currently set the EP3 maturity_date to the contract's true expiry T — future_attributes_for in rs/admin-cli/src/instruments.rs:44-58 carries the real contract_date into EP3 "so EP3 expires them correctly" (perpetuals keep the far-future 2099-12-31 sentinel).

This is wrong for how we actually retire an instrument. EP3 does not auto-resolve futures: at maturity it flips the instrument to Expired and leaves positions untouched — we must book the final settlement. Our delist orchestrator (admin-cli delist, rs/admin-cli/src/delist.rs) does that by booking one EP3 two-sided block trade per holder against the house settlement account, then setting the EP3 state to Terminated. Those closeout block trades require EP3 to still consider the instrument open. If EP3 has already expired the instrument at T, the delist procedure can't book the closing trades — the exchange-side expiry races the very procedure that settles it.

AX already has its own source of truth for the real expiry and lifecycle:

• instruments.expiration (TIMESTAMPTZ, mutable) — the true T (db/postgres/1.sql).
• instruments.is_closing — freezes client order entry and modification (cancels allowed) while positions are closed out ahead of delisting; reversible. Terminal state is delisted_at, stamped by the delist run.

So the EP3 maturity date doesn't need to be the real expiry at all — clients never see it (the public expiration field is served from our DB row). It only needs to be late enough that EP3 never expires the instrument out from under the delist procedure.

1. List dated EP3 instruments with an EP3 maturity_date of T+7 days (T = the true expiry, i.e. the nominal contract_date). The buffer is a backstop, not a schedule: the normal path is that admin-cli delist runs shortly after T and terminates the EP3 instrument well before T+7. EP3's own expiry should never fire.

2. At the true T, an automated process moves the instrument to closing state: set is_closing = TRUE on the AX row while the EP3 instrument stays open. From T onward the instrument is exactly in today's pre-delist posture — clients can cancel and be closed out but not open new exposure — until ops runs the delist within the buffer window.

The lifecycle becomes:

Perpetuals (contract_date = 0) are unaffected — they keep the 2099 sentinel and have no automated closing step.

• future_attributes_for (rs/admin-cli/src/instruments.rs): dated contracts get contract_date + 7 days as the EP3 maturity instead of contract_date. Day arithmetic must roll month/year boundaries correctly (use chrono, not field math on the YYYYMMDD designator).
• A scheduled task that scans for instruments with expiration <= now(), is_closing = FALSE, and delisted_at IS NULL, and sets is_closing = TRUE. Same effect as the existing manual admin action, just automated at T; idempotent and safe to rerun.
• No schema change: expiration is already the true T and is_closing is already the closing flag.
• Already-listed dated instruments need their EP3 maturity pushed to T+7 via an EP3 instrument update (one-off ops action at rollout).

• Which EP3 states accept InsertTwoSidedBlockTrade? The proposal assumes closeouts require an open (non-Expired) instrument — confirm with Connamara whether Expired also rejects block trades, or merely rejects regular orders. If Expired happens to allow block trades, the buffer is still cheap insurance but the motivation weakens.
• Where does the automated closing task live? Candidates: the settlement-engine (already runs scheduled per-instrument work) or a small cron. It only needs Postgres access, so the simplest home wins.
• What if the delist slips past T+7? EP3 expires the instrument and we're back to today's problem. Options: alert when is_closing has been set for more than N days without a delist, and/or have the task push the EP3 maturity out further while the instrument remains undelisted. Alerting alone is probably enough for a 7-day window.
• Is 7 days the right buffer? Chosen to comfortably cover a settlement price print plus ops scheduling across a weekend/holiday. No strong attachment; anything ≥ a few business days works.