Monetarium — Marketing Site

The public marketing site for the Monetarium chain, built solo as part of the same client engagement as the Monetarium block explorer — a Decred-derived multi-coin chain (base coin VAR plus up to 255 SKA-type coins) positioning itself as commodity-backed monetary infrastructure. The site is deliberately engineered to read as institutional financial infrastructure, not a crypto launchpad: restrained, monochrome, typographic.

Live: monetarium.world

The site

A fully static Astro 7 build (output: 'static') served from Cloudflare Workers. Seven content routes — home, tokenomics, whitepaper, philosophy, ways-to-earn, and roadmap — plus an internal design-system reference. Same undisclosed client as the block explorer; this was a solo frontend build, where I owned the design system, the content model, and the build/deploy toolchain end to end.

Engineering highlights

• Ships ~zero JavaScript. Nothing hydrates by default; the only client code is a couple of tiny vanilla <script> islands where interaction is genuinely needed — the theme toggle and a scroll-aware header. Everything else is static HTML.
• Runtime-swappable monochrome theming. A disciplined three-file CSS-token architecture (Tailwind CSS v4 CSS-first @theme): raw color primitives live in exactly one file, a second @theme inline maps Tailwind color utilities onto those primitives so flipping data-theme re-resolves every color live with no rebuild, and markup only ever references semantic utilities (bg-surface, text-accent) — never raw hex. A render- blocking inline script applies the stored theme before first paint to prevent a flash.
• Self-hosted fonts, hermetic build. IBM Plex Sans / Mono and Montserrat are vendored and emitted through Astro’s native Fonts API — no third-party font requests at runtime, no build-time fetch, so builds stay reproducible offline.
• Whitepaper → PDF pipeline. A Paged.js build step (build:pdf) renders the whitepaper content to a paginated, print-quality PDF from the same source of truth as the web page.
• i18n-ready from the start. English-only today, but content is split into three tiers by what it is — scalar UI strings, Zod-validated content collections for prose, and typed locale-keyed datasets — so a second locale is additive, not a rewrite.

Rigor & quality gates

A unit suite (Vitest) covers the pure TS helpers most prone to silent breakage — the build-time design-token parser and the i18n utilities — and a custom token-lint script (check:tokens) guards the theming contract so a stray raw color can’t slip past review. Lefthook hooks auto-format on commit and run the full gate on push, so most failures never reach CI.

Delivery pipeline

CI/CD is three GitHub Actions workflows over one shared DRY gate — check:build (typecheck, format, unit tests, token-drift check, and a full static build), the same command the pre-push hook runs:

• CI verifies every PR with no secrets, so nothing can deploy from a pull request.
• Deploy ships to Cloudflare Workers on push to main, after re-running the full gate.
• Preview gives every PR an isolated preview via a Cloudflare version upload — never a live deploy, so it structurally can’t touch production — at a deterministic per-PR URL, posted back as one sticky PR comment.

The smaller decisions are where the care shows: preview URLs sit behind Cloudflare Access sign-in, with a belt-and-suspenders noindex header injected into preview builds only, so nothing leaks to crawlers during the auth fail-open window; every Action is pinned to a full commit SHA for supply-chain safety; and concurrency groups let a newer push supersede an in-flight run. Staging was deliberately retired once per-PR previews made it redundant.

Scope & honest caveats

This is a content and design site, not a backend application — its sophistication is in the design system, the static-first performance discipline, and the build tooling rather than in application logic. It is also still in active development: content and pages continue to evolve alongside the chain.