Other Authorizers

Cobo Safe is embedded with multiple types of built-in Authorizers.

FuncAuthorizer

FuncAuthorizer is a simple Authorizer that is used to validate the address and the function of a smart contract call.

Assume that an Owner wants to authorize a Delegate to transfer USDT via Ethereum. This can be achieved through the following configuration of FuncAuthorizer:

  1. Validate that the USDT contract address is 0xdAC17F958D2ee523a2206206994597C13D831ec7.

  2. Validate that the transaction will invoke the transfer(address,uint256) function. Note that this function must follow the contract ABI specification.

  3. Call addContractFuncs() or addContractFuncsSig() of FuncAuthorizer to add the above address and function.

Please note that FuncAuthorizer only validates the address and the function of a smart contract call. It does not validate the parameters that are passed in when the contract is called. For example, FuncAuthorizer cannot be used to configure the receipt or the USDT transaction amount. You will need to manually write an ACL instead to implement access controls at the granular level.

TransferAuthorizer

TransferAuthorizer allows you to validate the token type and receipt of a transaction using the addTokenReceivers function. The Delegate can transfer the authorized type of tokens directly to the receipt.

Note that for ERC-20 tokens, the token type will be the token address. For native tokens, the token type will be 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.

ArgusRootAuthorizer

ArgusRootAuthorizer is the default type of Authorizer on Cobo Argus. ArgusRootAuthorizer is not used for validation purposes. Instead, it is used to maintain a set of Sub-Authorizers.

ArgusRootAuthorizer is also designed in the Role-Based Access Control (RBAC) framework. You can use ArgusRootAuthorizer to configure one or multiple Sub-Authorizers for each Role.

When a transaction is sent to ArgusRootAuthorizer:

  1. ArgusRootAuthorizer will query the Delegate of the transaction and identify the Role assigned to the Delegate with the help of a Role Manager.

  2. ArgusRootAuthorizer will query the Sub-Authorizers associated with each Role.

  3. ArgusRootAuthorizer will call the Sub-Authorizers associated with each Role. If the transaction passes validation from any of these Sub-Authorizers, it will be approved. If the transaction fails validation from all of these Sub-Authorizers, it will be rejected.

If a Sub-Authorizer contains both preExecCheck and postExecCheck, a transaction will be approved only if it passes validation from both functions.

Hint

You can add additional data, referred to as hint, during a smart contract call in order to accelerate the validation process and save on gas fees.

The hint field can be passed in in a CallData struct as follows when a transaction is sent to an Authorizer:

struct CallData {
    uint256 flag; // 0x1 delegate call, 0x0 call.
    address to;
    uint256 value;
    bytes data; // calldata
    bytes hint;
    bytes extra; // for future support: signatures etc.
}

With ArgusRootAuthorizer, for instance, multiple Roles can be assigned to a Delegate and each Role can be associated with multiple Authorizers. A transaction will be approved if it successfully passes validation from any of these Authorizers. In this case, Role and Authorizer can be used as hint to determine the specific Authorizer whose validation the transaction will pass:

  1. Execute the execTransaction() function by making an eth_call call without setting the hint field. The hint field returned in TransactionResult will be the hint of this transaction.

  2. Pass in this hint to CallData.

  3. Decode hint in ArgusRootAuthorizer to query the Role and Authorizer.

  4. Use Role Manager to validate whether the Role obtained in step 3 corresponds to the Delegate of this transaction.

  5. Validate whether the Authorizer obtained in step 3 has been registered in ArgusRootAuthorizer.

  6. The hint is considered invalid if either step 4 or step 5 fails. The transaction will be directly rejected.

  7. The hint is considered valid if both step 4 and step 5 succeed. You can use the Authorizer specified in the hint to validate the transaction.

Last updated