d-bis/proxmox
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix MEV backend and token-aggregation deployment wiring
All checks were successful
Deploy to Phoenix / deploy (push) Successful in 12s
Details

Browse Source
This commit is contained in:
defiQUG
2026-04-15 03:25:30 -07:00
parent 382e776599
commit 59006f520a
12 changed files with 264 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

96
docs/04-configuration/GAS_NATIVE_VERIFIER_WIRING_INVENTORY_AND_REMEDIATION_PLAN.md Normal file
View File

@@ -0,0 +1,96 @@
# Gas-Native Verifier Wiring Inventory And Remediation Plan
This document captures the current state of the Chain 138 gas-native GRU transport lanes and the exact runtime references they still require.
It is intentionally conservative:
- only deployed addresses evidenced in the canonical registry are treated as real
- `CW_ASSET_RESERVE_VERIFIER_DEPLOYED_CHAIN138` is informational until the live L1 bridge is explicitly attached
- gas-verifier envs remain unset until bridge wiring is confirmed
## Current State
Current public GRU preflight status:
- non-gas Mainnet lanes are now ready:
- `138-1-cBTC-cWBTC`
- `138-1-cUSDC-cWUSDC`
- `138-1-cUSDT-cWUSDT`
- remaining Mainnet gas blocker:
- `138-1-cETH-cWETH`
The gas-native transport lanes are defined in [gru-transport-active.json](/home/intlc/projects/proxmox/config/gru-transport-active.json:774) with two reserve-verifier modes:
- `chain138-gas-strict-escrow`
- `chain138-gas-hybrid-cap`
## Runtime Keys
| Env key | Purpose | Current evidence | Current state | Safe action |
|---|---|---|---|---|
| `CW_GAS_STRICT_ESCROW_VERIFIER_CHAIN138` | active verifier for strict-escrow gas lanes such as `138-1-cETH-cWETH` | `CWAssetReserveVerifier` is deployed at `0xbf26a679586663f87f3bf3f52c79479b8aa8d854` | unset on published runtime by design | keep unset until live L1 bridge attachment is confirmed |
| `CW_GAS_HYBRID_CAP_VERIFIER_CHAIN138` | active verifier for hybrid-cap gas lanes such as `cETHL2 -> cWETHL2` | same deployed generic verifier exists | unset on published runtime by design | keep unset until live L1 bridge attachment is confirmed |
| `CW_GAS_ESCROW_VAULT_CHAIN138` | gas-family escrow vault for strict/hybrid gas lanes | no canonical deployed address published in contract reference | unset | inventory deployment artifacts; do not invent |
| `CW_GAS_TREASURY_SYSTEM` | treasury-side reserve accounting for hybrid-cap gas lanes | no canonical deployed address published in contract reference | unset | inventory deployment artifacts; do not invent |
| `CW_ASSET_RESERVE_VERIFIER_DEPLOYED_CHAIN138` | informational pointer to the deployed generic verifier | published in canonical registry | settable now | safe to publish as informational only |
## Canonical Deployed Evidence
Published in [CONTRACT_ADDRESSES_REFERENCE.md](/home/intlc/projects/proxmox/docs/11-references/CONTRACT_ADDRESSES_REFERENCE.md:77):
| Contract | Address | Published status |
|---|---|---|
| `CWAssetReserveVerifier` | `0xbf26a679586663f87f3bf3f52c79479b8aa8d854` | deployed, not yet attached |
| `ReserveSystem` | `0x607e97cD626f209facfE48c1464815DDE15B5093` | deployed for stable reserve flows |
| `BridgeEscrowVault` | not published in canonical address reference for gas rollout | unknown for gas runtime purposes |
| `TreasurySystem` | not published in canonical address reference for gas rollout | unknown for gas runtime purposes |
Gas-family canonical tokens and public mirrors are deployed and published, but runtime verifier wiring is still incomplete.
## Why The Gas Lane Is Still Blocked
The remaining blocker is not token publication and not `CW_MAX_OUTSTANDING_*`.
The blocker is that the gas-family lane requires runtime verifier references that are intentionally left unset until bridge attachment is explicit:
- `CW_GAS_STRICT_ESCROW_VERIFIER_CHAIN138`
- `CW_GAS_HYBRID_CAP_VERIFIER_CHAIN138`
- `CW_GAS_ESCROW_VAULT_CHAIN138`
- `CW_GAS_TREASURY_SYSTEM`
This is consistent with:
- [deploy-token-aggregation-for-publication.sh](/home/intlc/projects/proxmox/scripts/deploy-token-aggregation-for-publication.sh:294)
- [print-gas-runtime-env-canonical.sh](/home/intlc/projects/proxmox/scripts/verify/print-gas-runtime-env-canonical.sh:74)
- [TOKEN_AGGREGATION_REPORT_API_RUNBOOK.md](/home/intlc/projects/proxmox/docs/04-configuration/TOKEN_AGGREGATION_REPORT_API_RUNBOOK.md:100)
## Remediation Sequence
1. Confirm whether the live Chain 138 L1 bridge is already attached to the deployed generic verifier `0xbf26a679586663f87f3bf3f52c79479b8aa8d854`.
2. If attached, publish:
- `CW_GAS_STRICT_ESCROW_VERIFIER_CHAIN138`
- `CW_GAS_HYBRID_CAP_VERIFIER_CHAIN138`
using the confirmed active verifier address.
3. Confirm the deployed gas escrow vault address, if one exists, and publish:
- `CW_GAS_ESCROW_VAULT_CHAIN138`
4. Confirm the deployed gas treasury accounting contract, if one exists, and publish:
- `CW_GAS_TREASURY_SYSTEM`
5. Redeploy or restart the token-aggregation runtime.
6. Re-run:
- `bash scripts/verify/check-gru-transport-preflight.sh https://explorer.d-bis.org`
- `bash scripts/verify/check-gas-rollout-deployment-matrix.sh`
## Known Safe Defaults
Safe to publish now:
- `CW_ASSET_RESERVE_VERIFIER_DEPLOYED_CHAIN138=0xbf26a679586663f87f3bf3f52c79479b8aa8d854`
Not safe to auto-publish without bridge confirmation:
- `CW_GAS_STRICT_ESCROW_VERIFIER_CHAIN138`
- `CW_GAS_HYBRID_CAP_VERIFIER_CHAIN138`
- `CW_GAS_ESCROW_VAULT_CHAIN138`
- `CW_GAS_TREASURY_SYSTEM`
## Operational Boundary
At the moment, the gas-native blocker is a real rollout dependency, not a broken publication script:
- non-gas caps are published and working
- token-aggregation publication is healthy
- the remaining gas lane requires confirmed bridge/verifier/vault wiring
Treat the gas-native lane as `deployment-evidenced but runtime-incomplete` until those four envs are resolved from deployed contracts or explicit rollout policy.

14
docs/04-configuration/MEV_CONTROL_DEFI_ORACLE_IO_DEPLOYMENT.md
View File

@@ -1,6 +1,6 @@
# MEV Control GUI — mev.defi-oracle.io
**Last Updated:** 2026-04-13
**Last Updated:** 2026-04-15
**Document Version:** 1.0
**Status:** Deployment runbook
@@ -17,6 +17,14 @@ This document describes how to publish the **MEV Control** web app (`MEV_Bot/mev
The browser uses **same-origin** `/api` (no CORS split). Set **`MEV_ADMIN_API_HOST`** / **`MEV_ADMIN_API_PORT`** so the nginx CT can reach the backend CT where `mev-admin-api` listens. For the current recommended split topology, keep the public GUI on CT **2410** and point `/api` to a dedicated backend CT on **`r630-04`** (current production backend: **`192.168.11.223:9090`**). Do not host the MEV backend services directly on a Proxmox node unless you are intentionally breaking the portability standard.
The backend CT runtime env must also include:
```bash
MEV_SUPERVISOR_URL=http://127.0.0.1:9091
```
Without that value, `mev-admin-api` cannot proxy `/api/control/*` to `mev-supervisor`, and the worker fleet will not recover correctly after boot or restart.
## Prerequisites
1. **info** nginx LXC exists and nginx works (VMID **2410** by default): see [INFO_DEFI_ORACLE_IO_DEPLOYMENT.md](INFO_DEFI_ORACLE_IO_DEPLOYMENT.md).
@@ -76,7 +84,7 @@ If you intentionally carry **MEV** traffic on the same Cloudflare tunnel stack a
|----------|--------------------------------------------|---------|
| `MEV_DEFI_ORACLE_WEB_VMID` | `2410` | Target LXC |
| `MEV_DEFI_ORACLE_WEB_ROOT` | `/var/www/mev.defi-oracle.io/html` | Web root |
| `MEV_ADMIN_API_HOST` | `192.168.11.11` shared default; override to the backend CT IP (recommended `192.168.11.223`) for the contained split topology | mev-admin-api bind host (from CT) |
| `MEV_ADMIN_API_HOST` | `192.168.11.223` | mev-admin-api bind host (from CT) |
| `MEV_ADMIN_API_PORT` | `9090` | mev-admin-api port |
| `MEV_DEFI_ORACLE_UPSTREAM_IP` | `IP_INFO_DEFI_ORACLE_WEB` | NPM forward target |
| `MEV_DEFI_ORACLE_UPSTREAM_PORT` | `80` | NPM forward port |
@@ -88,6 +96,8 @@ curl -fsS -H 'Host: mev.defi-oracle.io' "http://${IP_INFO_DEFI_ORACLE_WEB:-192.1
# expect: mev-gui-healthy
curl -fsSI "https://mev.defi-oracle.io/" | head -5
curl -fsS "https://mev.defi-oracle.io/api/infra" | jq .
curl -fsS "https://mev.defi-oracle.io/api/health" | jq .
```
After TLS is live, open **https://mev.defi-oracle.io/intel** for in-app framing docs; **/login** if `MEV_ADMIN_API_KEY` is enabled on the API.

6
docs/04-configuration/MEV_CONTROL_LAN_BRINGUP_CHECKLIST.md
View File

@@ -1,6 +1,6 @@
# MEV Control LAN Bring-Up Checklist
**Last Updated:** 2026-04-12
**Last Updated:** 2026-04-15
**Status:** Operator checklist for the current Proxmox / Sankofa LAN
This runbook turns the current MEV Control deployment into a working LAN stack for **`https://mev.defi-oracle.io`**.
@@ -9,8 +9,9 @@ It is based on the repo's current assumptions:
- Public GUI static assets are served from **VMID 2410** (`192.168.11.218`) via nginx.
- The GUI proxies **same-origin** `/api/*` to **`MEV_ADMIN_API_HOST:MEV_ADMIN_API_PORT`**.
- The shared repo default upstream is still **`192.168.11.11:9090`** in [config/ip-addresses.conf](../../config/ip-addresses.conf), but for this deployment we intentionally override it to a dedicated backend CT on `r630-04`.
- The repo default upstream is the dedicated backend CT on **`192.168.11.223:9090`** in [config/ip-addresses.conf](../../config/ip-addresses.conf).
- The admin API expects the pipeline health ports **8080-8087** and graph API **9082** to be reachable on **localhost**.
- The backend CT runtime env must include **`MEV_SUPERVISOR_URL=http://127.0.0.1:9091`** or `/api/control/*` will return `supervisor not configured` and the worker fleet will not start after boot.
Because of that localhost assumption, the cleanest contained split topology for this deployment is:
@@ -166,6 +167,7 @@ Notes:
- `config.dev.toml` expects **Postgres on port `5434`**, Redis on `6379`, and NATS on `4222`.
- This is the easiest way to match the included `docker-compose.yml`.
- If you later promote this to a dedicated Chain 138 config, update `MEV_CONFIG` in the env file and restart `mev-supervisor` and `mev-admin-api`.
- Keep **`MEV_SUPERVISOR_URL=http://127.0.0.1:9091`** in `/etc/mev-platform/backend.env`. This is functionally required, not optional, for boot-time worker recovery.
## 7. Build binaries inside the backend CT