Solana struggles with composability due to its account model and transaction structure. Unlike Ethereum, where users send calldata to smart contracts, Solana requires sending complete account details for each instruction. This makes transactions heavier and complicates data sharing between instructions. For instance, while a two-hop swap on Solana is technically composable, the complexity pales in comparison to an Ethereum transaction that can execute a 50-hop swap with minimal overhead. The author argues that current design choices hinder Solana’s potential for complex transactions. To address these limitations, the article proposes three solutions. First, implementing Validator-Side Account Lookups could optimize transaction sizes without making them larger. Second, allowing Top-Level Return Value Passing would enable smoother transitions between instructions, addressing issues where leftover tokens from one swap complicate subsequent operations. Lastly, Native Bundling could enhance transaction composability. The author acknowledges that these ideas push against Solana's foundational principle of keeping validators simple and fast, but they could significantly reduce execution latency. The piece also highlights the difference in how instructions are treated in Solana. Currently, instructions do not allow individual failures and do not pass return values, which forces developers to create complex workarounds. In contrast, Ethereum’s Multicall allows multiple calls to be combined into one transaction, increasing efficiency and reliability. The author suggests adopting a similar model for Solana to improve its composability and user experience. Overall, the proposed changes could lead to a more flexible and efficient transaction model, enhancing Solana's usability in complex financial operations.