Add single-byte account discriminators via a SettlementAccount enum#64
Open
kaze-cow wants to merge 4 commits into
Open
Add single-byte account discriminators via a SettlementAccount enum#64kaze-cow wants to merge 4 commits into
kaze-cow wants to merge 4 commits into
Conversation
Prefixes every account this program owns with real storage with a
1-byte discriminator, mirroring how SettlementInstruction already
identifies instructions:
- New SettlementAccount enum (interface/src/lib.rs), following the same
num_enum::TryFromPrimitive pattern as SettlementInstruction. Discriminators
start at 128 and increment per account type, kept distinct from the
instruction discriminators (0-4).
- OrderAccount: discriminator 128 (OrderAccount), account grows
199 -> 200 bytes.
- Settlement state PDA: new interface::data::state module, discriminator
129 (SettlementState), account grows 0 -> 1 byte (written on Initialize).
An Anchor-style IDL's `discriminator` field can be any byte length, not
just Anchor's own 8-byte sha256("account:...") convention, so a single
byte is enough for IDL-driven tooling (e.g. Solscan) to identify the
account type while costing far less rent than an 8-byte discriminator.
Also adds a hand-written Anchor-compatible IDL (programs/settlement/idl/
cow_settlement.json) describing the program's instructions/accounts/types.
Since this is a native/Pinocchio program rather than an Anchor program,
several spots can't be fully expressed in the IDL grammar (BeginSettle's
dynamically-shaped tail, order_pda's hashed PDA seed) and are documented
inline via `docs` fields instead.
Builds on the little-endian encoding from the previous PR.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The hand-written IDL doesn't need to land together with the code changes it describes; splitting it out so it can be reviewed and iterated on separately (and marked draft while we figure out how to validate it). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 tasks
kaze-cow
commented
Jul 8, 2026
Comment on lines
+182
to
+184
| if *discriminator != EncodedOrderAccount::DISCRIMINATOR { | ||
| return Err(ProgramError::InvalidAccountData); | ||
| } |
Contributor
Author
There was a problem hiding this comment.
this check may be superfluous if we decide we want to go more efficient.
2 tasks
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
1 participant
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.
Summary
SettlementInstructionalready identifies instructions.SettlementAccountenum (interface/src/lib.rs), following the samenum_enum::TryFromPrimitivepattern asSettlementInstruction. Discriminators start at 128 and increment per account type, kept visually/numerically distinct from the instruction discriminators (0-4).OrderAccount: discriminator 128, account grows 199 -> 200 bytes.interface::data::statemodule, discriminator 129, account grows 0 -> 1 byte (written onInitialize).discriminatorfield can be any byte length — it doesn't have to be Anchor's own 8-bytesha256("account:...")convention — so a single byte is enough for IDL-driven tooling (e.g. Solscan) to identify the account type, while costing far less rent than an 8-byte discriminator would.Builds on #63 (little-endian encoding) — based on that branch since decoding an account now also depends on its fields already being little-endian.
The hand-written IDL that documents this program (originally included here) now lives in its own separate draft PR, stacked on top of this one.
Test plan
just build-verifiedto rebuild the on-chain.socargo test --workspace— all tests pass, including new discriminator-rejection tests andSettlementAccountenum testsjust fmt-checkpasses🤖 Generated with Claude Code