Skip to main content

Extensions overview

Extensions are additional contracts that can be composed with your middleware to provide extra functionality. These extensions provide public functions protected with AccessManager to manage specific aspects of your middleware, such as operator management, vault management, and more.

Extensions Architecture

Access Manager​

Key Concepts: Extends KeyManager to determine who can call certain functions, integrates roles, ownership, or custom logic for system-level permissions.

  • OzAccessManaged​

    Integrates OpenZeppelin's AccessManagedUpgradeable to enforce access restrictions. Inherits from AccessManager and uses a centralized "authority" concept to allow or deny certain calls.

  • OzAccessControl​

    Implements a role-based access system similar to OpenZeppelin’s AccessControl.

    • Uses DEFAULT_ADMIN_ROLE and other custom roles.
    • Roles can be granted, revoked, and set as admins of other roles.
    • Functions can be protected by assigning roles to function selectors.
    warning

    Requires initialization to set roles to function selectors and role admins.

  • OwnableAccessManager​

    Implements a simple, owner-based access model. Only the owner (a single privileged address) can control certain actions, suitable for more centralized governance setups.

    warning

    Requires initialization to set the owner.

  • NoAccessManager​

    A placeholder or fallback that does not enforce any access restrictions. Essentially, it grants public access to all functionalities, likely useful in controlled test environments.

Capture Timestamp Manager​

Key Concepts: Extends CaptureTimestampManager to define how to capture a "snapshot" in time to anchor states, epochs, or periods for consistent logic across time intervals.

  • TimestampCapture​

    Captures the current timestamp minus one second. This ensures that state transitions or snapshots reference a past moment, potentially preventing re-entrancy or timestamp manipulations.

  • EpochCapture​

    Organizes time into discrete “epochs” (fixed duration intervals). The capture time is the start of the current epoch. This is useful for systems that update or settle states at regular intervals, ensuring predictable, periodic captures.

Key Manager​

Key Concepts: Extends KeyManager to associate operators with cryptographic keys, handle key rotation, ensure uniqueness, track active/disabled keys, and limit how often keys can be changed.

  • NoKeyManager​

    A baseline implementation of KeyManager that does not store or manage keys. It’s a stub intended for scenarios where no key tracking is necessary.

  • KeyManagerBytes​

    Manages operator keys stored as arbitrary bytes. It enforces uniqueness, handles rotations, and limits disabled keys. Keys are tracked over time, and old keys can be paused or unregistered once they are no longer needed.

  • KeyManager256​

    Similar to KeyManagerBytes, but keys are stored as bytes32 values. This can be more gas-efficient or simpler for certain verification schemes. It also limits disabled keys and ensures that each operator holds a unique, active key.

Sig Manager​

Key Concepts: Extends SigManager to verify signatures that prove an operator controls a particular key. Different signature schemes are supported.

  • EdDSASig​

    Implements EdDSA (specifically Ed25519) signature verification. Operators use Ed25519 public keys and signatures to prove control. This extends the ecosystem to leverage more modern cryptographic schemes beyond the standard ECDSA.

  • ECDSASig​

    Uses standard ECDSA (the common scheme in Ethereum) to verify that operators own the keys they claim. This is ideal for compatibility with existing Ethereum wallets and tools.

Stake Power Manager​

Key Concepts: Extends StakePowerManager to convert staked amounts into voting power. Useful for governance or resource allocation proportional to stake.

  • EqualStakePower​

    A straightforward implementation that treats stake and voting power as 1:1. An operator staking X units of a token or resource gets X voting power. This is a baseline model that can be extended or replaced by more complex logic.

Operators​

Key Concepts: Operator registration, lifecycle management (register, pause, unpause, unregister), vault association, and force-pause capabilities.

  • Operators​

    Provides core functionality for managing operators. Operators can be registered with a key and optionally linked to a vault. It also includes methods to pause, unpause, and unregister operators.

  • SelfRegisterOperators​

    Extends Operators by allowing operators to self-register and manage their own lifecycle using signatures. Operators can prove their identity and control over a key by submitting valid signatures, enabling decentralized self-service operator management.

  • ForcePauseSelfRegisterOperators​

    Builds on SelfRegisterOperators to add a governance or authorized entity’s ability to forcefully pause specific operators. This prevents them from unpausing themselves until authorized parties force-unpause them. Useful for emergency measures or dispute resolution.

Others​

  • Subnetworks​

    Handles the registration, pausing, and unregistration of subnetworks. A subnetwork can be considered a subgroup or shard within a larger system. This extends governance and administrative controls beyond individual operators to entire networks of them.

  • SharedVaults​

    Manages a set of vault addresses used by multiple operators. Similar to how operators can be paused, unpaused, or unregistered, vaults can also be registered, paused, and unpaused. Shared vaults allow resource pooling and coordinated management.