CUBE3 Protocol

Learn about CUBE3 Protocol

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 routing docs. This explains the relationship between the CUBE3 Payload, the Module Payload, and the Routing Bitmap in great detail.