Push proceeds to users in FinalizeSettle#62
Conversation
…' into push-funds-to-user-parsing
…cessing-in-begin-settle
…h-funds-to-user-processing-in-finalize-settle
…' into push-funds-to-user-parsing
…cessing-in-begin-settle
…h-funds-to-user-processing-in-finalize-settle
…cessing-in-begin-settle
…h-funds-to-user-processing-in-finalize-settle
…h-funds-to-user-processing-in-finalize-settle
… -> rejects_push_if_buffer_does_not_match_mint
| let (state_pda, state_bump) = Address::find_program_address(&state_pda_seeds(), program_id); | ||
| if state_pda_account.address() != &state_pda { | ||
| return Err(SettlementError::StateAccountMismatch.into()); | ||
| } |
There was a problem hiding this comment.
I liked this fn a lot.
I believe after #49 it will use create_program_address instead of find_program_address, is that right?
There was a problem hiding this comment.
Yes, then there won't be any reason to run the search loop!
| /// Validate that `token_program_account` is the legacy SPL Token program, which | ||
| /// every settlement transfer is issued against. | ||
| #[must_use = "ignoring the output may lead to an unintended on-chain state"] | ||
| fn validate_token_account(token_program_account: &AccountView) -> ProgramResult { | ||
| if token_program_account.address() != &SPL_TOKEN_PROGRAM_ID { | ||
| return Err(ProgramError::IncorrectProgramId); | ||
| } | ||
| Ok(()) | ||
| } | ||
|
|
There was a problem hiding this comment.
Nothing critical, but I this looks like a good spot to call pinocchio_token::state::Account::from_account_view, which also validates the account data.
I assume any invalid token account would still cause a revert during the transfer call anyway, so we'd just be catching the error earlier.
There was a problem hiding this comment.
Renamed this function to stress that this validates only the token program address: bf1b683.
The from_account_view already existed in the current code, so I implemented the suggestion by moving the check from the order processing to this function: 4192b1e.
The price for this is that we go through all orders twice instead of only once, but maybe it isn't too bad.
I didn't include in the PR because I wasn't sure this is the change you intended. WDYT?
There was a problem hiding this comment.
Looks good, I don't have a strong opinion about where the validation takes place.
Ideally we'd iterate only once, but I agree it's not a huge gain.
3 participants
Push each order's proceeds out of the buffers in
FinalizeSettle.This is the final part of the settlement push flow. The previous PR taught
BeginSettleto pair each settled order with exactly one push and check the push pays the order's buy token account, but nothing moved yet. HereFinalizeSettleactually performs the transfers.What
push_fundsdoesBeginSettlealready guarantees, for the paired finalize, that the push count matches the order count and that each push's destination is the right buy token account, and the counterpart check guarantees that begin ran.So the only things left for
FinalizeSettleto check is that:And naturally, it needs to actually send funds.
How to test
finalize_settle_pushes.rsmoves from asserting that pushes merely parse to asserting they actually pay: single-order, several orders sharing one buffer, and several orders drawing from different buffers, each checking both the destinations' credited balances and the buffers' debited balances. It also covers new edge cases.