Understand the protection model.

What Aegis is.

Most launchpads send project-owner trading fees directly to the creator. Aegis changes the destination of those economics during a predefined protection period. Each Aegis launch receives its own Protection Vault, and the launch is created through PONS with the creator-side tax fixed at 4% / 400 bps and the Protection Vault set as the creator-fee recipient.

The core idea is economic accountability: creator-side fees accumulate behind the project instead of being immediately available to the creator. A successful project can eventually release those assets after the protection period. A project that meets the objective catastrophic-loss conditions can instead make the vault available to qualifying investors.

What we built.

How a protected launch works.

1. The creator connects a wallet and enters token metadata, pair asset, protection period and optional dev buy.
2. The website reads the current PONS launch configuration and creator-tax cap. The launch stops if required PONS economics have changed unexpectedly or the Aegis router is not permitted to launch.
3. The Aegis Launch Router creates the project's isolated Protection Vault before completing the PONS launch.
4. PONS is called with creatorTaxBps = 400, buyback disabled and the new Protection Vault as the creatorFeeRecipient.
5. The Aegis Registry verifies the resulting PONS launch record on-chain. A token is not treated as an Aegis launch merely because the website says so.
6. The token enters CURVE LIVE / PRE-COVERAGE. Purchases can be recorded, but final Protected Cost Basis is not established until coverage activates after graduation.

Available protection periods in the current contracts are 30, 60, 90 or 180 days. The selected period starts when coverage activates, not when the bonding curve first opens.

The Protection Vault.

Every project receives a separate smart contract that holds or harvests its designated creator-side PONS proceeds. The creator does not receive those assets during the active protection period.

If the period expires normally, the vault can pull outstanding PONS creator fees and release the remaining project pool to the configured creator payout address. If a Protection Event activates, the vault moves into the claims lifecycle instead.

There is no protocol mechanism that mints new $AEGIS, creates protocol debt, or takes another project's vault to make a failed project whole.

Protection lifecycle.

Protected Cost Basis.

Aegis does not blindly insure the price a wallet chose to pay. That would let an insider buy a manipulated top and manufacture an oversized claim.

For purchases made before coverage activation and still held when coverage activates, the position is capped using the Coverage Reference Price. For eligible purchases while coverage is ACTIVE, the same reference-price cap applies.

After WATCH begins, new purchases receive zero new Protected Cost Basis. Selling or transferring tokens reduces the existing protected position. Receiving a token transfer does not create new protected basis for the recipient.

Four protection tiers.

In the deployed implementation, tier qualification is based on $AEGIS staked in the Aegis Tier Vault, not merely tokens sitting in a wallet. Thresholds are percentages of total $AEGIS supply.

The live website includes a Stake $AEGIS interface that reads this Tier Vault directly, handles ERC-20 approval, staking, unstaking and mature-tier activation.

Tier upgrades are not instant. A higher tier requires a seven-day maturity period and does not retroactively increase older protected exposure. If a wallet unstakes enough $AEGIS to no longer support its tier, the effective tier can downgrade immediately.

Who can and cannot qualify.

A Protection Event does not automatically make every holder eligible. The current claim model requires a wallet to have a qualifying protected position and at least a 50% loss on that protected basis.

The creator and creator payout address are automatically excluded by the vault. The Aegis launch router, project token and curve are also excluded system addresses. Because an optional dev buy is delivered to the creator wallet, that dev-buy position remains excluded. Additional known affiliated addresses can be permanently excluded by the protocol guardian.

Transfers cannot wash excluded or unprotected basis into a fresh address: a recipient receives tokens, but the transfer itself creates no Protected Cost Basis.

How claims are calculated.

If the pool contains enough capital to cover all tier-adjusted Claim Weight, each qualifying wallet can receive its full tier-adjusted amount. If the pool is smaller, all qualifying claims are reduced by the same funding ratio.

After a Protection Event, the Position / Claims Engine reconstructs eligible positions from canonical on-chain activity and produces a claim dataset. A reviewed Merkle root and allocation are proposed to the Protection Vault. The vault enforces a 72-hour challenge delay before finalization.

Once finalized, the website's My Claims page retrieves the wallet's finalized amount and Merkle proof from the public Claims API. The wallet signs the claim transaction itself. The Protection Vault verifies the proof and permanently records that wallet as claimed for that Protection Event before transferring funds, preventing a second claim for the same event.

What happens after a 100K → 3K collapse?

Assume the protocol establishes a validated reference market capitalization of $100,000. The token later collapses to $3,000, a 97% drawdown. Market-cap figures are used here only to make the example intuitive; actual Aegis accounting is performed in the project's pair asset.

WATCH would already have closed new protection once the validated price fell 70%. At a 95% drawdown, equivalent to $5,000 in this example, the project enters TRIGGER PENDING. If the validated price remains at or below that threshold for 60 continuous minutes, the Protection Event activates.

Suppose an eligible Tier IV wallet has a Protected Cost Basis equivalent to $1,200. At a 97% decline, its remaining position is worth about $36, so its Eligible Loss is $1,164. Tier IV places the full $1,164 into Claim Weight. If all valid wallets together have $10,000 of Claim Weight but the project's Protection Vault contains only $4,000, the Funding Ratio is 40% and this wallet's final payout is $465.60.

Oracle and TWAP design.

The deployed Aegis oracle requires a 3-of-5 signature quorum for each accepted price report. The Protection Controller accepts observations no more frequently than once every five minutes and maintains a rolling window of 12 observations.

Coverage cannot activate until PONS reports the project as graduated, 60 minutes have elapsed since graduation and the full observation window is available. The resulting rolling price becomes the initial Coverage Reference Price.

Quorum reduces reliance on a single reporter key, but a signature threshold by itself should not be interpreted as proof that the reporters are operated by independent organizations. Users should evaluate the current operational setup separately from the contract's quorum rule.

Designed against manufactured claims.

• Creator exclusion: project creator and payout addresses cannot claim against their own vault.
• Reference-price cap: paying an artificially high execution price cannot raise Protected Entry Price above the established coverage reference.
• No transfer laundering: transfers never create protected basis for the recipient.
• WATCH cutoff: distressed purchases after WATCH create no new protected basis.
• Tier maturity: a higher $AEGIS tier takes seven days to become effective.
• Immediate downside: reducing the staked $AEGIS amount can downgrade the effective tier without a seven-day grace period.
• Persistent trigger: a brief -95% wick cannot activate the Protection Event.
• Fee-route monitoring: if PONS creator-fee routing no longer points to the Protection Vault or a risky pending recipient is detected, Aegis can freeze the vault state for guardian resolution.
• Claim replay protection: the vault stores claimed status by Protection Event ID and wallet.

Mainnet contracts.

The website reads these deployed Robinhood Chain contracts. Source-code verification on an explorer helps users inspect bytecode/source correspondence, but verification is not the same thing as an independent security audit.

Risks and limitations.

• Aegis does not guarantee that any project is legitimate, profitable, liquid or technically secure.
• Aegis does not guarantee full reimbursement. The project's available Protection Vault is the maximum pool from which claims can be paid.
• A project's market price, PONS infrastructure, Robinhood Chain, RPC providers, oracle services, indexing infrastructure and frontend availability can fail or become unavailable.
• Position accounting depends on canonical on-chain activity being attributable under the published rules. The current engine blocks automatic claim publication when a post-graduation trade cannot be attributed unambiguously.
• Smart-contract source verification is not an independent audit. Users should review any published audit reports separately when they become available.
• The public Claims API cannot override the on-chain vault. A fabricated or stale proof will fail the vault's Merkle verification.
• Crypto assets remain highly speculative. Pool-backed protection reduces a defined category of loss exposure; it does not eliminate market risk.