Order spam #2188
Order spam #2188
Conversation
| @@ -89,6 +89,9 @@ Network parameter: `spam.order.MinimalMarginQuantumMultiple` (between 0 and infi | |||
|
|
|||
| If the maintenance margin for a given transaction is smaller than the parameter `spam.order.MinimalMarginSizeQuantumMultiple`, then the transaction is pre-block rejected. | |||
| I.e. if `(rf + linear slippage param) x size x price < spam.order.MinimalMarginSizeQuantumMultiple x asset quantum amount` then the order is rejected. Here `rf` is the risk factor (and will be different for long and for short) `linear slippage param` is a market parameter and `size` and `price` are assumed to be correctly scaled by, PDPs and MDPs respectively. | |||
| - For peg orders we check the `price` implied by the peg and the book at submission time. | |||
There was a problem hiding this comment.
what if the peg doesn't exist?
Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com>
Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com>
| @@ -85,19 +85,28 @@ Further, each party is allowed to submit up to `n` transactions per epoch where | |||
|
|
|||
| ### Transaction Spam | |||
|
|
|||
| Before any order or liquidity commitment is accepted for a perpetual futures or expiring futures check that the party has `margin + general > 0` with `margin` being the balance in the margin account for the relevant market and `general` the balance in the general account for the relevant asset. Orders from parties that don't meet this criteria are rejected. This is to be done after the PoW check. | |||
There was a problem hiding this comment.
we need to account for order margin I'd imagine too
There was a problem hiding this comment.
Yes, please have a look again after the recent edit.
cdummett
force-pushed
the
fix/order-spam-amendments-etc
branch
from
7e014c5
to
0e11ca0
Compare
cdummett
dismissed
their stale review
Dismissing previous approval as content added for spot markets.
|
|
||
| The following points apply generally to both derivative and spot markets: | ||
|
|
||
| - Non-persistent orders are not blocked by the mechanisms described above as long as the market exists. |
There was a problem hiding this comment.
What exactly do we mean by this? Is it that market orders are not subject to the minimum size checks? @cdummett
|
|
||
| Further, given the network parameter: `spam.order.minimalMarginQuantumMultiple` (between 0 and infinite) | ||
|
|
||
| If the maintenance margin for a given transaction is smaller than the parameter `spam.order.minimalMarginQuantumMultiple`, then the transaction is pre-block rejected. |
There was a problem hiding this comment.
So there will be cases where margin + order margin could be 0, but the transaction should still be accepted. I'm thinking, especially, about cases where a party has a general balance of 0, and margin balance < initial margin, but >= maintenance level (ie they're close to getting closed out). They might want to submit a transaction closing their current position. In that case the maintenance level for the given transaction == 0.
As per an exceptionally long thread on slack, there are also cases, specifically when dealing with capped futures, where the margin requirement for an order can be 0. This will, most likely cause such orders to be rejected as a rule.
To this end, I think it makes more sense for the markets themselves to receive a call to a function like OrderAcceptanceLikelihood, which the order spam component keeps track of over time. Should a given party submit N orders that are below 50% likely to get accepted over the course of N blocks, any order transaction that is less than 50% likely to get accepted should get rejected.
The benefits are that individual markets can determine whether or not, in the context of that market, an order makes more or less sense, and therefore should or should not be accepted, without relying on a single network parameter. Because we can keep a tally of these transaction types over time, we could also adjust the threshold for rejection/acceptance of any given transaction on a per-party basis, based on their behaviour. A party that submits, say, a zero-margin order to a capped market once isn't a worry as such. A party doing so every block, or several times per block, may see their order acceptance threshold increased to 75%, or even 100% (effectively timing them out for N blocks).
Aims to address comments from @ze97286 that got missed (by me) on the previous PR here #2180:
close #2097