Pack OrderIntent flags into a single byte - #116
Merged
kaze-cow merged 12 commits intoAug 26, 2026
Merged
Conversation
kaze-cow
marked this pull request as ready for review
August 24, 2026 13:09
fedgiac
reviewed
Aug 25, 2026
Contributor
There was a problem hiding this comment.
This PR would have a very natural split: the introduction of the flag encoding and then introducing the new flag for on-chain orders. Not having this makes the reviewing process longer imho. I reviewed the file interface/src/data/intent.rs for now, which mostly involves the new flag approach (which makes sense to me overall). Will review the rest once the comments are addressed.
Also, something I don't see discussed and I didn't reach in the review: what happens if an order is reclaimesd in the middle of a settlement?
`kind` and `partially_fillable` each occupied a whole byte of the encoded intent, and each needed its own range check on decode. Fold both into one flags byte instead: `partially_fillable` takes the most significant defined bit, `kind` the next one down, and every remaining bit is reserved and must be zero. `OrderIntent` keeps the idiomatic representation — an `OrderKind` enum and a `bool` — so callers are unaffected. Only the wire format and the validation change: a single mask check now rejects any byte carrying an undefined bit, which keeps the encoding injective and so keeps order UIDs unique. `EncodedOrderIntent::SIZE` goes 150 -> 149 and `EncodedOrderAccount::SIZE` 201 -> 200. This is a BREAKING CHANGE to the `OrderIntent` encoding: it repurposes existing bytes, so it moves every order PDA and changes every order UID. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kaze-cow
force-pushed
the
kaze/sc-288-on-chain-orders-should-be-reclaimable-when-order-is
branch
from
August 26, 2026 08:08
d00b0db to
dd787a3
Compare
kaze-cow
changed the title
ReclaimOrder of completed orders before expiryOrderIntent flags into a single byte
should accept flags to allow for covering the edge cases
…orders-should-be-reclaimable-when-order-is
fedgiac
approved these changes
Aug 26, 2026
fedgiac
left a comment
fedgiac
left a comment
Contributor
There was a problem hiding this comment.
Looks good after the merge!
| EncodedOrderIntent::WIDTH_PARTIALLY_FILLABLE, | ||
| size_of_val(&intent.partially_fillable) | ||
| EncodedOrderIntent::WIDTH_FLAGS, | ||
| // in truth if there was a problem here it would actually cause a compilation error |
kaze-cow
deleted the
kaze/sc-288-on-chain-orders-should-be-reclaimable-when-order-is
branch
August 26, 2026 12:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fold the encoded
OrderIntent'skindandpartially_fillableinto a singleflags byte.
Split out of the reclaim work in #116's original scope, as suggested in
#116 (review).
The follow-up that introduces the
created_on_chainflag and the early-reclaimbehaviour is stacked on top of this branch in #122 .
Motivation
kindandpartially_fillableeach took a whole byte of the wire format andeach needed its own range check on decode. Both carry a single bit of
information, so a flags byte replaces two validated bytes with one, and leaves
room for the flags we know are coming.
Implementation
partially_fillabletakes the most significant defined bit,kindthe next onedown (
Sell= 0,Buy= 1). Every remaining bit is reserved and must be zero.OrderIntentkeeps the idiomatic representation — anOrderKindenum and abool— so callers are unaffected. Only the encoding and its validation change.EncodedOrderIntent::SIZEgoes 150 → 149 andEncodedOrderAccount::SIZE201 → 200.
This is a BREAKING CHANGE for the
OrderIntentencoding because it repurposesexisting bytes, and therefore it modifies the location of the order PDA and
changes the hash of all orders.
Testing Plan
The existing codec tests carry over to the new representation, plus:
every_flag_owns_a_distinct_bitpins that each flag occupies one bit, that notwo flags share a bit, that they run from the most significant defined bit
down, and that together they are exactly
FLAGS_MASK.decode_accepts_defined_flag_bits_onlywalks all 256 flag bytes and checkseach one is either rejected or decodes to the expected
kindandpartially_fillable.rejects_reserved_flag_bitsis the property-based counterpart,and
bytes_roundtrippins that any accepted byte string re-encodes to itself.uid_digest_regressionandencoding_regressionare updated for the newencoding.