The short answer
When a protocol roadmap item is funded but your team lacks the specialists, or a mechanism needs researching before anyone commits to it, Cryptuon delivers it as milestone-based sponsored engineering. Each milestone has a written acceptance test. The output is a reproducible implementation and an evaluation report that includes negative results. Where the sponsor agrees, the code is released as open source.
Grant-funded and RFP work is welcome. Ecosystem programmes such as the Solana Foundation’s describe milestone-based grants, convertible grants, and RFPs, and our proposals use the same milestone structure.
Decision criteria
The questions that decide cost and approach:
Is the deliverable a working system, an answer, or both?
“Build the reference implementation of this specification” is engineering with known acceptance tests. “Find out whether this distribution mechanism resists Sybil splitting” is research with an uncertain answer. Most sponsored work is both. Separating them into different milestones lets the sponsor pay for the answer before committing to the build.
What does “done” mean for each milestone?
A milestone without a test turns into an argument at invoice time. Every milestone in our proposals names a tagged commit, a command that reproduces it, and the results that count as acceptance. For research milestones, “done” means the experiment ran as specified and its data is published to the sponsor. It does not mean the result came out a particular way.
Who must be able to reproduce the result?
Reproducibility for the sponsor’s reviewer is the default. Results that will be cited publicly, or used by other teams, need a stricter bar: pinned toolchains, recorded seeds, and test suites that run on an ordinary machine without our infrastructure.
What happens to the code afterwards?
Open-source release, sponsor ownership, or delayed publication each change the documentation, licensing review, and handover effort. If someone has to maintain the code after the last milestone, that should be budgeted now.
Does the work touch tokens or distribution?
Mechanism research is legitimate engineering. Token sales and promotion are not part of it. Where the work involves a token or distribution, the plan separates the mechanism (which we implement and evaluate) from the token structure (which needs legal review that we do not provide).
Implementation options
| Approach | How it works | Strength | Tradeoff | Maturity |
|---|---|---|---|---|
| Cryptuon sponsored engineering | Milestone-based delivery of a funded specification or experiment, with acceptance tests per milestone | Research-to-code track record in public repositories; one accountable contractor for implementation and evaluation | Small team: very large programmes need a larger firm or a consortium; audits are separate | Tesseract test suite reproduced; EVMORE declared; commit-reveal reproduced on PyPI; no third-party audit published |
| University research group | Faculty and students study the problem, usually with publication as the main output | Depth on open questions; academic credibility | Academic timelines; production-quality code is rarely the goal | Established |
| Specialist protocol-engineering or security firm | A larger consultancy staffs the roadmap item | Capacity, brand recognition, sometimes audit under one roof | Higher cost; senior specialists are often shared across many clients | Established |
| In-house hiring | Recruit the specialists and build internally | The knowledge stays in the team | Slow and uncertain recruiting for scarce skills; fixed cost after the project | Standard |
| Grant-funded independent contributors | Several independents deliver separable tasks against a grant | Flexible and often cost-effective for well-specified tasks | The sponsor carries integration, review, and coordination | Common in ecosystem programmes |
The delivery sequence
- Scope. Turn the funded roadmap item, RFP, or research question into a specification, and list open questions and assumptions.
- Milestone plan. Give each milestone a deliverable, a reproduction command, acceptance results, and a price.
- Prior-art check. Check whether existing open-source work already solves part of the problem, and reuse it where licensing allows.
- Build and evaluate. Implement and test, run experiments from recorded parameters, and keep a decision log of departures from the spec.
- Milestone review. The sponsor’s reviewer reproduces the milestone from a tagged commit before it is accepted.
- Release and hand over. Publish open source where agreed, deliver the final evaluation report, and hand over or move to maintenance.
A milestone definition of the kind that goes into a proposal. The format is illustrative; acceptance is what the commands produce:
milestone: M2
title: "Reference relayer with failure-path tests"
tag: v0.2.0-m2
reproduce:
toolchain: { python: "3.12", vyper: "0.4.0", rust: "1.79" }
command: make test
acceptance:
- "All tests listed in docs/m2-acceptance.md pass on a clean Ubuntu 24.04 machine"
- "Refund path exercised for every leg when any leg misses its deadline"
- "Evaluation notebook regenerates every figure in report-m2.pdf from data/m2/*.json"
payment_on: acceptanceThe reproduction check a sponsor’s reviewer runs. It starts from a clean clone and does not depend on our machines:
#!/usr/bin/env bash
# Reproduce a milestone from its tag on a clean machine and keep the log as evidence.
set -euo pipefail
REPO="${1:?repository URL}"
TAG="${2:?milestone tag}"
WORKDIR="$(mktemp -d)"
git clone --depth 1 --branch "$TAG" "$REPO" "$WORKDIR/src"
cd "$WORKDIR/src"
make test 2>&1 | tee "$WORKDIR/test-$TAG.log"
git rev-parse HEAD > "$WORKDIR/commit-$TAG.txt"
echo "Evidence written to $WORKDIR"For distribution-mechanism research, evaluation metrics are code, not prose. One example is reward concentration across simulated participants:
def gini(rewards: list[float]) -> float:
"""Gini coefficient of a reward distribution: 0 = perfectly equal, near 1 = concentrated."""
values = sorted(rewards)
n, total = len(values), sum(values)
if n == 0 or total == 0:
raise ValueError("need at least one non-zero reward")
weighted = sum((i + 1) * v for i, v in enumerate(values))
return (2 * weighted) / (n * total) - (n + 1) / nEvidence
- Tesseract implements the Universal Atomic Composability research: seven Vyper contracts and a Rust relayer. The quickstart reproduces the 135-test suite with
make test. It also publishes the expected result on main: 86 passed, 40 expected failures, and 9 unexpectedly passing. Not every scenario passes yet, and the quickstart says so. Documentation: docs.cryptuon.com/tesseract. - EVMORE is a reference implementation of a fair-launch proof-of-work distribution. How it works documents the KeccakCollision puzzle, verified on-chain by a 62-line Vyper contract. Its FAQ states that it is an experiment, not an investment product. Documentation: docs.cryptuon.com/evmore.
- commit-reveal packages a primitive from protocol research. Its security page lists mypy strict typing, Hypothesis property tests, and a Bandit scan, along with what is out of scope. Documentation: docs.cryptuon.com/commit-reveal.
- Our research page lists five papers: Towards Universal Atomic Composability, Generalised DePIN Protocol, FairFlow Protocol, Decentralized Deepfake Detection Network, and Centralized Intermediation in a Decentralized Web3 Economy.
- How distribution and incentive designs differ across the portfolio, and where we chose not to use a token: tokenomics across Cryptuon. The cross-chain research background is in the cross-chain atomicity problem.
- Evidence levels and limitations for each project are in the maturity register.
- Not yet evidenced: no third-party audit has been published for Tesseract, EVMORE, or commit-reveal. Tesseract is not on mainnet. No sponsored delivery is yet listed as customer-accepted in the register.
What drives the cost
- Novelty. Implementing a settled specification costs less than resolving open research questions along the way.
- Environments. Each additional chain, client, or testnet multiplies deployment, test, and failure-path work.
- Evaluation depth. Simulations, parameter sweeps, and adversarial scenarios take time to design and to make reproducible.
- Reproducibility bar. Reviewer-only reproduction is cheaper than a public, citable release with pinned environments.
- Release and handover. Documentation, licence review, and maintainer onboarding for an open-source release.
- Audit readiness. Preparing specifications, invariants, and threat notes for a third-party auditor, when value will eventually depend on the code.
Limitations and what we won’t do
- Our team is small. Programmes needing many parallel workstreams are better served by a larger firm, or by us working alongside one.
- An engineering review is not an independent audit. Code that will hold value needs a third-party audit, which we can scope and bring in at separate cost.
- We do not design tokens for fundraising, sell or promote tokens, or project returns. EVMORE is a research artefact, and we treat it as one.
- We do not guarantee grant awards, RFP wins, or paper acceptance.
- If a university group, another firm, or existing open-source work fits the problem better, the assessment says so.
See also how we structure engagements, and related work on cross-chain integration and forecasting and agent competitions.
Next step
Send us the specification, RFP, or roadmap item, your funding structure (grant, RFP, or direct sponsor), and any deadlines through /start. The assessment returns a milestone plan with an acceptance test and a price for each milestone, a prior-art check, and the risks most likely to move the schedule.