Understanding Solana CPIs: Cross-Program Invocation Tutorial

Anchor simplifies CPI implementation through type-based account validation and CPI context builders. Different account types enforce constraints: 'signer' requires transaction signing, 'account' enables deserialization checks, and 'program' validates program IDs. For CPI, specifying the program account with the correct type enables Anchor's automatic CPI functionality. PDA constraints can be added via account brackets with seeds arrays and bump specifications, enabling deterministic verification of PDA derivation properties.

Smart contract security extends to interactions between contracts and cryptographic authentication. Re-entrancy attacks exploit recursive function calls between contracts, hijacking execution flows to drain funds repeatedly. Replay signature attacks copy valid transactions across networks, stealing funds by exploiting identical signatures. EIP-155 adds network identifiers to prevent this, but meta-transactions remain vulnerable requiring custom developer protections. These inter-contract vulnerabilities demonstrate how smart contract security requires understanding both execution patterns and cryptographic protocols.

Three critical vulnerability patterns demonstrate common smart contract risks: (1) Improper input validation in Getcoin's bounty system allowed attackers to steal the entire contract balance by exploiting minimum threshold requirements, (2) Melonport's emergency redeem function accepted arbitrary contract addresses implementing ERC-20 functions without verification, enabling arbitrary code execution, and (3) Melonport's emergency function didn't verify users requested proportional shares, allowing theft of entire assets. These vulnerabilities show how simple validation errors and improper function design can lead to catastrophic losses.

This video presents several underappreciated smart contract attack vectors that auditors often overlook: (1) Call data higher-order bits vulnerability in Solidity <0.8, where extra bits in call data can alter parameter values; (2) Call data malleability, where appending data to valid call data creates different hashes while bypassing duplicate checks; (3) Gas griefing attacks exploiting EIP-150's 63/64 gas limit for subcalls, allowing partial transaction execution while critical operations fail silently; (4) Gas exhaustion attacks using return data copy to consume gas and prevent transaction completion; (5) Read-only reentrancy, where view functions return different values on multiple calls due to gas consumption; (6) Metamorphic contracts that use self-destruct to upgrade code on the same address, maintaining state while changing behavior; (7) Cross-platform attacks combining web vulnerabilities like XSS with smart contract flaws; and (8) Static call state staleness, where failed static calls leave stale memory values that subsequent code may incorrectly use.

This comprehensive section establishes fundamental security patterns essential for secure Solana development. It covers signer authorization requiring explicit verification beyond transaction signing, arbitrary CPI attacks exploiting unchecked program IDs during cross-program invocations, duplicate mutable accounts causing unexpected behavior when identical accounts serve as both source and destination, ownership checks ensuring accounts have expected owners, PDA privileges controlling access to token vaults, revival attacks exploiting incomplete account closure, reinitialization attacks resetting initialized accounts to defaults, account reloading after CPI ensuring updated balances, and type cosplay attacks exploiting unchecked discriminators to deserialize unrelated account structures. These principles form the core security discipline for preventing unauthorized access, data corruption, and asset theft in Solana programs.

This segment explores the concept of DeFi composability, often called 'money legos.' The instructors explain how developers can combine multiple DeFi protocols to create new applications, taking existing primitives like tokens, swaps, and lending protocols and combining them. They mention the DeFi Minimal repository as a resource containing example smart contracts for swaps, lending, borrowing, and staking. The tutorial emphasizes that this composability is a fundamental feature of the DeFi ecosystem.

Jupiter is a DEX and liquidity aggregator founded in May 2021 by co-founders of Meteora DEX. It aggregates liquidity from multiple DEXes including CLBs and AMMs, finding optimal swap routes that split trades across exchanges in a single transaction. This solves DeFi's liquidity fragmentation problem. Jupiter offers limit orders, DCA strategies, perpetual futures with 100x leverage, and lending features. In January 2024, it launched the JUP token via airdrop with 700 million distributed to nearly a million wallets. The protocol announced using 50% of fees to buy back JUP for a long-term reserve. JUP hit $2 at launch but has been down 76% since, with a conservative target of $3 representing a 6x return.

DeFi's biggest advantage is composability - the ability to combine different protocols in a single transaction. Users can combine a DEX with a borrow/lending protocol to execute margin trades without moving money between exchanges. Yield farming incentivizes adoption by distributing tokens to users who provide liquidity. The theory is that if a protocol is worth tens of billions, giving away value to users is reasonable. However, returns can be extremely high (1000%+ annually), raising sustainability questions. The optimistic view is protocols give away value to incentivize adoption. The pessimistic view is that returns are unsustainable because token prices may crash as fast as yield is paid out, tokens may be hyperinflated, or the project may be a scam. SushiSwap exemplified both the potential and risks - it gained massive popularity through yield farming on Uniswap, but when the founder took the treasury for himself, the token crashed dramatically and the community turned on the project.

Composability (DeFi) refers to the ability to build applications on top of existing protocols, similar to how software applications are built on operating systems. Users with basic knowledge can access protocols like lending platforms through interfaces, while those with deeper understanding can create complex strategies by combining multiple protocols. This creates a tiered ecosystem where beginners can participate while advanced users build sophisticated automated systems.

The Solana DeFi ecosystem includes multiple decentralized exchanges and platforms: Raydium (built on Serum), Orca, Jupiter (DEX aggregator), and Serum DEX. These platforms offer features like liquidity pools, staking, and token swapping. The speaker mentions that Raydium and Orca are among the top DEXs on Solana, providing users with various options for trading and providing liquidity.

This extensive section covers two primary testing methodologies for Solana programs. For Rust testing, the program-test crate provides a powerful framework without requiring the Solana validator, offering manual control over accounts and system variables, immediate CLI log visibility, and parallel test execution. The complete workflow involves creating #[tokio::test] functions, initializing ProgramTest with program metadata, adding external programs from fixtures, creating instructions and transactions, and processing them with desired commitment levels. For TypeScript testing, Anchor framework serves as the standard approach, generating IDL and types files that enhance testing experience. Anchor test starts the Solana validator, storing logs and ledger in the anchor folder with graphical explorer capabilities for debugging. Both approaches have trade-offs: Rust offers more control while TypeScript provides broader ecosystem familiarity. The section concludes by introducing the anchor.toml manifest for configuring test environments.

Anchor enables automated testing by spinning up local validators, compiling programs, deploying, and running test cases. Unit tests verify individual program functions through assertions on expected outcomes. Test-Driven Development (TDD) involves writing tests before implementation, though AI tools may generate tests that pass without properly validating requirements. Effective testing requires understanding that good tests should fail initially and only pass when requirements are correctly implemented.

Anchor simplifies testing through workspace management and Mocha framework, using describe-it patterns with BN objects for numeric comparisons. Tests call program.rpc.function_name() with appropriate accounts and arguments. The comparison reveals that traditional Solana requires monolithic process_instruction functions with manual serialization, deserialization, and security checks. Anchor replaces this with separate instruction functions, automatic serialization/deserialization, and built-in security verification. The IDL generation eliminates redundant frontend type definitions, reducing development complexity from hundreds of lines of boilerplate to clean, maintainable architecture.

Anchor test setup involves initializing the provider via `anchor.AnchorProvider.local()` and obtaining a program instance from `anchor.workspace`. Access the default wallet through `.wallet.publicKey` and generate additional test wallets as needed. The complete test flow includes: generating seeds from public keys, deriving PDA addresses using `findProgramAddress`, sending transactions via `program.methods`, fetching updated account data, and writing assertions to validate results. Key comparisons use PublicKey equality methods rather than direct operators.