Move's `public` vs `friend` vs `entry` Visibility: Module Scoping vs Direct Invocation

Solidity's public/private model excels at developer familiarity and rapid prototyping because it mirrors traditional OOP. For example, the simplicity of marking a function public has enabled the explosive growth of the EVM ecosystem, with over 100 million deployed contracts on Ethereum alone. However, this binary choice creates a critical security-composability trade-off: a public function is globally accessible, while a private one is completely locked, leaving no middle ground for controlled, intra-ecosystem access.

Move's public/friend/entry model takes a different approach by introducing module-scoped visibility and explicit entry points. The friend keyword allows you to whitelist specific modules, enabling secure cross-module calls without exposing functions to the entire network. The entry modifier further restricts functions to be callable only via transactions, not internally. This results in a more secure and intentional architecture by default, as seen in core Aptos and Sui frameworks, but requires more upfront design discipline.

The key trade-off: If your priority is maximizing unrestricted composability and developer speed within a mature EVM toolchain (e.g., for a rapid DeFi prototype on Arbitrum or Base), Solidity's model is effective. If you prioritize security-by-default and granular, verifiable access control for high-value assets or novel financial primitives (e.g., a novel AMM on Aptos or a gaming economy on Sui), Move's friend and entry system provides a fundamentally stronger foundation.

public functions excel at enabling broad, permissionless composability because they are callable from any module. For example, core DeFi protocols like Aptos Liquidswap and Sui Turbos Finance rely on public entry points for their automated market makers, allowing any user or smart contract to interact with swap pools directly. This maximizes protocol utility and ecosystem integration but exposes a larger attack surface, requiring rigorous auditing of every public function.

friend functions take a different approach by enabling controlled, module-level composability. This results in a trade-off between security and flexibility. A module can declare other modules as friends, granting them exclusive access. This is ideal for upgradeable contracts or internal protocol logic, as seen in Aptos Framework upgrades, where only the governance module can call critical migration functions. It prevents unauthorized external calls but adds administrative overhead in managing friend lists.

entry functions are optimized for direct user and script invocation, acting as transaction entry points. This design results in superior user experience and gas efficiency for end-users, as they can call these functions without intermediate wrapper contracts. On Sui, which heavily promotes entry, this leads to simpler dApp interfaces and measurable reductions in transaction complexity. However, entry functions cannot be called by other Move modules, limiting internal composability.

The key architectural trade-off: If your priority is maximizing ecosystem composability and protocol utility, default to public functions. If you prioritize secure, upgradeable internal logic with controlled access, architect with friend visibility. For user-facing operations where direct invocation and gas efficiency are paramount, design your transaction endpoints as entry functions. Most production systems, like those on Aptos and Sui, use a hybrid model, leveraging each modifier for its intended scope.