Rigoblock Documentation
  • Welcome
  • Introduction to RigoBlock
  • Contracts
    • Protocol
      • RigoblockPoolExtended
      • Core
        • constants
        • immutables
        • storage
        • actions
        • owner actions
        • abstract
        • fallback
        • initializer
        • state
        • storage accessible
      • Deps
        • Authority
          • authority docs
        • PoolRegistry
          • pool registry docs
      • Extensions
        • AGovernance
          • Solidity API
        • AMulticall
          • aMulticall docs
        • AStaking
          • aStaking docs
        • AUniswap
          • aUniswap docs
        • EUpgrade
          • eUpgrade docs
        • EWhitelist
          • eWhitelist docs
      • Proxies
        • proxy
          • proxy docs
        • proxy factory
          • proxyFactory docs
    • GRG Token
      • RigoToken
        • rigoToken docs
      • Inflation
        • inflation docs
      • ProofOfPerformance
        • pop docs
    • GRG Staking
      • GrgVault
        • grgVault docs
      • StakingProxy
        • stakingProxy docs
      • Staking
        • staking docs
    • Governance
      • Solidity API
  • Deployments
    • deployed contracts - V4
    • deployed contracts
    • v1.5.0
    • v1.4.2
    • v1.4.1
    • v1.3.0
    • v1.1.1
    • v1.1.0
  • Governance
    • Rigoblock Governance
    • Supported Applications
    • Token Whitelists
    • Supported Methods
      • Selectors - V4
      • Selectors - V3
  • Bug Bounty
    • Known Issues
  • Oracles and Price Feeds
Powered by GitBook
On this page
  1. Contracts
  2. Protocol

Deps

Contracts that add base functionality to the protocol

  • Authority --> contains all protocol permissions, it is owned by the RigoBlock governance and stores the approved factories, adapters, whitelisted methods on adapters and the wallets that have whitelister role.

  • PoolRegistry --> stores the mapping of a pool proxy address to its assigned ID, which is the hash of the name and the owner, making it unique for a said name and pool operator. A pool's name is not stored in the registry and can be used multiple times (but with different pool owners) in order to prevent a race condition which would make it not 100% certain that they could deploy the same pool to multiple chains. The pool registry is used by applications like the RigoBlock Staking system for querying a pool's unique ID. A pool owner can set metamadata for its pool.

  • KYC --> a mock module, since a canonical KYC module is not provided and the pool operator is responsible, if decides to opt-in for whitelisting its pool proxy users, to implementing/selecting the KYC module of his choice, potentially restricting who can mint his operated pool's tokens or the maximum mintable amount.

Previousstorage accessibleNextAuthority

Last updated 2 years ago