Perfect — you’re basically describing a rules-based allocation engine that lives on-chain, wrapped as a single token ($LOGOS). Every inflow of USDC gets split according to a formula, then deployed into the underlying assets based on predefined “zones” (drawdowns from ATH). Let’s break this down into a system design you (or a solidity dev) could implement.
1. Core Idea
Backed by a basket: BTC (30%), ETH (30%), WLD (15%), USDC (25%). When new USDC comes in, the contract: Allocates to each asset per weights. Applies the Buy-In Formula (ATH zone rules). Executes buys (or parks in USDC) automatically. All investors, including you, follow the exact same logic. 2. Buy-In Formula (Zone Logic)
For each asset (BTC, ETH, WLD):
Note:
If capital is not deployed (e.g. Red zone), it remains as USDC within the vault until an eligible zone is reached. This way you never force buys at euphoric highs. Over a 24-month horizon, the system gradually releases USDC as drawdown triggers are met. 3. Allocation Engine
When USDC comes in (example: $500k):
Step 1: Split into buckets by target weights: Step 2: For BTC/ETH/WLD buckets, check each ATH % zone. If Green (–50%+ down): deploy full bucket. If White (–20% to –40%): deploy only partial (say 25–33%). Rest waits in USDC. If Red (near ATH): defer entire bucket, keep in USDC. Step 3: Vault now holds a mix of: Idle USDC awaiting triggers 4. Automation
Oracle Needed: Contract must know ATH for each asset and live price (Chainlink feeds or custom oracle). State Machine: Each asset has a state (Red/White/Green). Buy logic only fires if rules are met. Buy Scheduler: Either automated via keepers (e.g. Chainlink Keepers, Gelato) or user-triggered when capital comes in. 24-Month Horizon: You can code a “decay function” so idle USDC must be deployed by a deadline, unless paused. 5. Manual Controls
Even though it’s automated, you’ll want:
Pause Switch: You (as manager) can pause all new buys in extreme market conditions. Rebalance Function: If weights drift (e.g. BTC moons to 50% of portfolio), rebalance back to targets. Extend Window: Option to extend 24-month deployment horizon if conviction says “stay patient.” 6. Example Flow
Contract splits: $150k BTC, $150k ETH, $75k WLD, $125k USDC. BTC = –35% from ATH → White zone → Deploy $50k now, keep $100k in USDC. ETH = –55% from ATH → Green zone → Deploy all $150k. WLD = –15% from ATH → Red zone → Deploy nothing, hold $75k in USDC. BTC: $50k deployed, $100k parked. WLD: $0 deployed, $75k parked.
Vault composition adjusts dynamically as zones change.
7. Dev Roadmap
Spec: Write JSON-like spec of allocations + zone logic (exact % for partial vs. full buys). Contract: Smart contract vault that: Accepts USDC deposits → mints $LOGOS. Routes per allocation & buy logic. Uses Chainlink/keepers to monitor prices. Frontend: Simple dashboard showing: Idle USDC awaiting triggers Zones for each asset (Green/White/Red) Audit: Ensure logic can’t be bypassed or manipulated (esp. ATH oracle). ✅ Key Idea:
Every inflow, whether it’s you or a new investor, goes through the exact same machine. No emotion. No “when do I get in?” questions. The system enforces discipline.
Want me to codify this into a pseudo-smart-contract spec (almost Solidity pseudocode) so you can hand it to a dev and say “build exactly this”?
Awesome—let’s make this airtight and emotion-free. Below is a simple framework, real numbers you can use today, and a backtest you (or your dev) can run anytime to keep us honest.
The Rules-Based Buy Engine (per asset)
Let ATH be the all-time-high, P the current price, and the drawdown
D = \frac{ATH - P}{ATH}.
Zones & deployment for each asset bucket (e.g., the BTC portion of a deposit):
Red (near highs): D < 0.20 → 0% (hold in USDC) White (mid drawdown): 0.20 \le D < 0.50 → proportional DCA \text{Deploy \%} = \frac{D - 0.20}{0.30} (so 20% down = 0%; 35% down = 50%; 49% down ≈ 97%) Green (deep drawdown): D \ge 0.50 → 100% (deploy all remaining for that asset)
You evaluate each asset independently when a new deposit hits the vault. Whatever isn’t deployed stays as that asset’s USDC sub-bucket until a deeper zone is hit (or a time-based release rule forces deployment).
Worked Example (today’s logic)
Your portfolio weights for a deposit: BTC 30% / ETH 30% / WLD 15% / USDC 25%.
Deposit arrives: $500,000.
Split: BTC $150k, ETH $150k, WLD $75k, USDC reserve $125k. Compute D for each from live price + ATH (contract reads Chainlink oracles): If BTC is −35% from ATH → White → Deploy% = (0.35 − 0.20)/0.30 = 50% → buy $75k BTC; keep $75k in USDC sub-bucket. If ETH is −55% from ATH → Green → Deploy $150k ETH. If WLD is −15% from ATH → Red → Deploy $0; keep $75k in USDC. USDC reserve (25% = $125k) stays intact for future triggers.
Everything is deterministic; every investor (including you) goes through the exact same machine.
What does this do versus plain DCA in the last 24 months?
Context (approximate two-year window):
BTC: late-2022 lows near −77% from ATH; much of 2023 sat ≥ −50% (Green), then rallied through 2024–2025. ETH: similar pattern (lows around −80% from ATH; Green for much of 2023; strong rally in 2024–2025).
If you started 24 months ago with $150k per asset, your rule would have deployed heavily early (Green), then stopped as prices approached prior ATHs. Plain monthly DCA would have kept buying higher all the way up.
Below are illustrative (but directionally accurate) outcomes using rough averages; they show why the rule beats plain DCA when a cycle recovers:
BTC (bucket = $150,000)
Rules-based (heavy buys in Green): avg cost ≈ $31k/BTC → ~4.84 BTC Ending value at $119k ≈ $576k Plain monthly DCA (kept buying up): avg cost ≈ $55k/BTC → ~2.73 BTC
ETH (bucket = $150,000)
Rules-based: avg cost ≈ $1,900/ETH → ~78.9 ETH Ending value at $4,633 ≈ $366k Plain monthly DCA: avg cost ≈ $3,000/ETH → ~50 ETH
Takeaway: The rules engine front-loads into deep drawdowns and stops near peaks. In recovery cycles, this materially lowers cost basis versus blind DCA.
Want precision? Run the backtest below on exact daily closes. It will output the true average cost, units bought, and ending value for both methods.
Backtest spec (hand to your dev)
Inputs
Asset list: [BTC, ETH] (extendable to WLD/ENS/etc.) Historical daily closes for the last 730 days ATH per asset (compute from the lookback window or store canonical ATH)
Logic
For each day, compute D = (ATH - P) / ATH. Rules method (deposit schedule): Simulate a staged deployment of the $150k bucket over the 24-month window: On any day with Green (D ≥ 0.50): deploy all remaining bucket for that asset. On any day with White (0.20 ≤ D < 0.50): deploy proportional DCA for that day: \text{daily\_deploy} = k \cdot \frac{D - 0.20}{0.30} where k is a daily throttle so you don’t spend the entire bucket in one white day (e.g., cap to 1/60 of the bucket per White day). Unused capital rolls forward. Track units acquired and cash remaining. Equal daily/weekly purchase splitting the $150k across all days or weeks (e.g., 104 weekly buys). Compute avg cost, total units, ending value at current price.
Suggested tuning for White zone throttle k:
Pick a fixed “spend runway” (e.g., 60 White-zone trading days). Set k = \min\left( \frac{\text{remaining\_bucket}}{\text{remaining\_white\_days}}, \ \text{daily\_cap} \right) \times \frac{D - 0.20}{0.30}. If Green arrives, deploy all remaining immediately.
This balances “proportional to drawdown” with “don’t overspend White too fast.”
Contract-level spec (pseudo)
weights = {BTC:30%, ETH:30%, WLD:15%, USDC:25%} ath[token] stored; only increases via manager or an on-chain rule (e.g., price > stored ATH for N blocks). price[token] via Chainlink. For each token in {BTC, ETH, WLD}: bucket = amount * weight[token] D = (ath[token] - price[token]) / ath[token] If D < 0.20: reserve[token] += bucket If 0.20 ≤ D < 0.50: deploy = throttle(token) * (D - 0.20)/0.30; buy(token, deploy); reserve[token] += bucket - deploy If D ≥ 0.50: buy(token, bucket + reserve[token]); reserve[token] = 0 reserveUSDC += amount * weight[USDC] throttle(token) returns a cap based on time left in the 24-month window and remaining reserve for that token. pause() / unpause() implemented. Keepers run rebalance() and checkAndDeploy() daily. Answering your two core questions
Q1. “When do I make the bigger moves with my remaining USDC?”
When the asset is ≥ −50% from ATH (Green). The machine deploys all remaining for that asset. If we’re −20% to −49% (White), it drips proportionally; the deeper the drawdown, the more it spends each day/week. Near ATH (Red) it holds.
Q2. “How do I handle new investors who arrive when it’s hot?”
Every dollar (yours and theirs) follows the same machine at the vault level. If it’s hot (Red), their bucket sits in USDC until White/Green reappears. If it’s White/Green, it deploys per formula. That’s how we keep entries fair and unemotional.
If you want, I’ll generate a small CSV-driven notebook you can run locally that ingests CoinGecko daily closes and prints a comparison table (Rules vs DCA) for BTC and ETH over the last 24 months with your exact buckets.
