One system, carried from vision to working testnet.
The method has eight phases. Each one resolves a different class of decision, produces an artifact, and prepares the next phase to begin without losing the original vision.
Discovery through Observatory — one architect, one thread.
Determine what the system must be.
The first three phases turn a founder’s conviction into a system with a defined shape: what it makes possible, who acts inside it, and how the economics hold together.
Discovery
I begin by learning the founder’s vision, the reason it matters, and what the system must make possible. We test that vision against what decentralization can actually do and begin translating it into high-level architecture. Discovery ends when the founder and I have a shared understanding of the technology we are building.
Produces — the architecture brief
Web3 Architecture
Protocol architecture comes first, before we ever touch the token. I map the users, roles, actions, permissions, value flows, system boundaries, and chain assumptions until the founder’s industry vision has a coherent Web3 form. The token needs a home; this phase designs that home.
Produces — the system map
Token Architecture
Once the protocol has a clear structure, I design the token’s place inside it. We establish utility, incentives, rewards, emissions, and the behaviors the protocol should value, then test the economic design through simulation. This is more than a list of utilities: the protocol architecture and token architecture become one system.
Produces — the incentive model + simulation output
Specify the system before production code begins.
The architecture is carried into a frozen specification, and the specification is carried into contracts — with no break between the protocol architecture, the token architecture, the spec, and the code that gets built.
Spec Build
The architecture now moves under a magnifying glass. I resolve the contract set, lifecycle states, flows, invariants, permissions, integrations, edge cases, and known risks into a build-ready specification. The specification is reviewed adversarially, corrected, and frozen as the source of truth before production code begins.
Produces — the frozen specification
Build Phase · Architecture-Led Engineering
The frozen specification becomes contracts, tests, deployment tooling, and integration surfaces. I rule every architecture decision; implementation is then challenged through independent model reviews, separate adjudication, and dedicated fix verification before the next build wave proceeds. The finding, decision, remediation, and verification trail is tied back to the work. Material architecture changes re-enter the same gated cycle: specification, independent review, adjudication, remediation, and verification.
AI writes code. It does not decide what the protocol should be.
Produces — contracts · tests · the review record
Authentic internal document title. This ledger records internal review and audit-handoff preparation; it is not evidence of an independent audit.
Protect the system, deploy it, and make it visible.
The built protocol is wrapped in control infrastructure, deployed as one testnet environment, and given a frontend that investors and reviewers can actually use.
Security Infrastructure
Once the core system is built, I design the control architecture around its sensitive operations. Depending on the protocol, that can include timelocks, executors, function-level allow-lists, circuit breakers, insolvency tripwires, emergency controls, and machine-enforced lockdown gates. Where a separate guardian framework is part of the stack, I design and build the protocol integration around it.
This work prepares the system for independent security review. It does not replace the security firm.
Produces — the control architecture
Testnet Deployment
Deployment is an engineering phase, not a final script run. I establish the chain configuration, keys and wallets, deployment order, mock assets, integrations, peer routes, verification checks, manifests, and operating runbook. The sequence is rehearsed against local forks before the testnet environment is deployed and tested end to end.
Produces — deployment manifests + the runbook
Custom Frontend & Observatory
The frontend is designed from the protocol architecture, so each user has the right path through the system. Contract interactions, wallet states, transactions, and cross-chain flows are connected and tested as one experience.
The Observatory gives investors and observers a view into the running testnet: activity, transaction movement, system state, and the parts of the protocol that would otherwise remain hidden inside the repositories. The result is a working demonstration surface for the system — not a static mockup.
Produces — the working demonstration surface
A working view into the testnet.
The Observatory turns protocol activity into something investors, partners, and test users can follow without reading the contracts. It can show testnet transactions as they happen, trace cross-chain movement, expose reserve and market state, and separate the paths used by different participants.
Where organic testnet activity is limited, automated test users can keep the environment active. Trading systems can use reference price feeds and testnet market-making behavior; community paths can include whitelists, mock assets, role-specific test paths, guided scenarios, and operational exercises.
The purpose is not activity theater. It is to make the system observable: what users do, how the contracts respond, and how the protocol behaves as one connected product.
Audit-ready, not audited.
The result is a working testnet system prepared for technical diligence and independent audit handoff: frozen spec, findings ledger, invariant results, deployment manifests, runbooks, known-risk register. It is not a substitute for the security firm, and it is not a mainnet launch.