5/5
## Understanding Cross Program Invocations (CPI) on Solana At the heart of the Solana ecosystem lies the concept of **Composability**. This is the ability for different decentralized applications (dApps) to interact, build upon one another, and function like interconnected building blocks. The technical mechanism that makes this possible is known as **Cross Program Invocation (CPI)**. A CPI occurs when one executing program invokes the instructions of another program directly. To visualize this, consider a standard Web2 analogy: Imagine a server-side API endpoint that, during its execution, calls a second internal API endpoint to retrieve data or perform a specific task. In Solana, a CPI functions similarly. If you have ever built a "Counter Program" that initializes an account, your program likely called into the native **System Program**. That interaction was a Cross Program Invocation. ## Privilege Extension: How Permissions Transfer When dealing with blockchain transactions, security and authority are paramount. A critical rule governing CPIs is **Privilege Extension**. This concept defines how authority (signing capability) and access rights (writability) are passed from a calling program (**caller**) to the program being invoked (**callee**). ### The Transaction Flow Consider a scenario involving a user and two programs: **Program A** and **Program B**. 1. **The User's Role:** A user (Wallet Account) signs a transaction to interact with **Program A**. In doing so, the user declares specific accounts as **Signers** (proving authority) and **Writable** (allowing modification). 2. **The Caller (Program A):** Program A begins executing. It holds the permissions granted by the user. 3. **The CPI (A invokes B):** Program A decides to invoke an instruction on **Program B**. ### Inherited Permissions When Program A performs the CPI, it can pass the accounts it received to Program B. Crucially, **Program B receives these accounts with the original permissions intact.** * If an account was marked as a **Signer** for Program A, it remains a **Signer** for Program B. * If an account was marked as **Writable** for Program A, it remains **Writable** for Program B. This means Program B can modify the user’s account or perform privileged actions because the necessary authority was extended from the User $\rightarrow$ Program A $\rightarrow$ Program B. ### PDA Signing While user signatures are common, programs often need to sign for themselves using **Program Derived Addresses (PDAs)**. If Program A signs on behalf of its own PDA, those signer privileges also extend to the callee program. This allows for complex, autonomous interactions between contracts without requiring the user to manually sign a transaction for every single program in the chain. ## Maximum CPI Depth While CPIs allow for powerful chaining of logic, the Solana protocol enforces a limit on how many nested calls can occur within a single transaction. This is known as the **Maximum CPI Depth**. Currently, the instruction stack height is capped to prevent infinite loops and manage computational resources. ### The Stack Limit The current maximum depth is set to **4**. To illustrate this limit, consider a chain of dependencies: 1. Program A calls Program B (Depth 1) 2. Program B calls Program C (Depth 2) 3. Program C calls Program D (Depth 3) 4. Program D calls Program E (Depth 4) In this scenario, Program E reaches the limit of the stack. It can execute its own logic, but it cannot make a further CPI to a theoretical "Program F." ### Technical Constraints In the Solana source code and documentation, this limit is defined by the following constant: ```rust MAX_INSTRUCTION_STACK_DEPTH ``` Developers should note that the value of `4` is the current protocol constraint. However, as Solana evolves and network capabilities change, this depth limit may be adjusted in future updates. ## Summary Cross Program Invocations are the glue that holds the Solana ecosystem together. By understanding **Privilege Extension**, developers ensure their programs can securely act on behalf of users across multiple contracts. Simultaneously, being aware of **CPI Depth** ensures that architecture remains efficient and within the bounds of the protocol's computational limits.
At the heart of the Solana ecosystem lies the concept of Composability. This is the ability for different decentralized applications (dApps) to interact, build upon one another, and function like interconnected building blocks. The technical mechanism that makes this possible is known as Cross Program Invocation (CPI).
A CPI occurs when one executing program invokes the instructions of another program directly.
To visualize this, consider a standard Web2 analogy: Imagine a server-side API endpoint that, during its execution, calls a second internal API endpoint to retrieve data or perform a specific task. In Solana, a CPI functions similarly. If you have ever built a "Counter Program" that initializes an account, your program likely called into the native System Program. That interaction was a Cross Program Invocation.
When dealing with blockchain transactions, security and authority are paramount. A critical rule governing CPIs is Privilege Extension. This concept defines how authority (signing capability) and access rights (writability) are passed from a calling program (caller) to the program being invoked (callee).
Consider a scenario involving a user and two programs: Program A and Program B.
The User's Role: A user (Wallet Account) signs a transaction to interact with Program A. In doing so, the user declares specific accounts as Signers (proving authority) and Writable (allowing modification).
The Caller (Program A): Program A begins executing. It holds the permissions granted by the user.
The CPI (A invokes B): Program A decides to invoke an instruction on Program B.
When Program A performs the CPI, it can pass the accounts it received to Program B. Crucially, Program B receives these accounts with the original permissions intact.
If an account was marked as a Signer for Program A, it remains a Signer for Program B.
If an account was marked as Writable for Program A, it remains Writable for Program B.
This means Program B can modify the user’s account or perform privileged actions because the necessary authority was extended from the User Program A Program B.
While user signatures are common, programs often need to sign for themselves using Program Derived Addresses (PDAs). If Program A signs on behalf of its own PDA, those signer privileges also extend to the callee program. This allows for complex, autonomous interactions between contracts without requiring the user to manually sign a transaction for every single program in the chain.
While CPIs allow for powerful chaining of logic, the Solana protocol enforces a limit on how many nested calls can occur within a single transaction. This is known as the Maximum CPI Depth.
Currently, the instruction stack height is capped to prevent infinite loops and manage computational resources.
The current maximum depth is set to 4.
To illustrate this limit, consider a chain of dependencies:
Program A calls Program B (Depth 1)
Program B calls Program C (Depth 2)
Program C calls Program D (Depth 3)
Program D calls Program E (Depth 4)
In this scenario, Program E reaches the limit of the stack. It can execute its own logic, but it cannot make a further CPI to a theoretical "Program F."
In the Solana source code and documentation, this limit is defined by the following constant:
Developers should note that the value of 4 is the current protocol constraint. However, as Solana evolves and network capabilities change, this depth limit may be adjusted in future updates.
Cross Program Invocations are the glue that holds the Solana ecosystem together. By understanding Privilege Extension, developers ensure their programs can securely act on behalf of users across multiple contracts. Simultaneously, being aware of CPI Depth ensures that architecture remains efficient and within the bounds of the protocol's computational limits.
A conceptual guide to Understanding Cross Program Invocations (CPI) - Uncover the core mechanism of composability that allows Solana programs to interact as building blocks. Master the flow of privilege extension for transferring account authorities and understand the protocol limits imposed on the maximum instruction stack depth.
Previous lesson
Previous
Next lesson
Next
Course Overview
About the course
Native Rust & Anchor framework
PDAs, CPIs, and SPL Tokens
DeFi builds: oracles, auctions, AMMs
Last updated on January 12, 2026
Rust Developer
SolanaDuration: 8min
Duration: 23min
Duration: 4min
Duration: 2min
Duration: 4min
Duration: 11min
Duration: 4min
Duration: 0min
Duration: 0min
Course Overview
About the course
Native Rust & Anchor framework
PDAs, CPIs, and SPL Tokens
DeFi builds: oracles, auctions, AMMs
Last updated on January 12, 2026