Canopy automation and launch specification
Research update (13 September 2026): all 90 checked current v2 launches have zero core pool fees. Headline pons charges are not automatically income for an outside LP. Fee entitlement is a prerequisite for the proposed vault. Read the historical analysis and evidence.
Status: proposed implementation, 13 September 2026. Read the strategy first. Nothing in this document authorizes deposits or live trading.
Division of responsibility
Use agents to investigate markets, propose changes, and explain decisions. Use deterministic software to calculate positions, enforce limits, and execute approved actions. A language model must not hold an unrestricted signing key or turn social content directly into transactions.
| Component | Allowed responsibility | Forbidden authority |
|---|---|---|
| Research agent | Summarize activity, detect anomalies, propose candidates with evidence | Add contracts to a signing allowlist or invent missing data |
| Allocator | Generate target weights and ranges within a versioned mandate | Increase leverage, limits, or approved asset scope |
| Risk engine | Veto actions based on exposures, freshness, liquidity, and losses | Silently waive a failed check |
| Executor | Build typed transactions from approved actions; simulate and submit | Execute arbitrary agent calldata or arbitrary recipients |
| Reconciler | Verify receipts and actual balance/fee changes | Assume submission means settlement |
| Owner | Approve policy changes, revoke sessions, pause, recover assets | Routine rebalances need no new manual action inside the agreed policy |
New token admission requires an explicit allowlist update during the pilot. Automation applies to allocation and management of approved markets; automatic discovery does not imply automatic admission. Token descriptions, social posts, websites, and model output are untrusted inputs.
Data and identity
The current lib/data.mjs API serves discovery snapshots. DEX Screener search and DeFiLlama rankings are not sufficient for execution, pons provenance, holder analysis, or LP fee reconstruction.
Add a persistent indexer that records chain ID, factory version, launch event, token contract, canonical pool or V4 pool key, manager, hook, fee configuration, token decimals, and lifecycle state. Backfill bounded ranges and retain block hashes to rewind on reorgs. Distinguish observed, confirmed, and policy-finalized events.
Persist swaps, liquidity changes, fee growth, active ticks, ownership relationships, price observations, and known supply changes. Keep raw events and derived features versioned. Record unresolved identity and missing-history states instead of filling them from same-symbol tokens.
Source provenance: the pons v1 documentation describes factory events and bounded log backfills; the project repository separates generations. The v2 documentation path was region-blocked during this review; the repository informed the v2 design. Deployment equivalence remains unverified.
Track V4 pool identity using its full key, including currencies, fee, tick spacing, and hook. Uniswap hooks can alter pool behavior, so a familiar token pair alone cannot establish compatibility. Uniswap hook architecture
Use independent RPC endpoints for state agreement and a verified ETH valuation source. Two RPCs reading one manipulated pool are not independent price discovery. A pool TWAP mitigates some spot manipulation but cannot make a thin market reliable. Quarantine a market when valuation uncertainty exceeds policy limits.
Action lifecycle
Persist every proposal before signing:
proposal → validated → simulated → authorized → submitted → confirmed → reconciled
Alternative states: rejected, expired, pending, reverted, reorged, manual-review.
Each action includes a unique ID, policy version, input block/hash, affected contracts, amounts, range ticks, expected inventory after execution, expected benefit, all-in cost estimate, minimum outputs, deadline, and reason. Record the signed transaction hash, actual deltas, and a structured explanation after execution.
Before submission, recheck balances, permissions, liquidity, quote freshness, and aggregate exposure. Re-simulate if the state has materially changed. Serialize actions per vault; reconcile a pending nonce before replacing or retrying. Never blindly repeat a deposit, swap, or liquidity increase after a timeout.
A constrained session or keeper role should only allow reviewed router/position-manager functions, approved pools, bounded amounts, vault-owned position IDs, and vault recipients. Constrain Permit2/token allowances by spender, amount, and expiry. Enforce key limits at the contract/account layer; browser settings and an agent prompt are not a security boundary. The execution account design is a new component, not something the current wallet connector already provides.
Initial control policy
Values below are hypotheses to validate in simulation; none guarantees loss containment.
| Trigger | Initial action |
|---|---|
| Stale execution state or unresolved RPC disagreement | Block new deployment and swaps; keep reconciling outstanding transactions |
| Proposed position above 10% of NAV or related cluster above 20% | Reject increase; allow feasible reductions |
| Reserve below withdrawal commitments plus gas budget | Block new allocation |
| Price/valuation divergence above a reviewed market-specific bound | Quarantine and request review |
| Estimated rebalance cost above 50 basis points of traded value | Defer routine action; emergency path still needs explicit cost limits |
| Net turnover above 10% of NAV in a day | Pause routine rebalances; log any authorized risk-reduction exception |
| One-day portfolio loss exceeds 5% | Freeze new risk and evaluate orderly reduction |
| Peak-to-trough drawdown exceeds 10% | Pause allocation and require owner review before resuming |
| Unexpected hook/contract change, sell failure, or fee-accounting mismatch | Quarantine affected positions; disable new capital |
Loss triggers can be exceeded before the next observation or during an outage. Avoid unconditional market selling into a collapsing pool. Publish remaining token exposure, feasible unwind amounts, and estimated exit costs when reducing exposure cannot complete.
Ownership, deposits, and withdrawals
Phase one uses operator-owned assets without external deposits. This isolates strategy research from share pricing and public redemption obligations.
For a pooled product, choose a single accounting asset and reviewed vault standard only after specifying asynchronous settlement. A request reserves or escrows shares; settle and burn them only against reconciled assets under a disclosed batch-pricing rule. Define queue order, cancellation, execution-cost allocation, partial fills, and whether an in-kind exit is available. A reserve can accelerate small withdrawals but cannot guarantee liquidity for everyone.
Guard share pricing against manipulated spot NAV, stale positions, uncollected-fee overvaluation, rounding, and donation/inflation attacks. Deposits during uncertain valuation must queue or be disabled rather than dilute existing holders. Do not let an agent change pricing rules. Owner recovery and session revocation must work without the research service; revocation stops future actions, not transactions already finalized.
Validation before capital
- Pool feasibility: on a fork, prove mint → trade → fee attribution → collect → complete withdrawal for each supported deployment. Include v2-specific hook and quote-asset cases. Record code hashes and fee recipients.
- Historical replay: include dead and failed tokens; use only features available at decision time. Reconstruct active liquidity and fees from events, account for Canopy's own liquidity dilution, inventory transitions, gas, hook taxes, and realistic route costs. Do not reuse today's winners as the historical universe.
- Benchmarks: compare identical capital and flows against WETH holding, a defined token hold basket, static LP ranges, and a deterministic rebalancer without agent signals.
- Out-of-sample evaluation: freeze rules before the evaluation window. Run at least 30 days of shadow operation as an engineering minimum; require longer evidence if it does not cover selloffs and quiet markets. Report whether any improvement survives cost and wash-volume sensitivity.
- Fault tests: duplicate jobs, stuck nonces, reorgs, stale quotes, malicious metadata, missing prices, wallet/session revocation, transfer-tax tokens, and keeper outage.
- Capital pilot: use a capped operator-funded amount sized to measured exit capacity, with independent contract/executor review and manual admission. Stop if fee entitlement or loss accounting cannot be reconciled.
- Customer launch: requires reviewed custody, share/fee accounting, redemptions, operations, and applicable jurisdiction/distribution requirements. It is a separate decision from publishing a research dashboard.
Go/no-go criteria: no unexplained ledger discrepancies beyond documented rounding; every action traceable to a policy; no prohibited transaction in fault tests; proven withdrawability; sufficient evidence of positive net economic edge under conservative assumptions. A high gross fee run rate alone fails the gate.
Next implementation tickets
| Priority | Deliverable | Acceptance evidence |
|---|---|---|
| P0 | Versioned pons registry and pool feasibility report | Deployed identity and external-LP fee/exit evidence for one v1 and one v2 candidate, or explicit rejection |
| P0 | Persistent event indexer | Reproducible backfill and reorg rewind; no same-symbol joins |
| P0 | LP replay engine and ledger | Independent reconciliation of inventory and fees on known transactions |
| P1 | Basket eligibility/scoring report | Every include/exclude decision carries timestamped inputs and reason |
| P1 | Shadow allocator | Deterministic proposals with policy/cost checks; no signing capability |
| P1 | Vault research dashboard | Net return, fee attribution, exposures, benchmarks, drawdown, exit estimates, and action history |
| P2 | Constrained executor and recovery | Fork tests and security review before operator-funded use |
| P3 | Deposit/share/withdrawal system | Separate reviewed implementation and launch decision |
The first useful user-facing addition is a Strategy lab screen displaying the hypothetical basket and its measured results. Do not add a functioning “Deposit and earn” button before the ownership, execution, and withdrawal systems exist.