CUBE3 Documentation
  • CUBE3 Documentation
  • Detect Products
    • Inspector
    • Monitor
    • Sonar
      • Sonar Feeds
  • Protect Products
    • RASP
      • Quick Start
        • ERC-20 Non-Upgradeable (Foundry)
        • ERC-20 Non-Upgradeable (Hardhat)
        • ERC-20 Upgradeable (Foundry)
        • ERC-20 Upgradeable (Hardhat)
      • RASP Integration
        • 1. Installation
        • 2. Integration
        • 3. Deployment
        • 4. Registration
        • 5. Interaction
        • 6. Inspection
      • CUBE3 Protocol
      • CUBE3 SDK
  • Manage Products
    • Transactions
    • Alerts
      • Email Integration
      • Slack Integration
      • Telegram Integration
      • Discord Integration
      • Webhook Integration
    • Rules
  • API Documentation
    • Inspector API
    • Validation API
      • Troubleshooting
    • Management API
      • Monitor API
      • Alert API
      • Control lists API
    • Authentication
    • API Rate Limits
  • Risk Engine
    • Risk Scoring Introduction
    • Risk Scoring Detailed Overview
  • Settings
    • Billing
    • Organization
    • API Keys
  • Supported Blockchain Networks
    • CUBE3 Detect Products
    • CUBE3 Protect Products
  • Testing Guide
Powered by GitBook
On this page
  1. Protect Products
  2. RASP

CUBE3 Protocol

Learn about CUBE3 Protocol

Previous6. InspectionNextCUBE3 SDK

Last updated 9 months ago

Key Concepts

An Integration

CUBE3 provides abstract contracts that can be inherited to provide access to the cube3Protected modifier provided by the abstraction. Once your contract that inherits from an abstraction has registered on-chain with the router, it is then referred to as an "integration".

The Router

The router is designed for maximum flexibility. Given that the functionality of the cube3Protected modifier cannot exist without the accompanying CUBE3 services, flexibility and customization take precedence over immutability. As such, the Cube3RouterImpl achieves upgradeability by conforming to the UUPS spec. An integration needs to register with the Router before it can enable any function protections. Registration is further restricted through the use of a registrar signature generated by CUBE3. The signature is signed using the private key for the integration's signing authority, a dedicated account managed by the CUBE3 KMS. In order to register an integration on-chain, the signature needs to be retrieved from the CUBE3 dApp.

The Registry

The registry stores the signing authority for each customer integration. A signing authority is the account derived from the private-public keypair generated for each integration and stored in CUBE3's KMS on behalf of each integration.

Security Modules

Application-specific smart contracts that provide dedicated per-contract functionality to CUBE3’s on-chain protocol. The Cube3RouterImpl is responsible for routing transactions to designated modules, which will be covered in more detail in the Payload Routing section.

Signature/Signing Authority

A signing authority is a dedicated account created and managed by CUBE3 for each integration. The account address derived from the public key is stored on-chain in the CUBE3 Registry as the signingAuthority for your integration, while the private key is stored in the CUBE3 KMS. The KMS is unidirectional, and CUBE3 does not have direct access to the private key. The Signing Authority's only role is to sign data off-chain so that it can be validated on-chain, the authority has no privileged read/write access to your integration.

Routing and Payloads

An integration has access to all the functionality offered by the available Security Modules. The Router is responsible for getting your integration's transaction data to the correct Security Module by extracting data from the payload included in the transaction's calldata. For an in-depth overview of how routing works within the payload, please review the . This explains the relationship between the CUBE3 Payload, the Module Payload, and the Routing Bitmap in great detail.

routing docs