cancel-on-disconnect

[jordy25519]

Proposal to provide a CEX like cancel-on-disconnect feature for Drift protocol.
Simple kill-switch to guarantee when a subaccount is detected offline its orders will not be matched.

motivation: Drift gateway provdies a CEX like interface already and this feature is a nice addition to that

Sketch

Users can opt-in to cancel-on-disconnect at anytime by doing the following:

• derive a heartbeat account pda(PROGRAM_ID, subaccount_id, b'heatbeat')
• User submits a heartbeat tx every n heartbeat slots while active.
  where n is a protocol wide or user defined parameter.
  clients should submit a periodic tx to update heartbeat slot.
• Filler bots observe current_slot - last_heartbeat_slot < n can initiate a special cancel tx on the subaccount (similar to current timestamp expire behaviour). additionally, add make/take validations to prevent fills on disconnected subaccount orders.

// pseudo code
#[account]
struct SubaccountHeartbeat {
    active_session: bool,
    last_heartbeat_slot: u64,
}

fn handle_heartbeat() {
    heartbeat.active_session = true;
    last_hearbeat_slot = Clock::get()?.slot;
}

fn handle_cancel_on_disconnect() {
    // TODO: validation..
    heartbeat.active_session = false;
    for order in user.orders {
        handle_cancel_order(order);
    }
}

Considerations

• during congestion, a heartbeat tx not landing causes orders to expire unwarranted. The heartbeat period can be adjusted to compensate for reliability by trading latency of the kill-switch.

• not sure if the fees are acceptable, ~0.43-0.95SOL (+expiry fees) per day to use the heartbeat, assuming 5000 lamports per tx

• maybe filler bots have incentives to not cancel orders in a timely way, not sure how this is handled with order expiry timestamp currently. the same filler bot reward / user fees may be used.

Alternatives Considered

Add a heartbeat_slot to UserAccount
main drawback is breaking change, while one (small) benefit is that any tx could be used to update the heartbeat slot

[0xbigz]

i like the level of detail in this post @jordy25519

do you think maxTs in the OrderParams is a decent solution for this instead of introducing breaking change?

would be curious to hear the pros of going beyond that