Skip to main content

Audits

Forge's lending core is the Venus Core Pool architecture, vendored from upstream Venus and kept under a byte-identity discipline against a pinned upstream commit. This page explains the security posture users should understand: what Forge inherits from Venus, and which Forge-specific Bittensor surfaces are reviewed separately.

The Venus security posture is documented at:

Venus inheritance

Forge inherits the Venus Core Pool lending mechanics directly. The vendored Venus production Solidity is kept byte-identical to a pinned upstream commit, and CI fails on any unexpected drift. That means:

  • the Comptroller, vToken accounting, interest-rate models, and risk-parameter enforcement come from Venus.
  • the security history of those components, including audits and on-chain operating record, is relevant context for Forge's lending core.
  • documented deviations from upstream Venus (Forge-specific additions, removals, and configuration choices) are tracked in the repository and visible to reviewers.

Venus audits do not audit or guarantee Forge's deployment, Bittensor runtime behavior, staking precompile behavior, oracle configuration, liquidation helpers, governance setup, frontend, or any Forge-specific additions.

Forge-specific review scope

Forge-specific review covers the surfaces that are not directly inherited from Venus:

  • wAlpha / vWAlpha native Alpha custody and accounting: how Alpha collateral enters, sits in, and exits a Forge market through the staking precompile's mapped Substrate coldkey.
  • Bittensor staking precompile integration: approve / transferStakeFrom flows, deposit-side custody verification, and unstake/exit paths.
  • Alpha oracle adapters and price-protection logic: how Alpha is priced for collateral valuation and how stale or manipulated price data is rejected.
  • Liquidation helpers and protocol-share routing: the Alpha-aware liquidation flow described in Collateral and Risk, including the protocol-share split.
  • Governance and access-control configuration: the Forge Guardian Multisig wiring and per-action authorization.
  • Reserve and shortfall handling: how borrower interest and seized-collateral shares accumulate and route.
  • Keeper and liquidator operational assumptions: what off-chain actors are expected to do and what assumptions Forge makes about them.
  • Frontend transaction safety and parameter display: how the Forge app presents account state and risk surface to users.

What users should check

Before using Forge, users should:

  • Verify the network, market, and account state in the Forge app before each transaction.
  • Watch for parameter or pause-state changes published by the Forge Guardian Multisig.
  • Review the current audit and security information published on this page.

Read Forge Overview for the Bittensor precompile feature that makes native Alpha collateral possible.