LogoLogo
  • CrossCurve MetaLayer
    • ⚙️What is CrossCurve MetaLayer
      • CrossCurve Consensus bridge
      • CrossCurve Pools v2
    • 🗺️Roadmap
      • 2024
  • 🏢CrossCurve DAO
    • Overview of CrossCurve DAO
    • Voting
    • Obtaining veEYWA and Calculating the Boost
    • Staking mechanics
    • NFTs
      • CrossCurve DAO NFT
      • EYWA NFT Collection
  • 💼Earn with CrossCurve
    • Staking in CrossCurve
    • Providing Liquidity to CrossCurve Pools
    • Voting for Incentives
  • 📖user documentation
    • 🛸Migration to Sonic
      • Why are we moving to Sonic
      • Sonic Upgrade Stages
      • Liquidity transfer from Fantom to Sonic
      • Sonic Incentives on CrossCurve MetaLayer
    • 🔃Swap interface
      • How to trade
      • Slippage settings
      • Routing
    • 🌊Liquidity Interface
      • Easy mode
      • via Curve (Balanced)
      • Liquidity provision use cases
        • Deposit
          • Easy mode (Imbalanced)
          • via Curve (Balanced)
        • Withdraw
          • Easy mode (Imbalanced)
          • via Curve (Balanced)
        • Curve Knowledge Database
          • Balanced liquidity provision
          • Guide to transferring CRV from Fantom chain to Ethereum mainnet
          • Disclamer
    • 🏢DAO
      • Locker Interface
      • Vote Interface
      • Incentives Interface
      • Working with the EYWA Locker contract in Arbiscan.
    • 🌾Yield
      • Farms Interface
        • Staking liquidity and earning rewards
      • APR Calculator
      • EYWA pool via Convex
    • 💼Vesting
      • Claim portal interface
      • Early farming program interface
    • EYWA NFT
      • Bridge interface in the Aurora chain
      • Merge interface in the Arbitrum chain
      • EYWA NFT Manager interface
      • Dashboard interface
    • Leaderboard
    • ❄️Outdated
      • Early farming program
  • 📖Developer documentation
    • Pools/asset contracts
      • Hubchain Pools and Assets
      • 💱Supported tokens
    • 🔗CrossCurve smart contracts
    • 💻Guide for Developers
      • Technical Documentation for CrossCurve DAO Smart Contracts
        • CalldataHelperV1
        • DelegationManagerV1
        • DelegationConditionValidatorV1
        • EmissionManagerV1
        • EscrowManager
        • EscrowVoteManagerV1
        • GaugeFactoryV1
        • GaugeV1
        • IncentiveRewardsDistributor
        • LockHolderFactoryV1
        • LockHolderV1
        • ProposalManager
        • RebaseRewardsDistributorV1
        • RewardsDistributorFactoryV1
        • Treasury
      • 🔃Make cross-chain swap
      • 🔦Tracking cross-chain swap
      • 📔Pusher API Reference
      • 📝Glossary
      • API Specification
  • 📣About CrossCurve
    • 🛡️Security audits
    • 🧠Team
    • Project History
    • Website
    • Telegram
    • Twitter
    • Medium
    • Discord
    • YouTube
    • LinkedIn
    • GitHub
Powered by GitBook
On this page
  • Overview
  • Inherited Contracts and Interfaces
  • State Variables
  • Constructor
  • External Functions
  • Internal Functions
  • Errors
  • Summary
Export as PDF
  1. Developer documentation
  2. Guide for Developers
  3. Technical Documentation for CrossCurve DAO Smart Contracts

RewardsDistributorFactoryV1

Overview

RewardsDistributorFactoryV1 is an upgradeable contract (using UUPS) that deploys new instances of IncentiveRewardsDistributor. It restricts calls to createRewardsDistributor such that only the escrow vote manager can request a new distributor, thus ensuring controlled creation of additional reward distribution contracts.

Key Roles and Features:

  1. Factory Pattern: It centralizes the instantiation of IncentiveRewardsDistributor contracts, simplifying the process of creating new distributors for different escrow managers.

  2. Access Control: Only the escrow vote manager can call createRewardsDistributor, preventing unauthorized distribution contract creation.

  3. Upgradeable via UUPS: Ensures the factory contract can be upgraded over time, with ownership-based control on upgrades.

By implementing IRewardsDistributorFactoryV1, RewardsDistributorFactoryV1 provides a standard interface for deployment logic and event transparency (though no new custom events are declared here beyond the interface's contract structure).


Inherited Contracts and Interfaces

  • UUPSUpgradeable (OpenZeppelin): Provides the upgrade mechanism under the UUPS proxy standard, restricting upgrades to the contract owner.

  • OwnableUpgradeable (OpenZeppelin): Establishes ownership logic, allowing the owner to authorize upgrades and potentially modify other aspects of the factory (not used extensively here but available if needed).

  • IRewardsDistributorFactoryV1: Declares the initialize and createRewardsDistributor functions, along with an InvalidCaller error.

Additional External References:

  • IncentiveRewardsDistributor: The contract being deployed by this factory. It manages incentive reward distributions for an escrow manager and is constructed with references to the escrow vote manager and escrow manager.


State Variables

address public s_escrowVoteManager;
  • s_escrowVoteManager (address): The address of the escrow vote manager contract. Only this address may invoke createRewardsDistributor on the factory.


Constructor

constructor() {
    _disableInitializers();
}
  • Description: Disables contract initializers to ensure initialize() can only be called once. A standard pattern for UUPS upgradeable contracts.


External Functions

1. initialize(address owner_, address escrowVoteManager_)

function initialize(address owner_, address escrowVoteManager_) external initializer
  • Description: Configures the factory contract by assigning ownership (owner_) and storing the escrow vote manager address. This function can be called only once due to the initializer modifier.

  • Parameters:

    • owner_: The address to be assigned as the owner of this factory contract.

    • escrowVoteManager_: The address of the escrow vote manager responsible for orchestrating new distributor creations.

  • Logic and Effects:

    1. Invokes __UUPSUpgradeable_init() and __Ownable_init(owner_) for upgrade and ownership setup.

    2. Sets s_escrowVoteManager = escrowVoteManager_.


2. createRewardsDistributor(address escrowManager_)

function createRewardsDistributor(address escrowManager_) external returns (address)
  • Description: Creates and returns a new IncentiveRewardsDistributor contract instance, linking it to the calling escrow vote manager (msg.sender) and the provided escrowManager_. The call reverts if not invoked by s_escrowVoteManager.

  • Checks:

    • Must be called by s_escrowVoteManager. Otherwise, it reverts with InvalidCaller().

  • Logic:

    1. If msg.sender != s_escrowVoteManager, revert with InvalidCaller().

    2. Deploys a new IncentiveRewardsDistributor by calling its constructor:

      new IncentiveRewardsDistributor(msg.sender, escrowManager_)
    3. Returns the newly created contract’s address.

  • Return:

    • address: The address of the newly created incentive rewards distributor contract.


Internal Functions

1. _authorizeUpgrade(address newImplementation)

function _authorizeUpgrade(address) internal override onlyOwner
  • Description: Restricts upgrades of this factory to the contract’s owner, following the UUPS standard. This ensures that only the owner can deploy a new logic implementation for this factory contract.


Errors

  • InvalidCaller() Thrown if createRewardsDistributor is called by an address other than s_escrowVoteManager.


Summary

RewardsDistributorFactoryV1 provides a straightforward pattern for creating new IncentiveRewardsDistributor instances. By restricting calls to its createRewardsDistributor function to the escrow vote manager, it ensures that only authorized processes can spin up new distributor contracts. Coupled with UUPS upgradeability, the factory is future-proofed, allowing for modifications to how distributors are instantiated if the protocol’s requirements evolve over time.

PreviousRebaseRewardsDistributorV1NextTreasury

Last updated 1 month ago

📖
💻