One 73-file starter connects a contract, deployment, and frontend
GenLayer Project Boilerplate gives newcomers a concrete application rather than a folder full of placeholders. Its football betting contract accepts a match date, two teams, and a predicted winner. When asked to resolve a bet, the contract renders a BBC Sport results page, asks a language model to extract the score and winner as JSON, and runs that nondeterministic result through GenLayer's equivalence mechanism. Correct predictions add a point to the user's address.
Around that example sits most of a working application: Python contract code, direct and integration tests, a GenVM linter, TypeScript deployment scripts, and a React frontend with wallet support. This breadth is the project's main advantage. A developer can see how contract storage, web access, model output, deployment, client calls, and user-facing state fit together. That is much more instructive than a minimal hello-world contract.
Direct tests mock web and model output before Studio
Smart contracts that depend on web pages and model responses are awkward to test. Real calls are slow, variable, and tied to outside services. This starter separates fast direct tests from consensus-backed integration tests. Direct mode deploys the Python contract in memory and provides fixtures for senders, web responses, language-model responses, expected failures, and mock resets. The README positions them as the fast inner loop, with Studio reserved for checks that require deployment and consensus.
That loop is valuable even for developers who never use the included frontend. Contract authors can lint every change, run deterministic tests against mocked inputs, and reserve Studio for the smaller set of checks that actually need deployment and consensus. The repository includes a CI workflow for linting and direct tests, which gives pull requests useful feedback without standing up the full network environment.
The linter is not cosmetic. It checks forbidden imports, storage types, missing decorators and return annotations, and nondeterministic operations placed outside the approved equivalence blocks. Those are platform rules that ordinary Python tooling cannot infer. Keeping them close to the sample lowers the chance that a newcomer writes valid Python that GenVM cannot safely execute.
What happened when we ran it
Our sandbox installed 2,324 npm packages in 50 seconds and occupied 1,275 MB on disk. The build succeeded in 22 seconds. The source checkout at commit e685f1f was only 73 files, about 4,893 source lines, and 0.6 MB, so most of the measured disk cost came after dependency installation.
The root package had no tests script or target, so our harness skipped tests. That does not mean the repository has no test code: the checkout has a tests directory, and the README documents Python direct tests plus Studio-backed integration tests. It means the npm workflow we measured did not expose one command for the harness to run.
Npm audit found 47 known vulnerabilities in the installed dependency tree: 1 critical, 16 high, 28 moderate, and 2 low. Our run used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. We did not deploy to Studio, call an LLM or BBC Sport, connect a wallet, or assess contract consensus.
Python 3.12, the GenLayer CLI, and Studio complete the setup
The README requires Python 3.12 or newer, a virtual environment, and a globally installed GenLayer CLI. Linting and direct tests can run without Studio by mocking web and model calls. Deployment and integration tests need a local or hosted Studio instance, a chosen network, and the platform test runner.
After deployment, the frontend needs an environment file with the contract address. Its stack includes Next.js, React, TanStack Query, Wagmi, Viem, and Radix components. Wallet and network configuration create another boundary to debug. The README calls the frontend Next.js 15, while frontend/package.json identifies Next.js 16, so source and lockfiles should win when versions matter.
The football example exposes web and model failure modes
The contract's central behavior is intentionally nondeterministic. It relies on the structure and availability of a BBC page, then on a model returning parseable JSON with the expected meaning. Consensus is the platform's answer to variation, but application developers still own prompt design, source selection, failure handling, and economic consequences. Mocked tests cannot show how a changed page or ambiguous match name behaves across validators.
The sample also contains choices that should not survive into a real betting product. The check meant to reject already-finished matches is commented out to support historical testing. Team names and dates become part of identifiers and URLs, and the domain would require deeper validation, dispute handling, access rules, and legal review. The README calls the frontend production-ready, but that description should be read as a statement about its application stack, not the readiness of the complete betting system.
Active development matters more than the old tag
The latest GitHub release is v0.2.0 from December 9, 2025, but repository activity continued well afterward. The project was pushed on July 26, 2026, when maintainers merged fixes aligning contracts with GenVM 0.6 and rejecting undetermined deployments. Issues concerning private test internals, branching helpers, reward tests, and specification alignment were also closed in July. New issues and pull requests were still being updated in August.
GitHub reported 25 open issues and PRs, so that number is not a count of confirmed bugs. The queue includes feature proposals, outside submissions, documentation work, and low-information user posts. With 16,746 stars and hundreds of forks, awareness is high, but the repository's changing platform dependencies still argue for pinning a known-good revision.
For GenLayer learners, this is the clearest kind of starter: opinionated, runnable, and tested at two levels. Its direct-test approach is worth keeping even after every line of sample business logic has been replaced. Adopt it to learn and prototype, then tighten dependencies, update the frontend assumptions, expand failure cases, and perform real consensus testing before placing value behind the contract.