Cross-program invocation (CPI) addresses the limitations of confined application containers. Traditionally, applications were developed and packaged to include all necessary functionality, isolating them from others. This approach often led to extended development cycles, minimal code reuse, and vulnerabilities impacting entire applications. However, CPI enables Solana developers to transcend these constraints by building modular applications that interact seamlessly with each other.

What is CPI?

CPI is a direct call from one program to another. It invokes another program’s instructions, which perform a similar function to API endpoints. Programs expose instructions to the network and a CPI, which results in what is essentially an API internally invoking another API. This turns the Solana ecosystem into a giant network of APIs, providing abundant developer resources.

The flow looks like this: 

When a program initiates a CPI to another program, the signer privileges from the initial transaction invoking Program A (the caller) extend to Program B (the callee). Program B (the callee) can make CPIs to other programs with a maximum depth of four CPIs, while signer privileges extend to the subsequent callee programs. This authorizes callees to “sign” on behalf of the Program Derived Address (PDA) derived from its program ID.

What are the implications? 

CPIs enable a direct call from one program to another, which is essential for building complex decentralized apps (dApps). They allow developers to create modules of code that are invoked by different programs. This code can be reused, which simplifies the development process as developers leverage existing programs rather than building from scratch. That’s only part of it, though. Modules composed together can work together, share data, and offer combined services. This enables the creation of complex decentralized ecosystems where dApps build rich tapestries of functionality.

Example

The following example shows a lending pool program from a DeFi dApp that manages core lending and borrowing logic. The program invokes a Token program and a cToken program, which mint tokens to the user’s account.

The invoke_signed function can also be used when a program’s invocation requires a PDA along with the necessary seeds to derive the PDA of the calling program.

This modular structure allows each program to be updated or replaced independently, providing flexibility and maintainability. This is a simplified example for demonstration purposes. In a real-world scenario, you would need to implement more robust logic, error handling, and security measures. Additionally, you would use the Solana Program Library (SPL) for standard token operations and the Anchor framework to simplify Solana program development. 

Considerations

While CPIs present exciting possibilities, there are a few factors to consider before deploying them. This includes resource limitations. CPIs add to the overall computation cost, so programs must be optimized according to Solana limitations. Programs must also carefully manage account ownership and permissions to ensure they have the necessary access rights for the invoked operations. Finally, proper error handling is crucial to ensure that failures in CPIs do not lead to unintended consequences.