Capability

The object-capability (ocap) model is a security paradigm where authority is inseparable from the reference to an object. A capability is both a reference and a permission. This model is foundational to secure smart contract design, as seen in platforms like Ethereum (via externally owned accounts) and Cosmos SDK-based chains, preventing the ambient authority vulnerabilities common in traditional systems.

Capabilities can be delegated or composed to create complex permission flows. For example:

• A multisig wallet can hold a capability to spend funds, which is only executable when a threshold of signatures is met.
• In DeFi, a user can grant a lending protocol the capability to spend a specific token amount (via an ERC-20 approval), without handing over custody of their entire wallet.

A key feature of advanced capability systems is the ability to revoke or attenuate (reduce the power of) a capability.

• Revocation: The issuer can invalidate a capability, rendering it useless.
• Attenuation: A capability can be restricted (e.g., limiting spend amount, adding an expiry date, or narrowing the set of allowed actions) before being delegated further, enabling precise control over delegated authority.

Capabilities differ fundamentally from Access Control Lists (ACLs). An ACL is a ledger maintained by a resource, listing who is allowed to access it (subject-based). A capability is held by the user (object-based). This shifts the security model:

• ACLs: Centralized guard checks a list.
• Capabilities: Possession of the token is the proof of authority, enabling more decentralized and scalable systems.

In languages like Cadence (Flow) and Move (Aptos, Sui), capabilities are a core language feature. They enable resource-oriented programming, where assets are non-copyable types that can only be stored, moved, or destroyed. A capability is a reference to a resource, and its possession is required to call methods on that resource. This enforces strict ownership and access rules at the protocol level, preventing common vulnerabilities like reentrancy attacks.

Capabilities enable secure authority delegation without transferring ownership. For example, a user can grant a DeFi protocol a capability to interact with a specific token vault, limiting its access to only that vault and for a defined set of actions (e.g., deposit, but not withdraw). This is safer than providing an unrestricted private key or an allowance that must be manually revoked, as the capability's scope is inherently constrained.

Capabilities facilitate secure contract composability. A smart contract can publish a capability that other contracts can acquire to call its functions. This creates a web of trust where interactions are explicitly permitted, unlike the open callback model of Ethereum which can lead to unexpected reentrancy. This pattern is central to the object-centric architecture of networks like Sui, where capabilities govern how objects interact.

In Move-based blockchains, a module's init function is automatically granted a special Publisher capability upon deployment. This capability is then used to create type-specific capabilities (like BurnCapability or MintCapability) for resources defined in the module. These are then stored securely, often by the module owner, to control future privileged actions like minting new tokens, ensuring the initial deployer maintains ultimate control.

While some capabilities are permanent, systems can be designed with revocable capabilities. The grantor can store a reference to the issued capability and later destroy it, invalidating the delegate's access. This provides a more granular and programmatic revocation mechanism compared to traditional token allowances, which require an on-chain transaction to set to zero and can be front-run.

Capabilities offer a distinct security model compared to Ethereum's ERC-20 allowance system.

• Allowance: A numeric limit set by approve(), granting a spender the right to withdraw tokens up to that amount. It's a quantitative limit on a specific action.
• Capability: A reference token that grants the right to call specific functions on a specific object. It's a qualitative grant of authority. Capabilities reduce attack surface by not exposing all functions of an asset.

Smart contracts use capabilities to implement robust access control and composability. Instead of checking a caller's address, a contract function checks for the presence of a valid capability token. This pattern enables:

• Least-privilege security: Users only hold tokens for the specific actions they need.
• Delegation: Capabilities can be transferred or wrapped for secure delegation of authority.
• Modularity: Contracts can safely expose powerful functions, knowing only authorized holders can invoke them.

Capabilities provide a more secure and flexible alternative to traditional allowlists. Key differences:

• Dynamic vs. Static: A capability is a transferable object, while an allowlist is a static list managed by an admin.
• Object-Capability Security: Authority is held by the object (the token), not implied by identity. "Only holders of this key can open this door."
• Reduced Centralization: No need for a central administrator to update a list; authority flows with the capability token itself.

A canonical example is controlling the right to mint new tokens. Instead of hardcoding a single admin address into a token program, the mint authority is represented as a capability (e.g., a PDA on Solana or a MintCap resource in Move). This token can be held by a multisig wallet, a DAO, or even burned to make the token supply permanently fixed, providing clear and transferable control over a critical function.

Capabilities in blockchain are an implementation of the Object-Capability (ocap) model, a computer security paradigm. The core principles are:

• No ambient authority: A program cannot perform an action unless it possesses a specific capability for it.
• Capabilities are unforgeable: They can only be obtained through creation, endowment, or delegation from an existing holder.
• Principle of least authority: Systems are designed by distributing minimal capabilities. This model underpins the security design of several blockchain virtual machines.

A core security benefit where a process or user is granted only the minimum capabilities necessary to perform its function. This limits the blast radius of a compromise. For example, a smart contract that only needs to read a token balance would not be given a capability to transfer tokens, preventing unauthorized withdrawals even if the contract is exploited.

A secure capability must be unforgeable—it cannot be fabricated by an entity that does not already possess it. However, capabilities can be safely delegated or attenuated. Delegation allows controlled sharing of access, while attenuation creates a new, more restricted capability (e.g., read-only access from a read-write capability). The security model depends on the system's ability to enforce these rules at the runtime or VM level.

Contrasts two security models. In ambient authority (common in traditional systems), a process's identity (like a user ID) is checked against a global access control list for each resource access, leading to confused deputy problems. The object capability model eliminates ambient authority; access is solely determined by possession of a specific capability object, making authority explicit and non-repudiable.

A critical consideration is how long a capability remains valid and how it can be revoked. Persistence refers to a capability's lifespan (e.g., single session, permanent token). Revocation mechanisms are necessary to invalidate capabilities, which can be challenging in decentralized systems. Solutions include indirect capabilities (pointers to revocable grants) or time-bound capabilities that expire.

A classic security flaw where a program with elevated privileges is tricked into misusing its authority on behalf of a less-privileged attacker. Capability-based systems are inherently resistant to this because there is no ambient authority to confuse; a deputy can only act using the explicit capabilities it was given, not the identity of the caller.

In blockchain contexts, capabilities are often implemented via reference (e.g., a smart contract address and function selector) combined with the possession of a signed transaction or a token in the caller's wallet. Security relies on the underlying blockchain's integrity for unforgeability. The Cosmos SDK and Flow blockchain are notable for employing object-capability patterns in their architecture.