Deployment & Configuration

Deployment & Configuration Flow

The deployment flow consists of three major stages, orchestrated by the Factory contract and finalized by the Governor (via Timelock).

Step 1: Deploy Protocol (via Factory)

The Factory deploys core protocol contracts, including:

  • Risk Engine

  • Oracle Engine

  • Timelock

It also:

  • Sets roles for the Protocol Owner and Governor

  • Registers the instance in its registry

  • Establishes upgradeability via the Beacon pattern

Step 2: Deploy pToken (via Timelock)

Each pToken is deployed via Timelock by the Governor using the Factory’s deployment functions. The token is registered and linked with the relevant protocol instance.

Step 3: Post-Deployment Configuration (via Timelock)

After deployment, the Governor must finalize market-specific configurations using a sequence of protocol calls:

  1. Oracle Setup:

    • Deploy or reference a price oracle (e.g., ChainlinkComposite, Pyth).

    • Call setAssetConfig on the Oracle Engine for each pToken to set its price feed.

  2. Risk Configuration:

    • Use configureMarket on Risk Engine:

      • Set LTV

      • LLTV (Liquidation Loan-to-Value)

      • Liquidation Incentives

  3. Interest Rate Model (IRM):

    • Call configureInterestRateModel on each pToken to define interest rate parameters:

      • Base rate

      • Kinks

      • Slopes

  4. Market Caps and Close Factor:

    • Set borrow/supply caps via setBorrowCap / setSupplyCap.

    • Define liquidation threshold via setCloseFactor.

Timelock Controller

Pike’s governance delay is enforced through a modified version of OpenZeppelin’s TimelockController, with added support for emergency execution.

Key Roles

Proposer

The Governor, schedules all configuration proposals.

Executor

Set to address(0), allowing anyone to execute proposals after the delay.

Canceller

Includes the Governor, Protocol Owner, and Emergency Executor — can cancel scheduled but unexecuted actions.

Emergency Executor

Can bypass the delay and perform predefined emergency actions immediately.

Admin

Set to address(0) after deployment, making the Timelock ownerless and fully governed by proposals.

Security Considerations

  • The Emergency Executor and Protocol Emergency Guardian serve different purposes. Assigning the same address to both centralizes power and increases risk.

  • To ensure layered defense, keep these roles separate unless explicitly required and carefully managed.

Notes

  • Factory handles deployment; Timelock handles configuration. This separation promotes cleaner permissioning and role accountability.

  • Emergency actions must go through either the Emergency Executor or the Protocol Emergency Guardian, depending on their scope.

PreviousOverviewNextOverview

Last updated