docs(chain138): canonicalize Stack-A DODO PMM stack (live, traded) #17
Reference in New Issue
Block a user
Delete Branch "devin/1777435956-stack-a-canonicalization"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
On-chain probe (2026-04-22) confirms two parallel
DODOPMMIntegrationdeployments on Chain 138. Stack A is the live, traded one; Stack B (which earlier docs cited as canonical) is seeded but un-traded. This PR re-canonicalizes the project rule and two reference docs to reflect on-chain reality.0x86ADA6Ef91A3B450F89f2b751e93B1b7A32188950x5BDc62f1ae7D630c37A8B363a1d49845356Ee72d0x3f729632E9553EBacCdE2e9b4c8F2B285b014F2e0x5CAe6Ce155b7f08D3a956F5Dc82fC9945f29B381isKnownPool=true, asymmetric / traded balancesStack A pools (all
isKnownPool=true, all traded)0x9e89bAe009adf128782E19e8341996c596ac40dC0x866Cb44b59303d8dc5f4F9E3E7A8e8b0bf238d660xc39B7D0F40838cbFb54649d327f49a6DAC9640620x67049e7333481e2cac91af61403ac7bddfab7bcd0x72f1a0794153c3b8a1e8a731f1d8e1a52cb10dc50xb53a0508940b1ff90f1aad4f6cb50a7012fe55930xe227f6c0520c0c6e8786fe56fa76c4914f8615330xf3e8a07d419b61f002114e64d79f7cf8f7989433Files changed
.cursor/rules/chain138-tokens-and-pmm.mdc— replace integration + pool addresses with Stack A; add provider, cBTC, full pool table.docs/11-references/ADDRESS_MATRIX_AND_STATUS.md— re-version to 2026-04-22; show both stacks with status flags; add 5 cBTC/WETH pools; flip EnhancedSwapRouter row from Not deployed to Pending Phase 3.docs/11-references/PMM_DEX_ROUTING_STATUS.md— rewrite executive summary, surface both stacks, refer to staged Phase 3 deploy.No code change. Companion to atomic-swap-dapp PR #4 (frontend routing-honesty) and the upcoming Phase 3 EnhancedSwapRouter LAN deploy.
How verified
On-chain probe via public RPC
https://rpc.d-bis.org:dodoIntegration()on each provider — confirms pairing.isKnownPool(pool)per provider for both stacks' pools — confirms which provider owns which pools.IDODOFlexibleOraclePMMPool.balances()on every pool — confirms Stack A is asymmetric/traded, Stack B is flat.Full report:
test-plans/phase2a-wrapper-executor-abi-verification.md§ Phase 2a-2 reconciliation.Closes the gap where phoenix-deploy-api/server.js on master is the real implementation, but the running service on CT 5700 is the older stub that returns 'Deploy request queued (stub)' for every target. The new workflow .gitea/workflows/bootstrap-phoenix-deploy-api.yml is manual-only (workflow_dispatch). When triggered it: 1. Validates the repo layout (phoenix-deploy-api/server.js MUST NOT contain the stub string). 2. Tars phoenix-deploy-api/ + config/public-sector-program-manifest.json into a deploy bundle. 3. scp's the bundle to the PVE node that hosts CT 5700 using a dedicated deploy SSH key (PHOENIX_PVE_SSH_KEY repo secret). 4. pct push / pct exec the bundle into the CT and runs the existing phoenix-deploy-api/scripts/install-systemd.sh which already drops /opt/phoenix-deploy-api/, writes the systemd unit, and restarts the service. 5. Health-checks GET http://<dev-vm>:4001/health (with retry). 6. Posts a non-stub probe: POST /api/deploy with target __bootstrap_probe__ + the deploy bearer token. Fails the workflow if the response body still contains 'Deploy request queued (stub)' or any auth-rejection signal. That gives an unambiguous post-bootstrap health signal in CI logs without depending on a successful real deploy. Required new secrets (documented in docs/04-configuration/DEVIN_GITEA_PROXMOX_CICD.md section 3a): PHOENIX_PVE_HOST, PHOENIX_PVE_USER (default root), PHOENIX_PVE_SSH_KEY, PHOENIX_PVE_KNOWN_HOSTS (optional), PHOENIX_DEV_VM_VMID (default 5700), PHOENIX_DEPLOY_DEV_VM_IP (default 192.168.11.59). Triggered manually only — bootstrap is sensitive enough that we do NOT fire on every master push. Once the running service on CT 5700 is post-stub, the existing deploy job in deploy-to-phoenix.yml will actually execute scripts/deployment/deploy-atomic-swap-dapp-5801.sh on each push instead of returning a 202 stub. Co-Authored-By: Nakamoto, S <defi@defi-oracle.io>Claude encountered an error —— View job
I'll analyze this and get back to you.