Crank gas cost

[mschneider]

Problem: crank is currently run without direct incentive mechanism, different ecosystem members are running it pro bono. A more sustainable system would be preferable.

proposed solution: event queue stores extra lamports, cancel/take initiator deposits 1000 lamports per out event (should not require additional writeable accounts) crank collects 1000 lamports per event.

problems: it would require all integrations to pass in either the signer account as writeable or the additional lamports manually in another instruction

[crispheaney]

Alternative solution: a portion of the referrer rebate goes toward cranker

1. have cranker pass in their own open order account into consume_events
2. credit half of the referrer fee to cranker open order account: https://github.com/openbook-dex/program/blob/master/dex/src/state.rs#L3035
3. cranker passes themself as their referrer in settle funds

Benefits:

1. only crankers need to modify their client code
2. no additional fee for users

Cons:

1. rebates is not denominated in SOL

[SpaceMonkeyForever]

If I understand Max's suggestion correctly then the difference between the two approaches is that placing/cancelling orders will incur a fee instead of waiting for a match to collect a fee. I'm honestly not sure which is better. I think there's already an incentive for MMs to crank or else they can't quote. I would rather not charge MMs for placing orders and providing liquidity, charging them when there's a fill (fees) make more sense because they should be making PnL then and the platform gets its cut, so I'd lean towards the second approach by Crisp

[ohaddahan]

Problem: crank is currently run without direct incentive mechanism, different ecosystem members are running it pro bono. A more sustainable system would be preferable.

proposed solution: event queue stores extra lamports, cancel/take initiator deposits 1000 lamports per out event (should not require additional writeable accounts) crank collects 1000 lamports per event.

problems: it would require all integrations to pass in either the signer account as writeable or the additional lamports manually in another instruction

Not familiar enough, but what happens when a bid/ask is matched? Both accounts are closed?
If so, the rent can be the crank incentive, it adds up for high volume.

[luke-truitt]

Problem: crank is currently run without direct incentive mechanism, different ecosystem members are running it pro bono. A more sustainable system would be preferable.

proposed solution: event queue stores extra lamports, cancel/take initiator deposits 1000 lamports per out event (should not require additional writeable accounts) crank collects 1000 lamports per event.

problems: it would require all integrations to pass in either the signer account as writeable or the additional lamports manually in another instruction

I think something similar to this while completely eliminating all other fees would be best, less opinions on how the orderbook should be used and more about ensuring this can be cranked affordably. Factoring in whatever server costs are needed (that scale log in fiat) and txn costs (that scale linearly in SOL) I don't see a reason to reward others as anyone can charge fees separately (dapps/MMs/etc.)

[jkbpvsc]

I think the whole thing boils down to can we afford to break the ABI.

The SOL fee approach has a sound economic model imo, and it works for every market regardless of the value of the underlying asset. It's also more friendly to both takers and makers, because it eats less into the existing fees collected.

Chrises approach is more pragmatic, but it eats into the existing fees more, potentially prompting taker fees to be increased (40 bps suggested), and the economic model only works in markets where tokens are sufficiently valuable (maybe not a bad thing). The benefit of this approach is obvs that it preserves the ABI.

If I understand Max's suggestion correctly then the difference between the two approaches is that placing/cancelling orders will incur a fee instead of waiting for a match to collect a fee. I'm honestly not sure which is better. I think there's already an incentive for MMs to crank or else they can't quote. I would rather not charge MMs for placing orders and providing liquidity, charging them when there's a fill (fees) make more sense because they should be making PnL then and the platform gets its cut, so I'd lean towards the second approach by Crisp

My assumptions is that the cost can be easily circumvented by cranking in the same tx as when crank events are created, further if done correctly cranking can actually pay tx costs for both takers and makers.
This same assumption is true for Chrises approach.

[nickgarfield]

different ecosystem members are running it pro bono

My understanding is that Openbook is divided between permissioned and permissionless markets. The permissioned markets can only be cranked by the individual teams who created them, and so I assume the problem statement here applies to permissionless markets?

A few months ago, we started working on a program (linked below) to auto-crank Serum markets. It only handles the consume_events call today, but we should be able to extend it to settle_funds and other "automatable" instructions in the future. Our original vision was to allow teams who run permissioned markets to save on server costs and decentralize their operations, shifting the crank authority from a dedicated server to a permissionless network of RPC nodes.

I believe this solution could be similar (in spirit at least) to Max's proposal. Ironically, the Clockwork automation fee starts at a minimum 1000 lamports per instruction as proposed. This can be bumped higher to prioritize an important thread with the workernet, like cranking an Openbook market. I don't see any reason to change the Openbook interfaces or introduce a new user fee. To keep a market cranking, a community simply needs to fund the thread account associated with the market (this is permissionless as anyone can transfer SOL to another account).

There remain some challenges to be solved before I would recommend this in production though... On localnet, things obviously look great; but we've yet to see a per-slot time resolution for successful serial transactions on mainnet. We also need to test against a mainnet market where other MMs are actively cranking and see how it fails. I can post back here when things are looking more suitable for realistic mainnet usage. If you get a chance to read through the code, we would super appreciate any feedback you have!

https://github.com/clockwork-xyz/examples/tree/main/serum_crank

[mschneider]

. To keep a market cranking, a community simply needs to fund the thread account associated with the market (this is permissionless as anyone can transfer SOL to another account).

This is definitely an improvement in terms of ease of access from what's happening right now, but only a few communities are actually organized well enough to pay for cranking. The goal of a sustainable solution inside the program should be to have the bill paid up by the traders rather than a benevolent donor.