The AMM landed on 96369 on 2026-09-09 (luxfi/standard script/venue.ts,
recorded at deployments/venue/96369.json), so the four fields this file
left unset because nothing was deployed here have addresses to carry:
the two factories whose PairCreated and PoolCreated the subgraph trusts,
the quoter that prices a concentrated route, and the SwapRouter02 a swap
is addressed to.
Changing either factory changes the store's source fingerprint, so the
indexer drops its derived rows and re-reads from block 0 rather than
looking for events already behind its cursor. Applied and restarted: it
read blocks 1..59, 255 events, and values 16 pools at $39,899,893.58 with
LUX at one dollar.
Co-authored-by: Hanzo Dev <[email protected]>
Every card on all five explorers was a skeleton that never resolved. The UI
reads a Blockscout-shaped API, and this backend mounts one per chain at
/v1/indexer/<slug>; with NEXT_PUBLIC_API_BASE_PATH "/" the page asked for
/stats, /main-page/blocks and /config/backend-version, which 404, while the
same paths under the prefix answer 200.
All five also named the same slug's host as their own APP_HOST, so each brand
described itself as explore.lux.network. Each now names its own chain and its
own host: zoo reads zoo, hanzo reads hanzo, pars reads pars, spc reads spc.
Co-authored-by: Hanzo Dev <[email protected]>
One toolchain across the estate. The tree carried 1.26.0, .1, .3, .4 and .5
at once, so which compiler built a binary depended on which repo it came
from.
Co-authored-by: Hanzo Dev <[email protected]>
Each explore-fe Service publishes ui:80 -> 3000, so a router that asks for 3000
is answered with `service port not found: 3000` and the host serves 404. The
five routers now name 80.
Co-authored-by: Hanzo AI <[email protected]>
The four headline cards on explore.lux.network were zeros because the indexer
was pointed at luxd-rpc, and luxd-rpc fronts a StatefulSet whose five bootstrap
addresses are DigitalOcean droplets that no longer accept a connection. That
node never names a frontier, never creates the C-chain, and answers 404 for
every path under /v1/chain/c/rpc; the indexer read nothing from it and reported
`indexed: true` over an empty database. lux-chain answers eth_chainId 0x17871
and a height, so it is what cchain reads now. public_rpc gains the /rpc the
browser needs -- the path it named 404s, so every RPC-backed control on the
page had nothing to dial.
The five explore-fe deployments had no way in. Each host resolves to Cloudflare
and Cloudflare handed the request to an ingress with no router that matched,
which is the 404 they have all been serving. Each brand now names its own hosts,
carried over from the by-hand ingress-chains.yaml minus explore.spc.network,
which does not resolve.
The explorer pod's `explore` sidecar was explore-fe-lux a second time -- same
image, same digest, same brand -- published on a Service port no router named.
The indexer keeps the job only it does.
Co-authored-by: Hanzo AI <[email protected]>
It pulled ghcr.io/parsdao/explore, an image whose repository does not
resolve, and sat in ImagePullBackOff while the other four chains ran the
same luxfi/explore image branded by their own configmap. A second image for
a frontend that is already configured per chain is a second thing to keep
current, and this one was never current.
Co-authored-by: Hanzo AI <[email protected]>
evo carries hanzo.ai/no-ci=true:NoSchedule and is the cluster's only
amd64 node, so an amd64 workload that does not tolerate it has nowhere
to go:
0/2 nodes are available: 1 node(s) didn't match Pod's node
affinity/selector, 1 node(s) had untolerated taint(s)
The 175 pods already on evo predate the taint -- NoSchedule does not
evict -- so none of them tolerates it either, and nothing new can land
beside them. The taint is hand-applied and declared in no repo.
It exists to keep CI runners off the box, which is a fair thing to want.
This is not CI; it is the chain's explorer, and amd64-only. It says so
here rather than being held out by a rule aimed at something else.
Co-authored-by: Hanzo AI <[email protected]>
Each of these mounts a configmap named explore-env-<chain> that was declared
nowhere: the deployments referenced it, nothing created it, and every
frontend sat in CreateContainerConfigError. The same shape as the chain
nodes, whose genesis and startup config never migrated either.
The values are the RUNTIME set only. luxfi/explore's .env.example.lux mixes
build-time and runtime variables in one file — NEXT_PUBLIC_BRAND is read by
`pnpm build`, and the branding, marketplace and homepage URLs were dropped
from the image — so feeding that file to a container fails the validator on
congruity, then on deprecation, then on unknown names.
Co-authored-by: Hanzo AI <[email protected]>
/v1/bank/config answers demoLogin: true with demoEmail: [email protected]
to anyone who asks, and the deployed build falls back to a hardcoded
password when BANK_DEMO_PASSWORD is unset. That fallback is the estate's
documented org convention, so the advertised email and the password were
a pair anyone could assemble -- from the moment api.lux.financial was
routed, which was an hour ago.
The value is a Secret in the namespace, not a line in this file: the
reference belongs in git and the credential does not. It should move to
KMS with the rest.
This keeps the demo working. Turning BANK_SANDBOX off would close the
same door by removing the thing the host exists to show.
Co-authored-by: Hanzo AI <[email protected]>
The console at admin.lux.financial builds absolute URLs against this
host -- const zm="https://api.lux.financial" in its bundle, with no
same-origin path to proxy -- so it rendered and could not sign in while
nothing named the host.
app.lux.financial deliberately did not get this: dashd proxies /v1 to
this Service inside the cluster, so the dash works without the bank's
API being published. That is why it was routed first and alone, and why
this is a separate decision recorded separately.
What this publishes was read off the running pod, not assumed:
/v1/bank/health and /v1/bank/config answer 200, /v1/bank/overview 401,
and /api/collections -- the Base admin surface underneath bankd -- 404.
The framework's own console is not reachable through this route.
Co-authored-by: Hanzo AI <[email protected]>
Both hosts reach this ingress and, with no router naming them, got Go's
`404 page not found` from an empty route table — which is what every
lux.exchange screen that reads an indexer has been drawing.
The indexer is `explorer`, and there is only one. luxfi/indexer builds a single
binary whose own package doc says it "serves only the /v1/indexer/* HTTP API. No
graph engine", so it cannot answer /v1/graph/cchain/amm/graphql at any version
— the only thing the exchange asks an indexer for. luxfi/explorer composes that
same daemon package with the graph engine and mounts both dispatchers. So
lux-indexer.yaml goes: it declared a second deployment for the half this one
already serves, at replicas 0, against a Service (luxd-headless) that does not
exist. Nothing named lux-indexer runs in this namespace.
One chain in the config, because one chain answers. `/v1/chain/C/rpc` on a
mainnet validator returns 0x17871; P X A B Z T D G by name are 404, so are the
four L2 blockchain ids this file carried, and so are api.pars.network,
api.zoo.ngo, api.hanzo.network and api.osage.network. Q, K and M are served and
are not EVM. A row for a chain that is not there polls a 404 forever and decodes
plain text as JSON-RPC.
The chain is reached at `lux-chain.lux-mainnet.svc`, the selector-less Service
whose endpoints are the LAN validators, declared once in deploy/lux-api — so the
public route and this process reach the chain the same way. `luxd-rpc` selects on
a label a gate writes onto luxd PODS, and the validators are not pods here.
Measured after: 20 blocks and 780 transactions ingested from an empty volume in
7s, and lux.exchange/explore draws gLUX off four queries at ~110ms each.
Addresses are read off this chain rather than inherited. native is WLUX at
0x66dbed95… (symbol() answers, 2874 bytes); the 0x4888E4a2… this file named
holds no code here. factory_v2 and factory_v3 are dropped for the same reason —
they name the one contract a subgraph trusts, and neither is deployed on this
chain, so the AMM indexer watches the settlement precompile at 0x9999 and
answers an empty venue for the contract AMM that is not there.
lux-testnet and lux-devnet still carry lux-indexer.yaml. The same reasoning
applies and their chains have not been measured.
Co-authored-by: Hanzo Dev <[email protected]>
Stated where the decision to withhold app.lux.finance already lives, and
generalised past that one bundle: a literal is a claim that was true
once, cannot go stale visibly, and keeps being served after it stops
being true. On a lending surface that is a misstatement.
Recorded with it: the read has an upstream, and the upstream is empty.
No Lux network answers -- lux-mainnet-sync holds zero peers, its five
bootstrappers are the genesis validator set and none is reachable, and
api/rpc.lux.network 404. So there is nothing to total. Until a chain can
answer, the honest rendering of locked value is absent, not remembered.
Comment only; the render is byte-identical.
Co-authored-by: Hanzo AI <[email protected]>
Both hosts reached cloud, which knows nothing about a chain and answers 404 to
every RPC — which is what every Lux interface has been drawing since the old
cluster went away. They reach the validators now.
Those validators are on the LAN and not in this cluster, so the Service carries
no selector and its endpoint is written beside it. The route is a Kubernetes
object because this ingress runs the Kubernetes providers only: the file
provider in hanzo/universe's infra/lan is not enabled here, so a router added
there is a router nobody reads.
The path is `/v1/chain`. `/v1/bc` was the older spelling of the same segment
and is now gone from every node — nothing translates between them, because a
rename kept alive at the edge is a rename that never finishes. The root is a
different question and not a second spelling: a wallet is handed a host, so
api.lux.network IS the C-chain endpoint.
Co-authored-by: Hanzo Dev <[email protected]>
The host resolves and reaches this cluster, and got the ingress's own
404: bank-dash was healthy the whole time and no object named the host.
PRODUCTS.md and the e2e suite both give this host to this workload.
One host is enough here. dashd serves the bundle and proxies /v1 to
bankd in-cluster, so the API the page calls is same-origin and answered
without bankd being published. Publishing a bank's API is a separate act
with a separate blast radius; it is not needed for this page to work and
is not done here.
Co-authored-by: Hanzo AI <[email protected]>
The page this file serves links to app.lux.finance twice, so the host is
expected and answers the ingress's 404. Its route belongs beside the one
above it, and the only published build for it —
ghcr.io/luxfi/finance:1.0.3-amd64 — carries "$125M+ Total Value Locked" as
a literal in its bundle, which the page above no longer prints. The host
stays unrouted until a tag exists that reads that value from the chain.
Comment only: the render is byte-identical.
Co-authored-by: Hanzo AI <[email protected]>
Both Deployments run and both Services carry an endpoint; neither host had
an Ingress, so both answered the ingress's 404. bank-docs serves the docs
site, bank-admin the admin console.
nodeSelector comes from the live objects, which carry it and the files did
not: each image is one linux/amd64 manifest, so a sync of the files as they
stood would have dropped the selector and left the pods schedulable onto an
untainted arm64 node.
Co-authored-by: Hanzo AI <[email protected]>
The Service has no endpoints and no Deployment exists, so the host answers
503. Three things in the file stopped one from starting:
tag v1.5.5 is not published under ghcr.io/luxfi/lux-financial; v1.5.3
is the newest that is
probe liveness named /health, which the image does not serve — its
entrypoint is `node app/site/server.js` and Next answers 404 for
every path that is not a page, so the probe would restart each pod
it started
arch one linux/amd64 manifest, and spark is an untainted arm64 node
ROOT is read by nothing in that image; PORT and HOSTNAME are what the
standalone server reads. Enforcement on, so the object the file describes
is the one that exists.
Co-authored-by: Hanzo AI <[email protected]>
dashd looks up three names — DIST_DIR, PORT and BANK_UPSTREAM. The five
NEXT_PUBLIC_* names do not appear in the binary at all, and the built bundle
asks for /v1/ on its own origin, so NEXT_PUBLIC_BASE_URL was pointing readers
at api.lux.financial, a host that answers 404 for the bank API. Three cookie
names and an empty recaptcha key sat beside it, read by nothing.
Stating the three real ones, and why the pair of them makes this a pod, lets
the file answer the question people bring to it: where the dash sends its API
calls, and what it would take to serve it off the static plane instead.
The live Deployment carries the same four values.
Co-authored-by: Hanzo AI <[email protected]>
The primary-network chains answer to either case; one spelling beats two.
/v1/chain/c/rpc, /v1/chain/p, /v1/chain/x across the estate.
Co-authored-by: Hanzo AI <[email protected]>
Its only copy lived in the DigitalOcean registry the estate no longer
names, and there is none under ghcr or oci.hanzo.ai and no source repo to
rebuild from. The pod has been in ImagePullBackOff for four days.
Claude-Session: https://claude.ai/code/session_018U2e2U4PPc8UaXYyeT9iNu
Its only copy lived in the DigitalOcean registry the estate no longer
names, and there is none under ghcr or oci.hanzo.ai and no source repo to
rebuild from. The pod has been in ImagePullBackOff for four days.
Co-authored-by: Hanzo Dev <[email protected]>
`serviceAccountName` pointed the pod at an account the chart never
creates. The one it named is declared in k8s/lux-mainnet/, which CD does
not apply — it reads deploy/*/*.yaml — so the account did not exist and
the ReplicaSet was refused at every attempt:
pods "rpc-tip-gate-..." is forbidden: error looking up service account
lux-mainnet/rpc-tip-gate: serviceaccount "rpc-tip-gate" not found
No pod was ever created. luxd was up the whole time and the RPC in front
of it was not, which is the shape "the network is down" takes when the
node is fine.
rbac.create renders the account, Role and binding beside the Deployment
that reads through them, so removing one cannot leave the other. The
rules are the raw Role's and no more: pods get/list/patch, namespace
only, no secrets and no cluster scope.
Co-authored-by: Hanzo AI <[email protected]>
The five Lux mainnet validators are docker containers on the LAN host evo,
started by hand: no compose file, no unit, no script. deploy/lux-mainnet/luxd.yaml
addresses a Service on a cluster this estate no longer has, so the only record of
the flags they carry was the running processes themselves.
scripts/validators.sh carries those flags and rolls the fleet one node at a time,
verifying each is back on the version asked for with four peers before touching
the next -- sample 5 / quorum 4 means two down is the network.
Co-authored-by: Hanzo Dev <[email protected]>
The @luxfi/ui site is a static export: an S3 prefix and a host route,
declared the way lux.exchange is declared and released with the same
chart. The fleet's sink route for this host is retired.
Co-authored-by: Hanzo Dev <[email protected]>
project-lux.yaml in hanzo/universe is the one declaration of the lux-fleet
ApplicationSet and its fence; this copy drifted (apiVersion, destination,
KMS group) and CD never read it.
Co-authored-by: Hanzo Dev <[email protected]>
The rebuilt vote is a static export, so it is a site: an S3 prefix and a host
route and no pod, declared the way lux.exchange is declared and released with
the same chart. The Decent-derived app it replaces is uninstalled.
Co-authored-by: Hanzo Dev <[email protected]>
hanzo-build-linux-amd64, lux-build-linux-amd64, zoo-build-linux-amd64 and
every other org-prefixed spelling all meant the same machine. Which org a
job belongs to does not change which host can build it, so the org bought
one pool name per org per arch and each could go stale on its own -- the
evo host alone answered to fourteen names for one label.
One vocabulary now: linux-amd64, linux-arm64, macos-arm64, win-amd64. The
generic labels every plain workflow uses (ubuntu-latest, self-hosted) are
untouched, so naive CI keeps working.
Co-authored-by: Hanzo AI <[email protected]>
Both names answered 404 at every path: the declaration that served them
(k8s/lux-k8s/cdn/cdn.yaml) addressed an in-cluster S3 bucket on DOKS, and that
account is suspended. DNS and the tunnel already deliver both to the ingress --
each returns the ingress's own "404 page not found" -- so what was missing was a
route, not a path to the cluster.
deploy/lux-cdn/lux-cdn.yaml is that route, on the same pattern as every other
static host here: one staticFiles middleware over s3://hanzo-sites/lux/lux-cdn,
one rule matching both names, and no Deployment, because a static host is not a
pod. luxfi/cdn publishes the prefix from its own lane.
NO spaMode, and that is the one place this differs from the sites beside it.
The exchange's rule is that a mark which exists nowhere is reported missing and
never drawn, and that only holds if the host says so: in SPA mode an unknown
path answers 200 with index.html, so a caller asking for a PNG receives an HTML
document, caches it, and reports nothing.
The prefix is lux/lux-cdn rather than lux/cdn because `cdn` is on cloud's
reserved-label list beside api, admin and gateway -- no site may be published at
cdn.<apex> and shadow real infrastructure -- so that slug cannot be created and
the prefix cannot be published to.
assets.lux.network keeps its own declaration in that directory until it moves.
Co-authored-by: Hanzo Dev <[email protected]>
lux-mainnet is five validators with anti-affinity across five hosts. The local
cloud is two, and only one can run the node at all: ghcr.io/luxfi/node publishes
a single amd64 manifest and spark is arm64. Five votes on one host is one vote
wearing five hats, so this is the other thing — one validator, on evo.
Five blockers cleared and recorded in the README, because each cost a cycle and
none is guessable: the 256KB annotation limit that rejects a 949KB genesis, the
image that sets Cmd and no Entrypoint, sybil protection being refused on a
public network id, and a hostPath at /data shadowing the image's own plugin
directory — which makes the C-chain opt out with "chain VM plugin not loaded".
One open: the P-chain never finishes bootstrapping, so C is never created and
there is no RPC.
And a finding that settles the import question. The 218-block testnet RLP has
block 0 = 0x1c5fe377; current testnet genesis produces 0xfc909f7e. The genesis
repo records the change and calls it intentional — both networks were block-0
fresh, so nothing was owed to that history. It cannot be imported and is not
meant to be. Only mainnet's cChainGenesis is locked to its blocks.
Co-authored-by: Hanzo Dev <[email protected]>
All eight lived in .hanzo/workflows, a path github.com does not read, so with
github.com canonical they dispatched nothing at all.
cicd.yml also asked for hanzo-build-linux-amd64 — another org's pool. A
cross-org label does not fail a job, it queues it until the 24h timeout, so
this reads as a slow build rather than a misrouted one. It asks for
lux-build-amd64 now, which is what every other workflow here already used.
The step embedded multi-line Python at column zero — a heredoc terminator in
one repo, an inline -c script in the other — and both dedented straight out of
the run: block scalar, so the workflow did not parse as YAML at all and the
job it belongs to could never start.
It is one indented line now. The lookup is unchanged: read the ApplicationSet,
find the source whose chart is app, print its repository and target revision.
A missing source raises instead of returning nothing, which is the point of
parsing the document rather than grepping it — the comment above already said
a silent miss renders against whatever the registry calls latest.
The step embedded multi-line Python at column zero — a heredoc terminator in
one repo, an inline -c script in the other — and both dedented straight out of
the run: block scalar, so the workflow did not parse as YAML at all and the
job it belongs to could never start.
It is one indented line now. The lookup is unchanged: read the ApplicationSet,
find the source whose chart is app, print its repository and target revision.
A missing source raises instead of returning nothing, which is the point of
parsing the document rather than grepping it — the comment above already said
a silent miss renders against whatever the registry calls latest.
Zoo's cloud and its exchange services were declared here as well as in Zoo's own
repo, and the files had drifted apart. The copy here rendered a pod from a
cluster that is gone; Zoo's serves the site from files and is the one that syncs
clean. Zoo's wins because Zoo's is Zoo's.
Hanzo's operator and zen-gateway were declared here against Hanzo's own
declarations of both. Hanzo's are the ones running.
cert-manager was a third copy of one cluster-scoped install.
liquid-docs put a white-label site on a Lux host. It does not run and does not
belong in this repo. The pre-phase-a backup went with it: a snapshot of a
cluster that no longer exists, carrying the same aliases. The e2e annotation
that named that app says the same thing without it.
deploy/hanzo and deploy/hanzo-zt stay. lux-admin, lux-blog, lux-invest,
lux-safe-cgw and lux-zt-router are Lux services that sit in a namespace someone
named hanzo. The namespace is the thing worth renaming, not the owner.
Zoo's cloud and its nine mainnet services were declared here as well as in Zoo's
own repo, and the files had drifted apart -- zoo-cloud alone differed by half its
length. The copy here rendered a pod from a cluster that is gone; Zoo's serves
the site from files and is the one that syncs clean. Zoo's wins because Zoo's is
Zoo's.
Hanzo's operator and zen-gateway were declared here too, against Hanzo's own
declarations of both. Hanzo's are the ones running.
cert-manager was a third copy of one cluster-scoped install.
liquid-docs put a Liquid-branded site on a Lux host. It does not run and does not
belong in this repo. The pre-phase-a backup went with it -- a snapshot of a
cluster that no longer exists, carrying the same aliases.
deploy/hanzo and deploy/hanzo-zt stay: lux-admin, lux-blog, lux-invest,
lux-safe-cgw and lux-zt-router are Lux services that happen to sit in a namespace
someone named hanzo. The namespace is the thing worth renaming, not the owner.
github.com/luxfi/universe is canonical from here. git.hanzo.ai/lux/universe is
unreachable, and this merge carries its lineage over. The rule applied, per
area:
Workflows: one set, under .hanzo/workflows; .github/workflows is gone.
LLM.md, README.md, deploy/README.md: the forge's. GitHub's sections were the
ones the forge had already rewritten (the /mainnet/v1/bc path table, the
auto-bump flow), not divergent content. Counts brought to what this tree
holds; LLM.md records the rules below.
deploy/applicationset.yaml: the forge's object (apps.hanzo.ai/v1, destination
name lux-cluster) with repoURL https://github.com/luxfi/universe.
deploy/*.yaml modified on both sides: a three-way merge, not a whole-file pick.
Where both moved the pin, the newer semver wins; at the same semver, the side
that pinned a digest (exchange-api 2.3.34 is sha256:3eae48ac, which the
registry confirms; GitHub's zoo copy carried 007beb83, the pre-repush bytes).
Where both wrote cd.automated, GitHub's false wins: it is the later decision
(909d3bd) and the one about the cluster CD now runs on. true stays only on the
static sites GitHub verified there. The forge's /v1/bc -> /v1/chain rename and
its digests are carried into files whose other hunks came from GitHub
(explorer, exchange-api x3, rpc-tip-gate, lux-market).
lux-bank/lux-financial: GitHub's v1.5.5 is not in the registry (the newest
published tag is v1.5.3), so the pin is v1.5.3 with its digest. A pin never
names an image the registry does not have.
Static sites (lux-audio, lux-cloud/cloud, lux-credit, lux-fund, lux-lps,
lux-network, zoo/zoo-exchange): GitHub's three-object declaration — a
staticFiles Middleware, the route that names it, the endpoint-less Service,
no image — replaces the forge's pod. A union would put an Ingress and a
priority-100 IngressRoute on one host with a pod behind it serving nothing.
The forge's last pins, for the record:
lux-audio ghcr.io/luxfi/audio:latest@sha256:48265c37c91f
lux-cloud ghcr.io/luxfi/cloud-web:v1.5.34@sha256:54a586fbd4d6
lux-credit ghcr.io/lux-apps/credit:36b1c2dffd62
lux-fund ghcr.io/lux-apps/fund:20cb7cb988b3 (amd64 only)
lux-lps ghcr.io/luxfi/lps:1.0.2
lux-network ghcr.io/lux-apps/network:latest@sha256:b52dd80f59d7
zoo-exchange ghcr.io/luxfi/exchange:5.149.73@sha256:baefb1903851
Lifted objects (lux-mainnet/{explorer,lux-build,lux-market,rpc-tip-gate}):
the forge's file — the claim, routes, middlewares and rbac it lifted out of
k8s/ — with GitHub's cd.automated: false.
deploy/hanzo/{cloud,commerce-site,iam,lux-bitcoin,lux-coin,lux-finance,
lux-industries,lux-market,lux-safe}.yaml, deploy/lux-ns/lux-exchange.yaml,
deploy/lux-web/lux-network.yaml: deleted, as GitHub did in 2079731. Each Lux
site is declared once, as files, in its own namespace; hanzo's own services
are hanzo/universe's to declare. What the forge had changed in them, so it is
not lost: hanzo/cloud v1.801.476@sha256:0743f907; hanzo/iam IAM_DATABASE_URL
from Secret iam-db; lux-safe ghcr.io/luxfi/safe:v2.2.14; lux-exchange
5.149.83@sha256:7c1bd0e9 with a rateLimit Middleware and the hosts
app.lux.exchange, trade.lux.exchange, exchange.lux.network,
markets.lux.network; lux-web/lux-network at sha 1028f82e.
deploy/zoo-mainnet/: removed. Every Zoo workload is declared in zooai/universe.
Floating tags: every one carries a digest. lux-market and rpc-tip-gate take
the forge's frozen digests back; the rest already had theirs.
k8s/lux-*: the forge lifted k8s duplicates into deploy/ values and deleted
them. luxd-statefulset x3, lux-mainnet/explorer, lux-testnet/{chain-traffic,
exchange-api} stay deleted; what GitHub changed in them (node v1.36.125 pins,
exchange-api 2.3.28, the 50Gi claim, a comment) is behind the values files
(node 1.36.181, exchange-api 2.3.34, the explorer claim). The gateway
configs, luxd-startup ConfigMaps, lux-testnet/explorer and the mainnet
kustomization are the forge's: GitHub's content is a subset of them up to
/v1/bc -> /v1/chain and /v1/health/liveness -> /v1/health/ops/liveness, and
network.yaml, which GitHub's kustomization still lists, no longer exists.
scripts/roll_luxd.sh: the forge's quorum-preserving roll (eviction API, one
pod at a time, digest + version + every-chain bootstrap, devnet -> testnet ->
mainnet) plus GitHub's closing height-and-restart report. The tag is written
in the spelling the values files use (bare 1.36.181) and the digest resolved
for that spelling; a leading v is accepted and stripped. The push remote is
GIT_REMOTE (default origin).
Validated: 123 deploy YAMLs parse; 122 values files render against chart app
0.1.11; no floating tag without a digest; every kustomization that built
before builds now; pin.sh --verify reads 92 pins, 79 agree, 6 are frozen
moving tags whose pointer has since moved (their digests still name real
bytes), 6 are registries a luxfi token cannot read, and lux-financial is the
one it caught.
Co-authored-by: Hanzo Dev <[email protected]>
Every CNAME here named a Cloudflare tunnel that answers 502 or 530, and no route
in the cluster serves any of those hosts, so the record resolved to nothing.
They are now proxied A records on the origin, like every other name in the zone.
The edge answers for them, which is honest about there being no route yet and is
a name a route can be added to.
Co-authored-by: Hanzo Dev <[email protected]>
Every CNAME here named a Cloudflare tunnel that answers 502 or 530, and no route
in the cluster serves any of those hosts, so the record resolved to nothing.
They are now proxied A records on the origin, like every other name in the zone.
The edge answers for them, which is honest about there being no route yet and is
a name a route can be added to.
Co-authored-by: Hanzo Dev <[email protected]>
The Service had no endpoints and no Deployment existed, so all four hosts --
zoo.exchange, www.zoo.exchange, exchange.zoo.network, trade.zoo.exchange --
answered 503 at the origin.
The build is already published at s3://hanzo-sites/lux/zoo-exchange: 41 entries,
index.html at 37825 bytes, and a brand.json naming Zoo Exchange and Zoo Labs
Foundation. So this takes the shape lux-exchange already uses -- a staticFiles
middleware, a route that names it, and the endpoint-less Service the route
schema requires. No image, so the chart renders no Deployment.
That also retires the brand ConfigMap and its subPath remount: the brand is a
file in the prefix.
Co-authored-by: Hanzo Dev <[email protected]>
The Service had no endpoints and no Deployment existed, so all four hosts --
zoo.exchange, www.zoo.exchange, exchange.zoo.network, trade.zoo.exchange --
answered 503 at the origin.
The build is already published at s3://hanzo-sites/lux/zoo-exchange: 41 entries,
index.html at 37825 bytes, and a brand.json naming Zoo Exchange and Zoo Labs
Foundation. So this takes the shape lux-exchange already uses -- a staticFiles
middleware, a route that names it, and the endpoint-less Service the route
schema requires. No image, so the chart renders no Deployment.
That also retires the brand ConfigMap and its subPath remount: the brand is a
file in the prefix.
Co-authored-by: Hanzo Dev <[email protected]>
repository carried 'ghcr.io/luxfi/faucet:v1.0.1'. The chart takes repository and
tag separately and rejects a repository with a tag in it, so this file failed to
render and took its share of the lane's Applications with it. Every other file
under deploy/ already spells it as two fields; this was the only one that did not.
Co-authored-by: Hanzo Dev <[email protected]>
repository carried 'ghcr.io/luxfi/faucet:v1.0.1'. The chart takes repository and
tag separately and rejects a repository with a tag in it, so this file failed to
render and took its share of the lane's Applications with it. Every other file
under deploy/ already spells it as two fields; this was the only one that did not.
Co-authored-by: Hanzo Dev <[email protected]>
Records across these zones named an address this estate does not answer on.
Each now names the origin the edge forwards to.
They are proxied deliberately: Cloudflare answers, the origin is reached only
from Cloudflare, and the address never appears in a public answer. Unproxied, a
record both publishes the origin and makes a reassigned address a live takeover
of the name.
Co-authored-by: Hanzo Dev <[email protected]>
Records across these zones named an address this estate does not answer on.
Each now names the origin the edge forwards to.
They are proxied deliberately: Cloudflare answers, the origin is reached only
from Cloudflare, and the address never appears in a public answer. Unproxied, a
record both publishes the origin and makes a reassigned address a live takeover
of the name.
Co-authored-by: Hanzo Dev <[email protected]>
zoo-fleet reads github.com/zooai/universe, where all three are already
declared with the same images; the copies here were a second Application per
workload on the lux cluster. Five more Zoo services in deploy/zoo-mainnet
(computer, foundation, gym, ui, wallet) exist only here and are left in place
pending the ownership decision to move them to zooai/universe.
Co-authored-by: Hanzo Dev <[email protected]>
The lux-vote declaration named ghcr.io/luxfi/vote while its reasoning was still
about ghcr.io/luxfi/dao-vote — the Decent-derived fork luxfi/dao published, which
no declaration reads. luxfi/vote is the source now and its Image workflow is the
only thing that publishes there; the same workflow builds zoo.vote and
hanzo.vote into their own orgs' registries. The tag is left where it is with a
TODO to pin the first tag that workflow prints: it is what the live Deployment
runs, and it could not be verified from here because ghcr.io refuses an
anonymous pull token for the repository, so it stays a tag rather than becoming
a digest that was guessed.
zoo-vote is deleted here. zoo-fleet's generator reads zooai/universe
deploy/*/*.yaml (hanzo/universe infra/k8s/hanzo-cd/project-zoo.yaml) and
lux-fleet's reads this repository's, so the same workload was declared twice
across two fleets. It is declared in zooai/universe now. The other zoo-mainnet
files here are the same overlap and are left alone — that is a drift audit, not
this change.
Co-authored-by: Hanzo Dev <[email protected]>
The exchange client existed further down the app list; the second entry would
have declared the same clientId twice. lux-vote stays.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev