KAURAX — Infrastructure Audit

Date: 2026-09-07 Scope: the repository as it stands, before any infrastructure restructuring. Method: live inspection of the running devnet, the source tree, the test suites and the existing CI. Nothing below is inferred from documentation — every claim was checked.

1. Current architecture

What the repository actually is today

A single-package pnpm workspace containing a working Ethereum Layer-3 and one frontend. It is not yet a monorepo in the apps/ + services/ sense.

kaurax/
├── contracts/            Foundry — L2 settlement, L3 predeploys, bridges, AI layer
├── packages/
│   ├── config/           typed configuration loader
│   ├── node/             kaurax-node: sequencer, derivation, batcher, proposer, RPC
│   ├── sdk/              @kaurax/sdk
│   └── cli/              kaurax CLI
├── explorer/             Next.js 16 — explorer + bridge UI + dashboard (12 routes)
├── website/              static index.html
├── chain/                chain config + genesis allocation
├── scripts/              devnet / testnet / deployment shell scripts
├── infrastructure/       docker (3 Dockerfiles), monitoring (Prometheus + Grafana)
├── docs/                 23 documents
└── tests/                end-to-end acceptance test

Network configuration in place

Discrepancy to resolve. The infrastructure brief's example uses chainId 123456 and

symbol KXR. The project already uses 8420 / KAX, and those chain IDs were verified

free against the public registry (chainid.network, 2 750 chains). Per the brief's own

instruction ("ΜΗΝ χρησιμοποιήσεις το παράδειγμα chain ID αν υπάρχει ήδη άλλο"), the

existing values are kept. The `KXR` symbol is not adopted — changing it would break

the genesis, the explorer, the SDK and every document. It is a one-line config change if

you want it; say the word and I will do it properly across the tree.

2. What works

Verified live during this audit — the devnet was running throughout.

Running processes at audit time: anvil ×3 (L1 8545, L2 9545, L3 engine 18420), kaurax-node (8420/8421/7300), next start (3000).

3. What doesn't work / doesn't exist

Not present at all

Present but limited

4. Missing components (by brief section)

5. Security risks

Positive findings: no tracked .env; no private-key literals outside .env.example (which deliberately holds the public Anvil keys); zero TODO/FIXME markers; zero mock or fabricated data; admin RPC namespaces actively blocked and asserted at devnet startup.

6. Deployment risks

7. Recommended changes

Ordered, non-destructive, each verifiable.

1. Restructure to the target monorepo by moving existing directories, not rewriting

them: explorer/ → apps/explorer/, website/ → apps/web/, contracts/ → blockchain/contracts/, infrastructure/ → infra/. Keep packages/* where it is. Add Turborepo. 2. Add PostgreSQL + the indexer — this is the single highest-value addition. It unlocks real address history, token tracking and analytics, and takes the read load off the RPC. 3. Add the backend API (Fastify) with real health endpoints backed by real checks. 4. Build the remaining apps against real data where it exists, and label everything else explicitly Coming Soon / Testnet / Not deployed — never as working production. 5. Nginx + TLS-ready config, with the RPC rate-limited and CORS-scoped. 6. UpCloud `bootstrap.sh` and `deploy.sh`, idempotent, with checks before every destructive step. 7. `deploy.yml` driving SSH deployment, with secrets only from GitHub Actions. 8. Ops documentation: DEPLOYMENT.md, ARCHITECTURE.md, SECURITY.md, CONTRIBUTING.md.

Explicitly not recommended

• Changing the chain ID or the KAX symbol without instruction — it would break genesis, the

explorer, the SDK and the docs for no functional gain. - Rewriting kaurax-node, the contracts or the explorer. They work and are tested. - Adding any paid service. The plan uses Vercel (free tier), GitHub (free), one UpCloud VPS, and self-hosted PostgreSQL/Redis/Nginx in Docker.

8. Constraint: what cannot be verified from here

Stated so that nothing in the deliverable is mistaken for tested:

• No Docker daemon in this environment (colima not running) — every container image

and compose topology is written and statically validated, but not executed. - No UpCloud server, no domain, no DNS control, no TLS certificate, no API keys. All of these become .env.example entries and documentation, never guesses. - Vercel deployment cannot be performed — no authenticated project. The apps are built to deploy, and the configuration is provided.

Everything that can be run locally will be run and its result reported honestly.