@eco-incorp/sauce/svm is the Solana side: the client (createSauceSvmClient), clusters, PDAs, account resolution against the compiler’s account manifest, Kitchen and engine instructions, transactions and sending, token accounts, and compute planning for @sauce/router’s Solana venues. @eco-incorp/sauce/svm/engine exports the engine’s wire format and instruction builders, @eco-incorp/sauce/svm/verify verifies settle programs and engine CPI data, and @eco-incorp/sauce/svm/engine-artifacts (Node only) returns file paths to the packaged engine and Kitchen binaries.
@eco-incorp/sauce.
svmSettleSource
Function · @eco-incorp/sauce/svm
The SVM settle program text for escrowCount escrows - the SVM twin of
the EVM settle.sauce.ts, statement for statement, differing only where the VM forces it (see this
module’s header). Generated rather than static because the escrow count is a compile-time property
on SVM; the returned text is exactly what gets compiled.
svmSettleRefs
Function · @eco-incorp/sauce/svm
The account refs a generated program declares, in manifest order, for escrowCount escrows:
tokenProgram0, tokenProgram1, then per escrow escrow_i (source, writable), mint_i
(read for decimals), dest_i (recipient ATA, writable) - with the shared owner (signer) landing
right after escrow 0’s group: the order svmSettleSource declares main’s parameters in.
SVM_MAX_ESCROWS
Variable · @eco-incorp/sauce/svm
Upper bound on generated escrows. Each escrow attaches THREE accounts - escrow_i (source),
mint_i (read for decimals by TransferChecked), dest_i (the recipient’s ATA) - on top of the
two token-program slots and the shared owner. So N escrows is 3N + 3 accounts; a large N needs
an address lookup table to fit the transaction, which is why this is capped.