You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be useful for some use cases to store a value which tracks the total base_qty currently listed on a given slab.
While this could be tracked on the calling program side, I would suggest this is also an asset / use-case agnostic feature that might be useful for a number of cases.
An example case might be where a market order (or any order for that matter) should be capped so as not to take more than some % of the available volume. It may be generally useful to have an easily accessible metric/summary of volume available on the book.
Suggested approach would be to:
Increment this value by base_qty base_quantity of the new Leaf_Node posted
Decrement this value each time Out.base_size each time an Out is generated
The text was updated successfully, but these errors were encountered:
Personally just had this convo w/ Henry a bit back. This adds a lot of overhead to the orders account and while it does have huge UX benefits there is a pretty severe cost to adding so many bytes to the slab.
It may be useful for some use cases to store a value which tracks the total base_qty currently listed on a given slab.
While this could be tracked on the calling program side, I would suggest this is also an asset / use-case agnostic feature that might be useful for a number of cases.
An example case might be where a market order (or any order for that matter) should be capped so as not to take more than some % of the available volume. It may be generally useful to have an easily accessible metric/summary of volume available on the book.
Suggested approach would be to:
base_quantity
of the newLeaf_Node
postedOut.base_size
each time an Out is generatedThe text was updated successfully, but these errors were encountered: