Ethereum Oracle

.docker/Dockerfile

@@ -2,9 +2,14 @@ FROM golang:1.24-alpine AS builder
 
 RUN apk update && apk add --no-cache make bash nodejs npm
 
+ARG EXPLORER_BASE_PATH
+ARG WALLET_BASE_PATH
+
 WORKDIR /go/src/github.com/canopy-network/canopy
 COPY . /go/src/github.com/canopy-network/canopy
 
+ENV EXPLORER_BASE_PATH=${EXPLORER_BASE_PATH}
+ENV WALLET_BASE_PATH=${WALLET_BASE_PATH}
 
 RUN make build/wallet
 RUN make build/explorer

.docker/compose.yaml

@@ -1,4 +1,32 @@
 services:
+  anvil:
+    image: ghcr.io/foundry-rs/foundry:latest
+    container_name: anvil
+    ports:
+      - 8545:8545
+    networks:
+      - canopy
+    entrypoint: ["anvil", "-vvv", "--host", "0.0.0.0", "--block-time", "2", "--port", "8545"]
+    volumes:
+      - ./anvil:/anvil
+    healthcheck:
+      test: ["CMD", "cast", "block-number", "--rpc-url", "http://localhost:8545"]
+      interval: 30s
+      timeout: 10s
+      retries: 3
+      start_period: 40s
+  anvil-init:
+    image: ghcr.io/foundry-rs/foundry:latest
+    container_name: anvil-init
+    user: "0"
+    networks:
+      - canopy
+    depends_on:
+      - anvil
+    entrypoint: ["/anvil/anvil.sh"]
+    volumes:
+      - ./anvil:/anvil
+    working_dir: /anvil
   node-1:
     container_name: node-1
     build:
@@ -17,12 +45,11 @@ services:
     command: ["start"]
     volumes:
       - ./volumes/node_1:/root/.canopy
-  #    deploy:
-  #      resources:
-  #        limits:
-  #          memory: 2G
-  #          cpus: "1.0"
-
+#    deploy:
+#      resources:
+#        limits:
+#          memory: 2G
+#          cpus: "1.0"
   node-2:
     container_name: node-2
     build:
@@ -41,34 +68,35 @@ services:
     command: ["start"]
     volumes:
       - ./volumes/node_2:/root/.canopy
-#    deploy:
-#      resources:
-#        limits:
-#          memory: 2G
-#          cpus: "1.0"
-#  node-3:
-#    container_name: node-3
-#    build:
-#      context: ..
-#      dockerfile: .docker/Dockerfile
-#      args:
-#        BUILD_PATH: cmd/cli
-#    ports:
-#      - 30000:30000 # Wallet
-#      - 30001:30001 # Explorer
-#      - 30002:30002 # RPC
-#      - 30003:30003 # Admin RPC
-#      - 9003:9003   # TCP P2P
-#    networks:
-#      - canopy
-#    command: ["start"]
-#    volumes:
-#      - ./volumes/node_3:/root/.canopy
-#    deploy:
-#      resources:
-#        limits:
-#          memory: 2G
-#          cpus: "1.0"
+   # deploy:
+   #   resources:
+   #     limits:
+   #       memory: 1G
+   #       cpus: "1.0"
+  # node-3:
+  #   container_name: node-3
+  #   build:
+  #     context: ..
+  #     dockerfile: .docker/Dockerfile
+  #     args:
+  #       EXPLORER_BASE_PATH: ""
+  #       WALLET_BASE_PATH: ""
+  #   ports:
+  #     - 30000:30000 # Wallet
+  #     - 30001:30001 # Explorer
+  #     - 30002:30002 # RPC
+  #     - 30003:30003 # Admin RPC
+  #     - 9003:9003   # TCP P2P
+  #   networks:
+  #     - canopy
+  #   command: ["start"]
+  #   volumes:
+  #     - ./volumes/node_3:/root/.canopy
+  #   deploy:
+  #     resources:
+  #       limits:
+  #         memory: 2G
+  #         cpus: "1.0"
 
 networks:
   canopy:

.docker/oracle-compose.yaml

@@ -0,0 +1,71 @@
+services:
+  node-1:
+    container_name: node-1
+    image: canopy-node:latest
+    ports:
+      - 50000:50000 # Wallet
+      - 50001:50001 # Explorer
+      - 50002:50002 # RPC
+      - 50003:50003 # Admin RPC
+      - 9001:9001   # TCP P2P
+      - 6060:6060   # Debug
+      - 9090:9090   # Metrics
+    networks:
+      - canopy
+    command: ["start"]
+    volumes:
+      - ./volumes/node_1:/root/.canopy
+#    deploy:
+#      resources:
+#        limits:
+#          memory: 2G
+#          cpus: "1.0"
+  node-2:
+    container_name: node-2
+    image: canopy-node:latest
+    ports:
+      - 40000:40000 # Wallet
+      - 40001:40001 # Explorer
+      - 40002:40002 # RPC
+      - 40003:40003 # Admin RPC
+      - 9003:9003   # TCP P2P
+      - 6061:6060   # Debug
+      - 9091:9091   # Metrics
+    networks:
+      - canopy
+    command: ["start"]
+    volumes:
+      - ./volumes/node_2:/root/.canopy
+   # deploy:
+   #   resources:
+   #     limits:
+   #       memory: 1G
+   #       cpus: "1.0"
+  # node-3:
+  #   container_name: node-3
+  #   build:
+  #     context: ..
+  #     dockerfile: .docker/Dockerfile
+  #     args:
+  #       EXPLORER_BASE_PATH: ""
+  #       WALLET_BASE_PATH: ""
+  #   ports:
+  #     - 30000:30000 # Wallet
+  #     - 30001:30001 # Explorer
+  #     - 30002:30002 # RPC
+  #     - 30003:30003 # Admin RPC
+  #     - 9003:9003   # TCP P2P
+  #   networks:
+  #     - canopy
+  #   command: ["start"]
+  #   volumes:
+  #     - ./volumes/node_3:/root/.canopy
+  #   deploy:
+  #     resources:
+  #       limits:
+  #         memory: 2G
+  #         cpus: "1.0"
+
+networks:
+  canopy:
+    driver: bridge

.env.example

@@ -0,0 +1,10 @@
+# API Keys (Required to enable respective provider)
+ANTHROPIC_API_KEY="your_anthropic_api_key_here"       # Required: Format: sk-ant-api03-...
+PERPLEXITY_API_KEY="your_perplexity_api_key_here"     # Optional: Format: pplx-...
+OPENAI_API_KEY="your_openai_api_key_here"             # Optional, for OpenAI/OpenRouter models. Format: sk-proj-...
+GOOGLE_API_KEY="your_google_api_key_here"             # Optional, for Google Gemini models.
+MISTRAL_API_KEY="your_mistral_key_here"               # Optional, for Mistral AI models.
+XAI_API_KEY="YOUR_XAI_KEY_HERE"                       # Optional, for xAI AI models.
+AZURE_OPENAI_API_KEY="your_azure_key_here"            # Optional, for Azure OpenAI models (requires endpoint in .taskmaster/config.json).
+OLLAMA_API_KEY="your_ollama_api_key_here"             # Optional: For remote Ollama servers that require authentication.
+GITHUB_API_KEY="your_github_api_key_here"             # Optional: For GitHub import/export features. Format: ghp_... or github_pat_...

.llm/api-testing-progress.md

@@ -0,0 +1,73 @@
+# Launchpad API Testing Progress
+
+## Completed Endpoints
+
+| # | Endpoint | Method | Status | Date |
+|---|----------|--------|--------|------|
+| 1 | `/api/v1/explorer/pools` | GET | ✅ Complete | 2026-01-18 |
+| 2 | `/api/v1/wallet/rewards/history` | GET | ✅ Complete | 2026-01-18 |
+| 3 | `/api/v1/validators` | GET | ✅ Complete | 2026-01-18 |
+| 4 | `/api/v1/address-book/favorites` | GET | ✅ Complete | 2026-01-18 |
+| 5 | `/api/v1/users/chain-favorites/{chain_id}` | DELETE | ✅ Complete | 2026-01-18 |
+| 6 | `/api/v1/chains/repository/validate-fork` | POST | ✅ Complete | 2026-01-18 |
+| 7 | `/api/v1/explorer/search` | GET | ✅ Complete | 2026-01-18 |
+| 8 | `/api/v1/chains/{id}` | DELETE | ✅ Complete | 2026-01-18 |
+| 9 | `/api/v1/explorer/trending` | GET | ✅ Complete | 2026-01-18 |
+
+## Notes
+
+### GET /api/v1/explorer/pools
+- Returns paginated pool data from multiple chain schemas
+- Data verified against indexer DB (chain_1, chain_6, chain_100, chain_101)
+- Pagination working correctly (default limit 20, next_cursor provided)
+
+### GET /api/v1/wallet/rewards/history
+- Protected endpoint (requires Bearer token)
+- Returns reward events grouped by source chain
+- Requires `addresses` query param (without 0x prefix)
+- Data verified against indexer DB
+- Minor: chain_name/chain_symbol null for chain_6
+
+### GET /api/v1/validators
+- Returns paginated validator list with multi-chain aggregation
+- **Bug fixed:** Removed status override in `validator/service.go` that incorrectly marked validators as "inactive" based on stale height_time
+- Data verified against indexer DB (62 validators, status now matches)
+
+### GET /api/v1/address-book/favorites
+- Protected endpoint (requires Bearer token)
+- Returns only address book entries with `is_favorite: true`
+- Pagination working (page, limit, total_count)
+
+### DELETE /api/v1/users/chain-favorites/{chain_id}
+- Protected endpoint (requires Bearer token)
+- Removes chain preference (like/dislike) for user
+- Returns success message, preference becomes null after deletion
+
+### POST /api/v1/chains/repository/validate-fork
+- Public endpoint (no auth required)
+- Validates GitHub repository is a valid Canopy fork
+- Checks: repository_accessible, is_fork, not_archived, not_disabled
+- Returns comprehensive validation result with individual check details
+
+### GET /api/v1/explorer/search
+- Public endpoint (no auth required)
+- Supports search by: block height, address (40-char hex), transaction hash
+- Query params: `q` (required), `chain_id` (default: 1), `limit` (default: 10, max: 50)
+- Data verified against indexer DB (blocks, txs tables)
+- Minor issue: `total_transactions` in address results shows returned count, not actual total (explorer.go:591)
+
+### DELETE /api/v1/chains/{id}
+- Protected endpoint (requires Bearer token)
+- Deletes a chain owned by the authenticated user
+- Chain must be in `draft` or `pending_launch` status (not deletable if active)
+- Chain must not have associated transactions
+- Full create→delete→verify flow tested successfully
+- Not currently referenced in canopy-frontend
+
+### GET /api/v1/explorer/trending
+- Public endpoint (no auth required)
+- Returns graduated chains ranked by 24h trading volume
+- Query param: `limit` (default: 20, max: 100)
+- Response includes: rank, chain metrics, 7-day volume history, validators, holders
+- Data verified against `crosschain.validators_latest` and `crosschain.accounts_latest`
+- Risk field is statically set to "Low" for all chains

.llm/dex-paired-deposit-design.md

@@ -0,0 +1,76 @@
+# Cross-Chain DEX Paired Deposit Design (Paused Work Snapshot)
+
+Date: 2026-02-27
+
+## Purpose
+Capture the semi-agreed design direction for protocol-atomic paired liquidity deposits in the root/nested pipelined DEX.
+
+## Problem Statement
+Current DEX deposits are single-leg operations. We want a protocol-level two-sided deposit intent that either settles as a pair or refunds safely, while preserving deterministic LP-point accounting when orders and withdrawals coexist in the same batch.
+
+## What We Agreed On
+1. Introduce a paired deposit intent with explicit identity:
+   - `deposit_id`
+   - `owner`
+   - `amount_root`
+   - `amount_nested`
+2. Add explicit deposit receipts (separate from order receipts) with at least:
+   - `deposit_id`
+   - `success` (bool)
+   - `minted_points` (uint64)
+3. Use one chain as deterministic confirmer/calculator for LP points.
+4. The non-confirmer side mirrors `minted_points` from receipt and must not recompute.
+5. Add idempotent per-deposit status tracking (e.g. `PENDING`, `SETTLED`, `REFUNDED`).
+6. Add timeout/fallback refund behavior if paired settlement cannot complete.
+
+## Clarified Consensus During Discussion
+1. In current branch behavior, DEX batch handling errors in certificate processing are returned (not swallowed), so local processing is effectively atomic at tx/block commit boundary.
+2. Passing receipt-hash mismatch checks does not by itself guarantee rotation; successful function completion is still required.
+
+## Semi-Agreed Processing Model
+1. User submits paired intent legs on each chain (escrow to holding pool).
+2. Each leg is represented in DEX batch data and carried through normal pipeline rotation.
+3. During remote locked-batch processing, designated confirmer determines whether both legs match and emits `DepositReceipt`.
+4. During receipt application for our own locked batch:
+   - If `success=true`: move holding -> liquidity and apply LP points (`minted_points`).
+   - If `success=false` (or timeout): refund holding -> user.
+5. Status map enforces idempotency and replay safety.
+
+## Why `minted_points` Must Be Explicit
+If both sides independently recompute points from local snapshots, drift can occur when execution context differs (orders/withdrawals mixed in batch). A single-source `minted_points` receipt avoids ambiguity.
+
+## NextBatch vs LockedBatch Note
+We discussed matching against `nextBatch`. The current compromise direction:
+- Allow deterministic matching logic, but final settlement authority must remain tied to committed pipeline progression and explicit receipts.
+- Any approach that "consumes" next-batch entries must preserve replay/traceability and idempotent status transitions.
+
+## Open Design Decisions
+1. Deterministic confirmer selection rule:
+   - e.g. lower chain ID always confirms,
+   - or root always confirms,
+   - or derived from `deposit_id` parity.
+2. Receipt schema placement:
+   - extend `DexBatch` with `DepositReceipts[]`,
+   - or encode in a unified typed receipt array.
+3. Timeout policy:
+   - block-based deadline,
+   - liveness fallback integration,
+   - refund trigger side (both sides independently vs confirmer-driven).
+4. Validation strictness:
+   - require exact `(owner, amount_root, amount_nested)` symmetry,
+   - define behavior for malformed/duplicate counter legs.
+5. Interaction with existing liveness fallback and lock lifecycle:
+   - ensure no double-refunds,
+   - ensure no ghost settlement after refund.
+
+## Suggested Implementation Order (When Resuming)
+1. Data model changes (proto/types + status store keys).
+2. Receipt plumbing (serialization, hash inclusion, validation).
+3. Confirmer logic + follower mirror application.
+4. Timeout/refund mechanics + idempotency guards.
+5. Tests:
+   - paired success,
+   - single-leg timeout refund,
+   - duplicate/replay safety,
+   - mixed batch (orders+withdrawals+paired deposits),
+   - fuzz invariants for LP symmetry and supply conservation.