mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekayandHanzo Dev
230fbb3fe0
None of the three workflows here could run. release.yml's `plan` job named
`lux-build-amd64` and validate-asset-manifests.yml named the bare
`['self-hosted', 'linux', 'amd64']` triple; the pool on this forge is
`lux-build-linux-amd64` and nothing answers to either. A job naming a label no
runner carries does not fail — it waits. So Gate A has not been gating
anything, and it is the gate that proves every DEX asset manifest entry
resolves to a real on-chain asset.
release.yml had a second, independent reason to never produce anything: it
delegated the actual build to
`hanzoai/.github/.github/workflows/docker-build.yml@main`, and a cross-org
workflow_call from luxfi/* into hanzoai/.github fails before any job starts.
luxfi/operator recorded exactly this against exactly this reusable —
"startup_failure on EVERY run since the migration to that reusable ... every
attempt failed at 0-2s with zero jobs dispatched" — and inlined its own build
for that reason. These thirteen plugin images have not been built by this
workflow.
So the plugin build is inlined too, in .hanzo/workflows/release.yml. It is
short: compile the VM to build/<vm> on the runner, then Dockerfile.plugin copies
that one binary into a scratch image, one matrix leg per entry in
.github/images.json. The manifest file stays where it is and is still read from
`.github/images.json` — it is repo metadata, not a workflow.
Gate A becomes .hanzo/workflows/ci.yml with its three checks intact.
Two other things had to change for these to work off GitHub:
* ghcr auth. The reusable was handed the ambient credentials; the direct build
uses GHCR_USER and GHCR_TOKEN, the org Actions secrets sourced from KMS. The
instance GITHUB_TOKEN is a Hanzo Git token and has no rights at ghcr.io.
* arm64. The reusable was asked for an arm64 leg on a
`["self-hosted","linux","arm64"]` pool that does not exist. These images are
amd64-only until we own an arm64 runner and it can return as a native matrix
entry.
Deleted rather than migrated: workflow-sanity.yml. It is
`uses: hanzoai/.github/.github/workflows/workflow-sanity.yml@main` — the same
cross-org reusable call that fails before dispatch, so it has never reported on
anything. The label checking it was meant to provide is what
.github/actionlint.yaml is for, locally.
All three files are accounted for, which is the constraint: the forge stops at
the first workflow directory that exists, so a repo's entire .github/workflows
suite goes dark the moment .hanzo/workflows appears.
Co-authored-by: Hanzo Dev <[email protected]>
Lux Chains
Independent VM plugin binaries for the Lux Network.
Each directory builds to a standalone binary that the Lux node loads as a plugin via --plugin-dir.
Build
make # build all VMs
make evm # build one VM
make test # test all
Install
lpm install evm
lpm install dexvm
Or copy binaries to ~/.lux/plugins/<vmid>.
VMs
One row per directory in this repo. make derives its target list from the
directory listing, so a VM that has no directory here has no binary — the table
below and ls can never disagree.
Live means the VM has a chain registered on Lux mainnet 96369
(platform.getBlockchains).
| VM | Chain | Live on 96369 | Purpose |
|---|---|---|---|
| evm | C-Chain | ✅ | EVM smart contracts |
| dexvm | D-Chain | ✅ | Decentralized exchange |
| aivm | A-Chain | ✅ | AI/ML inference |
| bridgevm | B-Chain | ✅ | Cross-chain bridge — also owns all cross-chain messaging / relay / teleport (LP-6000); there is no separate teleportvm |
| graphvm | G-Chain | ✅ | GraphQL data layer |
| keyvm | K-Chain | ✅ | Key management |
| quantumvm | Q-Chain | ✅ | Post-quantum consensus signing (Pulsar) |
| zkvm | Z-Chain | ✅ | Groth16 over BLS12-381 (rolls N × ML-DSA-65 sigs into 192-byte proof) |
| identityvm | I-Chain | ❌ built, not deployed | Decentralized identity |
| oraclevm | O-Chain | ❌ built, not deployed | Oracle/off-chain data |
| relayvm | R-Chain | ❌ built, not deployed | Cross-chain relay |
| mpcvm | M-Chain | ❌ built, not deployed | MPC ceremonies (CGGMP21, FROST, Pulsar-general) — bridge custody for external wallets (LP-7100) |
| schain | S-Chain | ❌ built, not deployed | S3-style object storage (on-chain metadata / off-chain blob). Declares its own VMID = ids.ID{'s','c','h','a','i','n'} in schain/factory.go and is not in the canonical luxfi/constants VM-ID registry |
P-Chain (platformvm) and X-Chain (xvm) are in-process core VMs registered by
luxfi/node, not plugins built here. Together with the eight ✅ rows above they
are the ten chains live on 96369.
Not in this repo
| Name | Status |
|---|---|
teleportvm / T-Chain |
Removed. LP-134 dissolves T-Chain with zero remainder: threshold signing → M-Chain, FHE → F-Chain, cross-chain messaging/teleport → B-Chain (bridgevm). LP-5013 and LP-7330 are deprecated by LP-134; see LP-7050 for the migration map. No teleportvm VM ID exists in luxfi/constants. |
servicenodevm |
Never existed. The service-node registry was never built under this name; the S-Chain directory here is schain/ and is object storage, not a registry. |
fhevm / F-Chain |
Unbuilt. luxfi/constants reserves FHEVMID = {'f','h','e','v','m'} and luxfi/node/node/vms.go lists it in OptionalVMs as a plugin named fhevm, so luxd will scan --plugin-dir for it — but there is no fhevm/ directory in this repo and no plugin binary anywhere, so that scan always comes up empty. The FHE runtime library lives at mpcvm/fhe/; it is a package inside mpcvm, not a standalone chain. F-Chain is a spec (LP-8200, LP-167) with no shipping VM. |