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. Governance

Supported Methods

Notice: in Rigoblock V4, extensions are hardcoded in the implementation via the ExtensionsMap contract, and therefore not upgradable. Adapters are upgradable, as they are intended for use with external applications.

The Rigoblock protocols requires adapters that communicate with external applications to be explicitly approved. Once an adapter is approved, the adapter methods can be added to the protocol by adding a mapping of selector to adapter. This way, the protocol correctly routes external calls by making the preemptive checks within said adapters. Once an adapter has been added, the governance can remove it by voting. Certain wallets hold governance permit to add-remove methods. Adding and removing methods of preemptively approved adapters does not require governance voting. Things are subject to change as a governance or protocol upgrade could modify these requirements.

PreviousToken WhitelistsNextSelectors - V4

Last updated 2 months ago