Conversation
no need to distinguish when resolving token information
Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>
Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>
Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>
Avoids creating a fresh JSON-RPC client (with its own request-id counter) on every subcommand call, per fedgiac's review comment.
Context::from_args now reads the keypair file eagerly and stores the Keypair, rather than re-reading it from disk on every subcommand invocation, per fedgiac's review comment.
Use the interface crate's canonical PDA derivation instead of hand-rolling Pubkey::find_program_address with the raw seed, so this stays correct if the seed scheme changes. Per fedgiac's review comment.
The sell-side doc singled out the SOL case while the buy-side phrased its default generically; use the same generic phrasing for both, per fedgiac's review comment.
per fedgiac's review comment: the long_about text implied the command performs the trade, when it only submits an order intent on-chain.
`tokens` was a misnomer since this positional can also hold an amount string, and its doc referred to "above" which doesn't render in contexts like tooltips/shell completion. Per fedgiac's review comment.
Two #[command(long_about)] attributes on one struct meant only the last was ever used, and both `cow sell --help` and `cow buy --help` showed the same text (fedgiac's report). Root cause went further: the enum variants' doc comments on Commands::Sell/Buy set both the short about *and* the long_about, clobbering the flattened args struct's own long_about entirely, so neither variant's help text ever rendered. Fix: use a single unified long_about on BuyOrSellArgs describing both sell and buy forms, and switch the enum variants to explicit #[command(about = "...")] (short only) so it no longer overrides long_about.
Per fedgiac's review comment: a 5-element tuple made call sites hard to read; a struct with named fields makes the parse/execute boundary self-explanatory.
only downside with the wya its setup now is technically parse is asynchronous, but the execute looks pretty nice and relatively straightforward
Switches every hand-rolled u16/u32/u64 field currently stored/sent big-endian to little-endian: OrderIntent's sell_amount/buy_amount/valid_to, OrderAccount's amount_withdrawn/amount_received, and the BeginSettle/ FinalizeSettle counterpart-index fields (finalize_ix_index/begin_ix_index). Little-endian is the Borsh/Anchor convention; this is a first step toward Anchor-compatible on-chain data so external tooling (indexers, explorers) can read it without bespoke decoding. This changes the order UID hash and the wire format of CreateOrder/BeginSettle/FinalizeSettle - not backwards compatible with any existing on-chain state or off-chain signers. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Describes the settlement program's instructions/accounts/types for IDL-driven tooling (e.g. Solscan), since this is a native/Pinocchio program rather than an Anchor program and has no generated IDL. Several spots can't be fully expressed in the IDL grammar and are documented inline via `docs` fields instead: BeginSettle's dynamically-shaped tail (order count/bumps/transfer counts/pull amounts, which have no Borsh-expressible layout), and order_pda's PDA seed (a sha256 hash of the whole intent argument, not a plain field/account reference). Draft: we don't yet have a cheap way to validate that this IDL is actually correct - e.g. that it can build parsable/successful transactions for each instruction, and successfully parse real account data. That validation is intended as fast-follow work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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
programs/settlement/idl/cow_settlement.json) describing the settlement program's instructions/accounts/types, for IDL-driven tooling (e.g. Solscan). This program is native/Pinocchio, not Anchor, so there's no generated IDL to start from.docsfields instead:BeginSettle's dynamically-shaped tail (order count / bumps / transfer counts / pull amounts) has no Borsh-expressible layout (no length prefixes, and a trailing array whose length is the sum of an earlier array).order_pda's PDA seed issha256(intent_bytes)— a hash of the whole instruction argument, not a plain field/account reference the PDA-seed grammar can point at.create_buffer's account list is padded to a chosen maximum (15) of indexed(buffer_pda_i, mint_i)pairs, since the real instruction accepts an unbounded number of them via remaining accounts.Stacked on #64 (discriminators), which is itself stacked on #63 (little-endian encoding) — the IDL only makes sense once both land.
Draft — why
We don't yet have a cheap way to actually validate this IDL against the real program: e.g. that it can build parsable/successful transactions for every defined instruction, and successfully parse real account data pulled from a running program. That validation is planned as fast-follow work; marking this draft until we have it.
Test plan
python3 -m json.tool)🤖 Generated with Claude Code