Overview

This note details how Clearstar whitelists on-chain addresses for approved yield opportunities. It is a part of the Capital Allocation Framework

Whitelisting is the gateway between due diligence and live capital deployment. Once an opportunity has achieved a passing tier through the APB Risk Rating, the specific contract addresses that Clearstar will interact with are registered in ForDeFi, Clearstar's primary workspace. ForDeFi enforces whitelisting at the policy level: transactions to non-whitelisted addresses are blocked, regardless of who initiates them. This is a critical mitigation against front-end hijacking attacks, where a compromised protocol UI could redirect transactions to malicious contracts.

Whitelisting does not cover every contract analysed during due diligence. Only the addresses that Clearstar will directly interact with are whitelisted, typically the core protocol contracts (e.g. vaults, routers, pools) and the relevant asset contracts (ERC-20 tokens, ERC-4626 vaults). Supporting infrastructure contracts that were analysed for risk purposes but are not called directly are not whitelisted.

Every whitelisting action requires approval from at least two senior analysts, both of whom must have reviewed the full due diligence package before approving. ForDeFi captures a complete audit trail of who approved each whitelisting entry.

<aside> <img src="/icons/warning_red.svg" alt="/icons/warning_red.svg" width="40px" />

Dual sign-off is mandatory No address can be whitelisted with fewer than two senior analyst approvals. This applies to initial whitelisting, additions, and modifications. There are no exceptions to this requirement.

</aside>

flowchart TD
    A[APB Risk Rating: passing tier] --> B[Prepare whitelisting request]
    B --> C[Senior analyst 1 reviews DD and approves]
    B --> D[Senior analyst 2 reviews DD and approves]
    D --> E[Addresses registered in ForDeFi]
    C --> E
    E --> F[Proceed to Execution]

    style A fill:#4A90D9,stroke:#2E6BA6,color:#fff
    style C fill:#E8A838,stroke:#B8862D,color:#fff
    style D fill:#E8A838,stroke:#B8862D,color:#fff
    style E fill:#5BB85B,stroke:#3D8B3D,color:#fff
    style F fill:#5BB85B,stroke:#3D8B3D,color:#fff

Scope of Whitelisting

What Is Whitelisted

Only addresses that Clearstar will call directly during Execution are whitelisted. The table below illustrates the typical scope.

Address Type Examples Whitelisted?
Core protocol contracts Vaults, lending pools, routers, staking contracts Yes
Asset contracts ERC-20 tokens, ERC-4626 tokenised vaults Yes
Governance contracts Governor, timelock, multisig No (not interacted with directly)
Oracle contracts Chainlink aggregators, TWAP oracles No (not interacted with directly)
Dependency contracts Underlying protocols in the dependency chain No (unless directly called by Clearstar's strategy)

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />

Minimal surface area By whitelisting only the contracts Clearstar interacts with directly, the attack surface is kept as small as possible. If a front-end is compromised and attempts to route a transaction to a contract outside the whitelist, ForDeFi will reject it before the transaction is signed.

</aside>

Per-Chain Whitelisting

Whitelisting is performed per chain. If a protocol operates on multiple chains, each chain instance requires its own whitelisting entry, and a separate Blockchain Due Diligence must have been completed for each chain as part of the APB Risk Rating.

Function-Level Restrictions

Whitelisting is done at the contract address level by default. In some cases, function-level restrictions are applied on top of address-level whitelisting, particularly where spending limits or specific call permissions are appropriate. These are determined on a per-case basis depending on the strategy and the size of the allocation, and are configured within ForDeFi's policy engine.

Whitelisting Process