Solidity's external calls (call, delegatecall) are powerful but perilous, enabling dynamic interaction with any on-chain contract. This flexibility underpins DeFi composability—witness the billions in TVL across protocols like Aave and Uniswap V3—but introduces reentrancy and unchecked return data risks. The infamous DAO hack, resulting in a 3.6M ETH loss, was a direct consequence of a vulnerable external call pattern, cementing the need for checks-effects-interactions and tools like OpenZeppelin's ReentrancyGuard.
LABS
Comparisons
Solidity's external call safety vs Rust's FFI safety vs Move's cross-module calls
A technical analysis comparing the security models and inherent risks of invoking external code across Solidity (EVM), Rust (Solana/Sealevel), and Move (Aptos/Sui). Focus on reentrancy, FFI hazards, and dependency management for protocol architects.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Critical Risk of External Code Execution
How Solidity, Rust, and Move architecturally manage the security of cross-boundary interactions, a primary vector for exploits.
Rust's Foreign Function Interface (FFI) for blockchain clients (e.g., Solana, NEAR) allows safe integration with non-Rust libraries like C for performance-critical operations. However, it shifts the security burden entirely to the developer, requiring meticulous unsafe blocks and manual memory management. This is optimal for building high-throughput validators (Solana's 50k+ TPS leverages such optimizations) but is ill-suited for smart contract logic where a single memory safety bug can be catastrophic, as seen in early Solana program exploits.
Move's cross-module calls are fundamentally different: they are static, type-safe, and governed by the VM's resource model and bytecode verifier. Calls are to published modules within the same address, not arbitrary code. This design, used by Aptos and Sui, eliminates reentrancy by construction and ensures strong resource isolation, but at the cost of dynamic composability. Protocols must be co-published and upgraded in lockstep, a trade-off for guaranteed safety.
The key trade-off: If your priority is maximal composability and a mature ecosystem for DeFi, Solidity's model—with rigorous guardrails—is the path. If you need absolute safety guarantees and formal verification potential for asset-centric logic (e.g., a stablecoin or NFT standard), Move's architecture is superior. Rust's FFI is a specialist tool: choose it when building infrastructure requiring peak performance outside the VM, not for mainstream dApp logic.
tldr-summary
EXTERNAL CALL SAFETY COMPARISON
TL;DR: Core Security Postures at a Glance
How three major smart contract languages handle the critical attack vector of cross-boundary execution.
01
Solidity: Explicit but Permissive
Explicit call, delegatecall, and staticcall syntax forces developers to consciously choose the interaction type. However, it's permissive by default, requiring manual security patterns like Checks-Effects-Interactions (CEI) and reentrancy guards. This matters for developers building on EVM chains (Ethereum, Polygon, Arbitrum) who need flexibility but must be vigilant against exploits like the DAO hack.
02
Rust (via FFI): Unsafe by Definition
Foreign Function Interface (FFI) blocks are explicitly marked unsafe, creating a clear audit boundary. The compiler enforces that all external C or system calls are contained within these blocks. This matters for high-performance blockchain clients (Solana programs, NEAR contracts) and infrastructure where low-level control is critical, but it shifts the security burden entirely to the developer's implementation of the unsafe block.
03
Move: Ownership-Centric & Verifiable
Cross-module calls are just function calls within the same global state, governed by Move's strict ownership and linear type system. Resources cannot be duplicated or lost during a call. This matters for asset-centric applications on Aptos and Sui, as it eliminates entire classes of reentrancy and token accounting bugs by design, making security more verifiable at the VM level.
04
The Trade-off: Flexibility vs. Guarantees
- Solidity/Rust: Offer maximum flexibility for complex, cross-chain, or performance-critical logic but require rigorous manual auditing and pattern adherence.
- Move: Provides stronger compile-time and runtime guarantees for asset safety, simplifying secure development but within a more constrained, domain-specific paradigm. Choose based on whether your protocol's risk profile demands developer-controlled power or VM-enforced safety.
HEAD-TO-HEAD COMPARISON
Feature Matrix: External Call Security Models
Direct comparison of security guarantees and developer experience for cross-contract/cross-module interactions.
| Metric | Solidity (EVM) | Rust (Solana/Sealevel) | Move (Aptos/Sui) |
|---|---|---|---|
Default Reentrancy Protection | |||
Static Call Safety Verification | |||
Resource Ownership Model | Address-based | Account-based | Linear Types |
Gas Cost for External Call | ~21k gas base + logic | ~0.001 SOL (varies) | ~0.001 APT/SUI (varies) |
Primary Security Risk | Reentrancy, delegatecall | Invalid CPI, PDA derivation | Invalid public entry, type confusion |
Native Asset Transfer Safety | Manual checks required | Program-derived addresses | Built-in |
pros-cons-a
SAFETY & INTEGRATION COMPARISON
Solidity (EVM) External Calls: Pros and Cons
A technical breakdown of external call mechanisms across leading smart contract languages, highlighting key trade-offs for security, composability, and developer experience.
01
Solidity: Battle-Tested Composability
Mature ecosystem integration: Direct calls to any EVM address enable seamless interaction with 1000+ DeFi protocols like Uniswap and Aave. This is critical for DeFi composability and rapid prototyping. However, it relies on explicit developer diligence for reentrancy guards and gas limits, leading to vulnerabilities if mishandled.
$50B+
DeFi TVL on EVM
>1000
Integrated Protocols
02
Solidity: Gas-Cost Transparency
Predictable cost model: The gasleft() function and explicit gas stipends for .call() and .delegatecall() allow fine-grained control. This is essential for gas optimization in high-frequency trading bots or complex multi-step transactions. The trade-off is increased complexity and the risk of out-of-gas reverts for developers.
03
Rust (Solana/NEAR): Unsafe FFI Power
Direct system access: Foreign Function Interface (FFI) allows calling C libraries and OS functions, enabling high-performance oracles and custom cryptography. This is optimal for compute-intensive tasks off-chain. The major con is manual memory management and unsafe blocks, shifting the entire security burden onto the developer and audit team.
< 400ms
Solana Block Time
04
Rust (Solana/NEAR): Program-Defined Boundaries
Explicit account passing: Programs (smart contracts) must receive all accounts they interact with via parameters, enforced at the runtime level. This creates a clear audit trail for cross-contract calls on chains like Solana. The downside is boilerplate code and a steeper learning curve versus EVM's simple address calls.
05
Move (Aptos/Sui): Bytecode-Verified Safety
Static reference safety: The Move VM validates object ownership and reference permissions at the bytecode level before execution. This eliminates reentrancy and dangling reference bugs by design, making it superior for asset-centric applications like native tokens and NFTs. The limitation is reduced flexibility for arbitrary cross-module interactions.
06
Move (Aptos/Sui): Formal Resource Model
Linear type system: Resources (like coins) cannot be copied or implicitly discarded, ensuring double-spend protection is baked into the language. This is ideal for core financial primitives requiring maximum safety. The con is a paradigm shift for developers, requiring strict adherence to Move's resource-oriented programming model, which can hinder rapid integration with external, non-Move systems.
0
Major Reentrancy Hacks
pros-cons-b
EXTERNAL CALL SAFETY COMPARISON
Rust (Sealevel/FFI) and Move: Combined Pros and Cons
A direct comparison of how Solidity, Rust (via Sealevel/FFI), and Move handle the critical security challenge of cross-contract interactions. Each approach offers distinct trade-offs in safety, flexibility, and developer experience.
01
Solidity's External Call Safety
Pro: Battle-tested with explicit patterns. The call, delegatecall, and transfer functions are well-understood, with established best practices (e.g., Checks-Effects-Interactions pattern) to prevent reentrancy. This matters for developers building on EVM chains (Ethereum, Arbitrum, Polygon) who need to integrate with a massive existing ecosystem of contracts like Uniswap V3 or Aave.
Con: Runtime errors are common. Calls can fail silently or revert, requiring manual gas stipends and explicit error handling. The lack of type safety across contract boundaries is a major source of vulnerabilities, as seen in historic hacks.
02
Rust with Sealevel/FFI Safety
Pro: Compile-time and runtime guardrails. The Solana Sealevel runtime enforces cross-program invocation (CPI) with defined callee programs, preventing arbitrary calls. Combined with Rust's ownership model, this reduces entire vulnerability classes. This matters for high-performance DeFi or NFT protocols on Solana where security and speed are non-negotiable.
Con: Complex FFI for non-native programs. Interacting with programs not written in Rust (via Foreign Function Interface) introduces complexity and potential unsafety, pushing the burden onto the developer. The ecosystem tooling for secure FFI is less mature than EVM's battle-tested patterns.
03
Move's Cross-Module Call Safety
Pro: Built-in, verifiable safety. Move's resource-oriented model and linear types ensure assets cannot be duplicated or lost during cross-module calls. The bytecode verifier statically guarantees these properties. This matters for asset-centric applications on Sui and Aptos, where formal correctness for tokens and NFTs is paramount.
Con: Ecosystem lock-in and learning curve. The safety model is tightly coupled to the Move VM. Calling outside the Move ecosystem (e.g., to an Oracle) is not natively supported, and developers must learn a new paradigm distinct from Solidity/Rust.
04
Decision Summary: Which to Choose?
Choose Solidity's model if: Your priority is ecosystem integration and you have an experienced EVM team that can implement rigorous manual safeguards. Best for protocols where composability with existing DeFi legos is critical.
Choose Rust/Sealevel if: You need maximum performance with strong memory safety and are building primarily within the Solana ecosystem. Ideal for high-throughput applications where most dependencies are native Solana programs.
Choose Move if: Formal asset safety is your top requirement and you are building on a Move-based chain. Optimal for novel financial primitives where the correctness of asset movement is more important than broad, cross-chain composability.
LANGUAGE SECURITY
Technical Deep Dive: Attack Vectors and Mitigations
A critical analysis of how Solidity, Rust (via FFI), and Move handle the fundamental security challenge of cross-boundary calls, which are a primary source of exploits like reentrancy and data corruption.
Solidity is the most vulnerable by design. Its external calls are synchronous and can call back into the calling function before state changes are finalized, enabling classic attacks like The DAO hack. Mitigation requires manual patterns like Checks-Effects-Interactions. Rust's FFI and Move's cross-module calls are not inherently vulnerable; Rust's ownership model prevents concurrent mutable access, and Move's linear types and explicit acquires ensure state is not accessed mid-transaction.
CHOOSE YOUR PRIORITY
Decision Framework: Choose Based on Your Use Case
Solidity for DeFi
Verdict: The pragmatic, battle-tested standard for composability.
Strengths: The external call is the backbone of Ethereum's DeFi ecosystem, enabling seamless integration between protocols like Uniswap, Aave, and Compound. The explicit payable modifier and gas stipends allow for precise value transfer control. Security is managed through extensive tooling (Slither, MythX) and established patterns (Checks-Effects-Interactions).
Weaknesses: Reentrancy remains a critical, developer-managed risk. Failed calls only revert the immediate transaction, potentially leaving the system in an inconsistent state if not handled with patterns like pull payments.
Rust (Solana/NEAR) for DeFi
Verdict: High-performance but requires meticulous FFI management.
Strengths: FFI to the runtime (e.g., Solana's solana_program crate) provides raw speed and low latency, crucial for high-frequency DEX operations like Serum. Memory safety and the borrow checker prevent whole classes of vulnerabilities at compile time.
Weaknesses: Cross-program invocations (CPIs) are complex, requiring manual serialization and account list management. Errors in CPI can be silent, and the developer bears full responsibility for validating program-derived addresses (PDAs), a major source of exploits.
Move (Aptos/Sui) for DeFi
Verdict: Architecturally superior for asset safety, but ecosystem maturity lags.
Strengths: Cross-module calls are fundamentally safer. The type system treats assets as linear types that cannot be duplicated or discarded, eliminating the risk of accidental loss or inflation. The public(friend) visibility enables secure, compartmentalized composability within a protocol.
Weaknesses: The ecosystem is nascent. While the call model is safer, builders have fewer real-world, audited codebases (like Pontem, Thala) to reference compared to Ethereum's vast library.
verdict
THE ANALYSIS
Verdict and Final Recommendation
A final assessment of security paradigms for smart contract development across Solidity, Rust, and Move.
Solidity's external call safety excels at interoperability within the EVM ecosystem because of its mature, battle-tested patterns like checks-effects-interactions and reentrancy guards. For example, the widespread adoption of OpenZeppelin's ReentrancyGuard library has become a standard defense, with protocols like Aave and Uniswap V3 securing billions in TVL by rigorously managing external call risks. However, the burden of safety is placed entirely on the developer, making audits critical.
Rust's FFI safety takes a different approach by leveraging the language's compile-time ownership and borrowing system to enforce memory safety at the boundaries of unsafe blocks. This results in a trade-off: developers gain fine-grained control and performance for systems programming, as seen in Solana's Sealevel runtime, but must manually validate all invariants when interfacing with C or C++ libraries, a complex and error-prone process.
Move's cross-module calls are fundamentally safer by design through its resource-oriented type system and bytecode verifier. This eliminates entire classes of vulnerabilities like reentrancy and accidental resource duplication by default. For instance, the Aptos and Sui blockchains leverage this to enable secure, composable DeFi applications without the need for external guard libraries, though this comes at the cost of ecosystem maturity and tooling compared to Ethereum.
The key trade-off: If your priority is building within the largest, most tool-rich ecosystem (EVM) and you have budget for rigorous auditing, choose Solidity. If you need maximum performance and low-level control for a novel VM and can manage FFI complexity, consider Rust. If security-by-default and formal verification for novel financial primitives is your top concern, Move is the decisive choice.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall