Risk Overview

This page lists the risks of using AEGIS as an LP, borrower, integrator, or operator. It is written for honest assessment, not for marketing. If you are evaluating whether AEGIS is appropriate for your use case, read this page before you act.

Risks are grouped by category. For each one, we describe what the risk is, what mitigates it in the protocol design, and what residual risk remains for the user.

Smart contract risk

The risk. Solidity contracts can have bugs that cause loss of funds or protocol malfunction. This risk applies to every DeFi protocol, including AEGIS.

What mitigates it.

• DFM is audited by Spearbit and Cantina. Reports are linked from Security, Audits, and Status. DFM has been running on testnet and canary deployments for an extended period.

• Engine is audited by Trail of Bits.

• Invariants are documented in the AEGIS_Statement_of_Intended_Behavior.md files in each repo. These are the specific properties auditors and reviewers are invited to attack.

• Foundry test suites (including fuzzing and invariant testing) exercise both normal and pathological paths.

What remains. No amount of auditing eliminates smart contract risk entirely. Engine in particular introduces new code (pool-native credit, collateral floor math, peel + micro-liq) that does not have years of production exposure. Users should size positions according to their own risk tolerance.

Solvency & liquidation risk (Engine)

The risk. A vault can become undercollateralized if its attached NFTs lose value (price moves out-of-range) or if its idle-token reserves change value faster than keepers can act. If keepers cannot fully heal the vault, sL holders bear the uncovered L as first-loss.

What mitigates it.

• The √K collateral floor is evaluated using current pool state (√P, NFT ranges, idle balances). There is no oracle dependence, so there is no stale-oracle risk.

• Keepers have two modes (peel, micro-liquidation) with overlapping economics — if one fails, the other often succeeds.

• MAX_LTV_PIPS = 980,000 (98%) is a compile-time constant; the health cushion between LTV and solvency is narrow but deliberate (borrowers trade off capital efficiency against liquidation margin).

• Session-end LTV check reverts the entire transaction if the vault is out of spec, preventing any action that would leave the vault unhealthy.

What remains.

• If the pool has insufficient depth for keepers to swap at acceptable slippage, keeper economics break down and liquidations may stall.

• Extreme adversarial scenarios (e.g., coordinated price attacks on thinly-traded pools) could leave some residual sL loss. The full set of attack vectors is discussed in Solvency and Liquidation.

Oracle risk (indirect)

The risk. DFM uses the TruncGeoOracleMulti for base-fee computation and for CAP event detection. If the oracle misbehaves, the fee computed may be wrong.

What mitigates it.

• The oracle is derived from the same pool's ticks — it cannot be manipulated in a way that doesn't also manipulate the pool price. Pool manipulation costs approximately the pool's depth, which self-bounds the attack cost.

• The max-ticks-per-block cap is an explicit design feature; price moves beyond the cap arm the surge fee rather than being silently accepted.

• If the oracle manager reverts or the hook's external call to DFM fails, the hook emits ExternalCallFailed and falls back to manualFeePpm from PoolPolicyManager. The pool continues to function; only the adaptive fee is disabled for the affected block.

What remains. Pool-internal oracles are only as robust as the pool's depth. Thin pools are easier to push; AEGIS pools with low liquidity are more vulnerable to short-term oracle distortions.

Governance & admin key risk

The risk. AEGIS has owner-controlled functions: pausing auto-tune, updating policy parameters, adding/removing authorized hooks, setting the protocol fee rate.

What mitigates it.

• The complete inventory of privileged functions is documented in Governance and Roles.

• Critical parameters are bounded — MAX_LTV_PIPS, UTILIZATION_CAP_PIPS, MAX_NFTS_PER_VAULT, MIN_LIQUIDITY, and others are compile-time constants, not owner-tunable. An admin cannot increase LTV limits or change keeper gating.

• Owner keys are TODO: confirm — working assumption is a multisig with timelock for all parameter changes.

• Emergency pause exists for narrow pause points (e.g., auto-tune freeze). There is no "pause everything" super-kill switch.

What remains. If the owner key is compromised, an attacker could change tunable policy parameters (fee bounds, protocol fee rate, authorized hook list) within the bounded envelope. They cannot unilaterally drain user funds, but they can degrade protocol economics until the key is rotated.

Liquidity & market risk

The risk. AEGIS pools depend on Uniswap v4 markets being functional and reasonably liquid.

• LPs earn fees only when volume exists.

• Borrowers need the pool to be liquid enough to repay at acceptable slippage.

• Keepers need the pool to be liquid enough to execute micro-liquidation profitably.

What mitigates it. AEGIS deployments are targeted at pairs with sustained volume. Thin pools are unlikely to be enabled for Engine.

What remains. Pool liquidity can change. A pair that was active for a year could become dormant; during dormant periods, keeper economics weaken. LPs should track the pools they're in; borrowers should not rely on specific exit paths being available at all times.

Uniswap v4 dependency

The risk. AEGIS is built on Uniswap v4's PoolManager. If v4 core has a critical vulnerability or is paused, AEGIS inherits the impact.

What mitigates it. Uniswap v4 is itself heavily audited and has broad mainnet deployment. AEGIS does not modify v4 core; it only uses the hook interface.

What remains. AEGIS cannot protect users from issues in v4 core. Positions in AEGIS-enabled pools are Uniswap v4 positions, with Uniswap v4's risk profile.

Cross-chain & deployment risk

The risk. AEGIS deploys to multiple chains via CREATE2 deterministic addressing. Each chain is a separate surface.

What mitigates it.

• Same bytecode + same CREATE2 salt → same address across chains. Verification is mechanical.

• Each chain's deployment is independently verifiable on its block explorer. Addresses are published in Deployed Contracts.

• Per-chain policy is configured separately; a policy change on Base does not silently propagate to Optimism.

What remains. Different chains have different security properties (validator sets, settlement finality, bridge risk for the underlying tokens). AEGIS does not run bridges itself, but an AEGIS-enabled pool on chain X is exposed to chain X's ecosystem risks.

Keeper risk (Engine)

The risk. Micro-liquidation requires an economically-motivated keeper to submit transactions. If keepers are absent or unprofitable, unhealthy vaults may stay unhealthy longer than expected.

What mitigates it.

• Peel has a denominated bounty paid in the pair's tokens (from vault idle), making it naturally profitable for keepers when vaults are peel-eligible.

• Micro-liquidation has no bounty, but the AE-owned swap captures a discounted outcome; professional keepers will run micro-liq on any vault they can detect as unhealthy.

• The peel/micro-liq event streams are public; anyone can build a keeper.

What remains. Keeper performance depends on gas costs, MEV competition, and pool liquidity. During extreme gas spikes or when the pool has very little depth, keeper economics may weaken and vaults may stay unhealthy for longer windows than typical.

Regulatory & jurisdictional risk

The risk. DeFi protocols face evolving regulatory treatment globally. Specific services, functions, or integrations may be restricted in some jurisdictions.

What mitigates it. AEGIS is a set of smart contracts; it is not a custodial service, has no KYC layer, and does not route user funds through AEGIS-controlled accounts.

What remains. Users are responsible for their own regulatory compliance. AEGIS publishes no legal opinions about the status of the protocol or its tokens in any jurisdiction. TODO: if the Foundation publishes a restricted-jurisdictions list, link it here.

User-error risk

The risk. AEGIS Engine exposes a router-driven action system with multiple phases, a session model, and strict invariants. Integrators who misuse the API may unintentionally submit transactions that revert, leave dust, or interact with pools in non-obvious ways.

What mitigates it.

• The router enforces phase ordering, delta-zero, session lifecycle, and LTV at the end of every session. Revert early and clearly is the design goal.

• Events are published with full units in NatSpec.

• Integration patterns are documented in Integrating AEGIS Engine.

What remains. Integrators who don't read the docs can still lose gas on reverts. They can also, in principle, construct routes that deposit idle tokens without intending to (e.g., via an unexpected positive delta); the protocol won't prevent that, it's a consequence of how v4 PoolManager accounting works.

What AEGIS does not protect against

To be explicit about the scope of the protocol's safety model:

• Impermanent loss / LVR. AEGIS does not hedge LP inventory. Dynamic fees capture more economic surplus on the fee side, but the inventory side is unchanged. LPs still bear standard Uniswap position risk.

• Your own private key. AEGIS has no recovery mechanism. If you lose your key, you lose access.

• Non-AEGIS counterparties. If you use a third-party vault wrapper (Gamma, Arrakis, etc.) on an AEGIS pool, the wrapper's contract risk is on top of AEGIS's.

• Price direction. AEGIS does not predict prices, speculate, or provide exposure. Every AEGIS position's underlying exposure is determined by the Uniswap v4 math; nothing in AEGIS alters that.

---

Next: Governance and Roles — what is controlled by whom, and what remains fixed in the protocol.

---

Governance and Roles

This page is the inventory of everything that is controlled by someone — and everything that is controlled by no one because it's a compile-time constant. Every privileged function is listed; every upgrade path is called out.

AEGIS believes in minimal admin surface area, but not zero. This page explains the surface area that exists.

The principle

AEGIS draws a line:

• Compile-time constants. Parameters that define the safety envelope of the protocol. These cannot be changed without deploying new contracts. Examples: MAX_LTV_PIPS, UTILIZATION_CAP_PIPS, MAX_NFTS_PER_VAULT, TWAP_WINDOW, N_TICKS, MIN_LIQUIDITY.

• Policy-governed parameters. Parameters that can be tuned to reflect market conditions or pool-specific requirements. These are controlled by the policy owner. Examples: baseFeeFactorPpm, polSharePpm, marketProtocolFeeBps, surgeDecayPeriodSeconds, hook authorization.

• Pool-level configuration. Per-pool policy values set at pool creation, tunable by the policy owner thereafter within policy-manager bounds.

The separation is deliberate. The user-safety guardrails are not adjustable. The economic-tuning knobs are.

Compile-time constants

These are hard-coded in the contract source. Changing any of them requires a new deployment (at a new address — CREATE2 makes the new address a different artifact). A list with references:

Constant	Value	Where	Purpose
MAX_LTV_PIPS	980,000 (98%)	AegisEngine	Session-end LTV cap for vault solvency.
UTILIZATION_CAP_PIPS	950,000 (95%)	AegisEngine	Max fraction of pool L that can be borrowed.
MAX_NFTS_PER_VAULT	4	AegisEngine	Cap on attached CL/LO NFTs per vault.
MIN_LIQUIDITY	TODO: confirm	AegisEngine	Minimum sL share delta for mint/burn.
TWAP_WINDOW	30 minutes (1,800 s)	AegisEngine	Oracle TWAP window for micro-liq gate.
N_TICKS	5	AegisEngine	Max TWAP-to-spot tick deviation for micro-liq.
MAX_IDLE_CURRENCIES	TODO: confirm	AegisEngine	Cap on distinct currencies held in vault idle.

These are the safety envelope. If you are auditing AEGIS or reviewing the protocol for a consumer-protection perspective, these are the values to verify in the deployed bytecode.

Owner-controlled functions

The protocol has an owner address. This address is the root authority over tunable policy. The owner key is expected to be held by a multisig; specific configuration is published in the deployed-contracts page.

TODO: confirm owner multisig signers, threshold, and timelock policy. Working assumption: 3/5 multisig with 48h timelock on all parameter changes except emergency pause, which has a shorter timelock or none.

Owner functions on AegisEngine

• setHookAllowed(address hook, bool allowed) — add or remove a hook from the authorized set. This gates which pools Engine will treat as Engine-enabled. Effect: new sessions on an unauthorized hook revert; existing sessions complete normally.

• setMarketProtocolFee(PoolId poolId, uint16 bps) — set the per-market protocol fee share (0-10,000 bps). Default: TODO: confirm — working assumption 500 bps (5%).

• setRateOracle(PoolId poolId, IVariableInterestRate) — set or unset the per-market rate oracle. Zero means use default.

Owner functions on PoolPolicyManager (DFM)

• setPoolPolicy(PoolKey, PolicyStruct) — write a new policy struct for a pool. All DFM-tuning parameters are inside this struct.

• setDefaultPolicy(PolicyStruct) — change the policy applied to new pools that don't specify one.

• setHookFeePpm(PoolKey, uint32) — update the hook fee portion for a pool. Bounded by PPM_SCALE.

• setPolSharePpm(PoolKey, uint32) — update the POL share for a pool.

• pauseAutoTune(PoolKey, bool) — freeze baseFeePPM at its current value. Surge still works; only the MTB auto-tune loop is frozen.

• emergencyPause(PoolKey, bool) — TODO: confirm scope — expected to halt new swaps on the pool if invoked, but this is a pool-manager-level action.

Owner functions on TruncGeoOracleMulti

• setHookAllowed(address hook, bool) — authorize or deauthorize a hook for recording observations.

• setPolicyManager(address) — point the oracle at a policy manager (usually set once at deploy).

Owner functions on DynamicFeeManager

• setHookAllowed(address hook, bool) — authorize / deauthorize hooks.

• setOracleManager(address) — update the oracle reference.

• setPolicyManager(address) — update the policy manager reference.

Owner functions on FullRangeLiquidityManager

• setHookAllowed(address hook, bool) — authorize / deauthorize hooks for POL operations.

• TODO: additional owner functions — confirm from contract source.

Functions anyone can call

A sampling of the public surface that doesn't require ownership:

• AegisEngine.aeUnlock(...) — start a session from a router (permissionless).

• Session actions (borrowL, repayL, modifyLiquidity, attach/detach, deposit/withdraw idle) — gated by vault ownership / authorization, not protocol ownership.

• Spot.pokeReinvest(poolId) — trigger POL compound. No reward, permissionless.

• OracleManager.increaseCardinalityNext(poolKey, n) — grow oracle capacity. Caller pays the gas.

• peel(...), microLiq(...) — keeper actions, permissionless.

• All DFM view functions (getLatestFeeQuote, getFeeState, isCapEventActive, etc.).

Rate oracle: pluggable per market

Engine markets can point at any IVariableInterestRate-conforming oracle. The default is a Frax-style kinked utilization curve deployed with the engine. Owner can swap it per market with setRateOracle.

TODO: document the default rate curve's exact parameters once finalized.

The contract interface (simplified):

interface IVariableInterestRate {

function getNewRate(

uint256 totalRlBorrowed,

uint256 equityL,

uint64 oldFullUtilRate,

uint64 dt

) external view returns (uint64 newRate, uint64 newFullUtilRate);

}

Protocol invariant: changing the rate oracle does not invalidate existing debt. The new oracle takes effect from the next accrue. Existing rLWad and borrowIndexWad persist.

Protocol fee: structural, not surprise

The marketProtocolFeeBps is charged as a share of accrued interest. It is not a fee on borrow, repay, or deposit. The value is bounded [0, 10,000] bps. When an accrue runs, the protocol share is minted as new sL to the protocol address.

The protocol address is TODO: confirm — working assumption is the same owner multisig, but could be a dedicated fee receiver.

Changing marketProtocolFeeBps does not retroactively affect already-accrued interest; it only affects future accrual.

What is NOT governed

To be explicit about what the owner cannot do:

• Cannot drain user funds. There is no withdrawal function from the pooled full-range position except via sL burn or borrow/repay. The owner address is not privileged against the market's math.

• Cannot change outstanding debt. rLWad and borrowIndexWad are market state. An owner action cannot edit a specific vault's debt.

• Cannot raise MAX_LTV. This is compile-time.

• Cannot remove the TWAP gate. This is compile-time.

• Cannot force-close a vault. Only peel + micro-liq (permissionless, economically driven) or owner-authorized close-out paths that respect the vault's economics.

• Cannot force sL transfers. ERC-6909 semantics; balances are user-owned.

• Cannot mint arbitrary sL. The only mint paths are modifyLiquidity (pays L), accrue (protocol share), and internal engine-side paths that are mathematically bound.

Upgrade model

AEGIS contracts are not upgradeable in the proxy sense. There is no transparent proxy, no UUPS, no diamond. If a contract needs to change, a new version is deployed and pools are migrated to it.

This is a deliberate choice:

• No proxy admin key, no selector collisions, no storage-layout bugs.

• Every deployed contract is immutable at its address.

• Cross-chain verification is mechanical (same bytecode = same address via CREATE2).

The trade-off is that bug fixes require migration, not in-place patching. The protocol accepts this cost for the simplicity benefits.

Deployment governance

The deployment process is:

1. Contracts are compiled at a specific commit (Git SHA recorded in the release).

2. Create2Deploy.s.sol runs across all target chains with a shared salt, producing identical addresses.

3. Deployed addresses are verified on each chain's block explorer.

4. Initial policy parameters are set on-chain via owner transactions.

5. Addresses are published in Deployed Contracts.

Each step is publicly verifiable. The deployment script is in the repo (script/Create2Deploy.s.sol for DFM, and the Engine equivalent).

Emergency response

If a critical issue is detected post-launch, the primary response mechanisms are:

• Pause auto-tune on affected pools via PoolPolicyManager.pauseAutoTune. Freezes fee adaptation without stopping the pool.

• Deauthorize the hook via AegisEngine.setHookAllowed(hook, false). Stops new Engine sessions on that pool; existing positions can still close.

• Communicate. TODO: establish and document the AEGIS security disclosure channel — expected: a [email protected] or equivalent, plus the usual channels (X, Discord) for status updates.

There is no "pause all lending" super-kill. This is a conscious trade-off: the safety envelope is already mathematically enforced in compile-time constants, so a universal pause would add operational risk without adding safety benefit.

Role summary

Role	What it controls	Who holds it
Owner (of each contract)	Tunable parameters, hook authorizations	TODO: multisig address — published per chain
Protocol fee receiver	Receives marketProtocolFeeBps share of accrued interest	TODO: confirm — likely owner multisig
Vault owner (per vault)	Actions on that vault (borrow, repay, attach, withdraw)	End user, the address that created the vault
sL holder	LP shares, redeemable for L	End user, via modifyLiquidity with positive delta
Keeper	Peel and micro-liq actions	Anyone — permissionless
Router	Wraps session lifecycle	Typically AEGIS-deployed, but not privileged; a third party can deploy their own router

---

Next: Security, Audits, and Status — the audit history, production readiness, and open issue inventory.

---

Security, Audits, and Status

This page is the honest status page. Read it before deciding whether to interact with AEGIS.

The two products, separately

AEGIS ships two products on distinct timelines:

• DFM — production-hardened, audited, deployed on canary pools since TODO: start date.

• Engine — under active development, audit-in-progress, not yet deployed to mainnet production.

Treat them as two artifacts with independent maturity.

DFM status

Audits

Firm	Scope	Date	Report
Spearbit	Full DFM contract set	TODO: month/year	TODO: report URL
Cantina	Follow-up / delta review	TODO: month/year	TODO: report URL

The DFM repo README notes "Spearbit / Cantina" as audit coverage. For the authoritative scope and findings, consult the report files in AEGIS_DFM/docs/audits/ or the linked URLs once published.

Production exposure

TODO: confirm and update with real numbers once DFM has been running at scale.

Rough shape of expected evidence:

• Canary deployment: N months live on testnet + low-TVL mainnet pools.

• Cumulative swap volume processed: TODO: $X.

• CAP events observed: TODO: N (sanity-check that the auto-tune loop behaves as designed in live conditions).

• POL accrued: TODO: $X of protocol-owned liquidity accumulated from fee share.

• Incidents: none known (or list them here if any occur).

Known DFM caveats

• One-sided residues. If the pool becomes highly imbalanced, fee residues may accumulate one-sided and defer reinvest until paired. This is expected behavior, not a bug, but may cause POL growth to look "stuttering" on extreme days.

• Oracle cardinality. By default, OracleManager has a modest cardinality. If you need longer TWAP history, anyone can pay to grow it via increaseCardinalityNext.

• Pool-specific policy presets. The policy presets shipped with DFM are defaults; for unusual pairs, custom policy may be needed and is at the owner's discretion.

Engine status

Audits

TODO: firm(s), scope, timeline.

Working assumption: at least one major firm (Spearbit, Trail of Bits, ChainSecurity, or OpenZeppelin) for the Engine contract set, with a follow-up review on any material changes. The Engine repo's README calls this out explicitly: "Engine contracts are currently a work in progress. They are not safe for production use."

Development status

As of 2026-04-20:

• Engine architecture is stable (documented in aegis-engine/docs/specs/0100-Architecture-Overview.md and 0150-Statement-of-Intended-Behavior.md).

• Foundry test suite includes invariant tests for equity-neutrality, √K floor monotonicity, session isolation, LTV gating.

• Integration tests exercise Engine + DFM together on forked mainnet state.

• TODO: confirm active development phase — likely "final pre-audit review" or "in audit".

What is not yet done

• Public audit reports.

• Mainnet deployment at non-trivial TVL.

• Live keeper infrastructure (peel + micro-liq operational playbooks).

• Production analytics / subgraph / app integration.

Known Engine caveats and TODOs

The Engine repo openly flags the following areas as needing work before production:

• Rate oracle defaults (fullUtilizationRate initialization, curve parameters) are "reasonable starting values" that may need tuning based on simulation.

• MAX_NFTS_PER_VAULT is currently 4; increasing this has gas implications and requires re-reviewing the C_min SAFE bound.

• The MicroLiq TWAP gate parameters (TWAP_WINDOW = 30min, N_TICKS = 5) are working assumptions; live market data may suggest different values.

• Peel bounty defaults are placeholder.

• Keeper-side tooling (monitoring, transaction submission, MEV protection) is not yet published.

These are not bugs; they are pre-launch tuning work.

The Statement of Intended Behavior

Each repo ships a Statement of Intended Behavior (SoIB) document:

• aegis-engine/docs/specs/0150-Statement-of-Intended-Behavior.md — canonical Engine spec.

• AEGIS_DFM/docs/AEGIS_Statement_of_Intended_Behavior.md — canonical DFM spec.

SoIB documents are the source of truth for:

• Expected invariants (e.g., equity-neutrality of borrow/repay, share price monotonicity in normal operation, session isolation, LTV enforcement).

• Specific properties auditors and reviewers are invited to attack.

• Policy-tunable vs. compile-time parameters.

If a behavior in the deployed contract differs from the SoIB, the SoIB is the intent; the deviation is a bug.

Bug bounties

TODO: confirm whether AEGIS runs a bug bounty program and, if so, the details (Immunefi, self-hosted, scope, top payout).

Working assumption: AEGIS will run an Immunefi-style program covering DFM and (once deployed) Engine. Scope, payouts, and disclosure process will be published when the program goes live.

Until a formal program exists, security researchers are encouraged to disclose responsibly via TODO: [email protected] or equivalent channel.

Monitoring

Live monitoring during operation:

• On-chain events. DFM and Engine emit comprehensive event streams. The event list is enumerated in each contract's NatSpec.

• Subgraph. TODO: subgraph URL — indexes the event set and exposes views for LP / borrower / keeper dashboards.

• Status page. TODO: status.aegis.markets or equivalent — for live protocol state (current authorizations, paused pools, any active incidents).

Incident response

If an issue is detected, the AEGIS team's response will follow:

1. Identify scope and affected pools / users.

2. Apply the narrowest possible mitigation (pause auto-tune on affected pools, deauthorize a hook if necessary).

3. Publicly communicate via the status page and direct channels.

4. Coordinate with auditors if a code-level fix is required; deploy new contracts and migrate if needed.

5. Publish a post-mortem.

Historical post-mortems will live at TODO: docs.aegis.markets/incidents or a similar URL, once there is a history to publish.

Risk framing for users

Given the status above, here is a direct framing for would-be users:

• DFM LP on an audited pool: a mature, audited product. Residual risks are smart contract risk (always non-zero) and pool-specific liquidity / volume risk. Reasonable for users comfortable with standard v4 LP exposure.

• DFM integrator (router, aggregator): safe to integrate. The fee model is deterministic and documented.

• Engine LP (pre-mainnet): should not be used in production. Testnet usage welcomed.

• Engine borrower (pre-mainnet): should not be used in production. Testnet usage welcomed.

• Engine integrator (pre-mainnet): can build against the documented API. Expect minor interface changes during the audit phase; lock in against a specific commit.

Once Engine is audited and deployed to mainnet, this page will be updated with production-readiness details. The date on the top of this page (TODO: last updated) indicates when the page was last reviewed.

Comparison with related protocols

For context on how AEGIS's security posture compares to the DeFi environment:

• Uniswap v4 is the base layer AEGIS builds on. v4 is audited by multiple firms; AEGIS inherits any residual risk there.

• Aave / Compound are production money markets with multi-year track records. They have oracle dependencies AEGIS does not, but they also have far more time-tested code.

• Uniswap v3 LP managers (Gamma, Arrakis, etc.) are similar in code-maturity to DFM. They have different risk profiles (active rebalancing rather than passive fee adaptation).

The protocol does not claim to be more or less safe than these; the shape of the safety story is different. AEGIS trades oracle-dependence for pool-internal solvency checks, and static fees for adaptive ones. Whether those trade-offs are attractive is a user-by-user decision.

Sources

• DFM repo: github.com/labs-solo/AEGIS_DFM

• Engine repo: github.com/labs-solo/aegis-engine (TODO: confirm public visibility)

• Audit reports: see the links table above once they are public.

---

Next: Deployed Contracts — the contract address book per chain.

---

Deployed Contracts

This page is the authoritative address book for AEGIS deployments. Addresses here are deterministic via CREATE2 — the same bytecode + the same salt yields the same address on every EVM chain AEGIS deploys to.