Our contracts are free. The nine months are not.
Kerne built a complete synthetic dollar, runs it in production on Base, put it through a Tier-1 external audit and published the report. The contracts are MIT and the source is already public, so you can fork them this afternoon and pay us nothing. What you cannot fork is knowing which parameters are safe, the order things deploy in, the test suite that makes it changeable, and the reserve attestation rails. That work is what we sell, from $25,000.
This is the stack Kerne issues its own dollar with, and keeps issuing it with. Selling the work is productizing what we built, not stepping away from it.
Take the contracts. Seriously.
kUSD, skUSD, the Peg Stability Module and the vault are MIT licensed, and their source is published and verified against the deployed bytecode. That means you can read every line right now, copy it, change it, ship it commercially, and owe us nothing. We are not going to pretend otherwise in order to charge you for it.
The same goes for the attestation verifier. We open-sourced it under MIT as a standalone library, because an attestation that only its author can check is worth nothing, and a verifier you have to buy is not a verifier. Anything whose value depends on you being able to check it yourself, we give away.
We tell you this first because it is true, and because it is the argument. If the code were the hard part, a fork would be the whole answer and this page would not exist. The code is the artifact of the work. The work is what took nine months, and the work is what is for sale.
Precisely: 14 of 18 deployed Kerne contracts are source-verified on both BaseScan and Sourcify, and we list the rest with reasons rather than round up. Two details you would otherwise find yourself: the live Peg Stability Module is an exact match on Sourcify but its BaseScan verification is still pending after the 2026-07-10 redeploy, and skUSD, while verified on both, is a Sourcify partial match rather than an exact one. The per-address status is in the verification registry. Counts measured July 31, 2026.
What a fork does not give you
None of the following is in the public source, and all of it is the reason a working deployment takes most of a year to reach from a cold start.
782 forge tests across 67 files cover the five contracts in the audit scope, inside a suite of 2,638 that passed with zero failures on its last full run. Fuzz and invariant runs over the peg, the accounting and the role surface. None of it is published, and it is the difference between code you have and code you can safely change: without it, your first parameter edit is a guess.
Which fee, which cap, which breaker threshold, which oracle staleness bound, and the reasoning for each. A fork gives you our numbers with none of the argument behind them, which is the part that stops you learning the same lessons at your holders' expense.
The forge scripts that put the system on chain in the right sequence, the role-grant order, and the runbooks for the mint path, the redeem path and the unwind. Deploying these contracts in the wrong order is a live-funds problem, not a redeploy.
The verifier is open source and free on purpose, because an attestation nobody can check independently is worth nothing. What is not public is the producing side: the hourly signing pipeline, the key handling, the canonical number-binding and the freshness guarantees we run in production. We can operate that for your token rather than have you build it.
The issuance interface (mint, redeem, stake, the transparency surfaces) and Opal, the points and rewards engine. Both are ours and neither is public. Available at the top tier for teams that would rather re-skin than rebuild.
The stack is live on Base and has been since 2026-05-14. When your deployment does something strange at 2am, the useful thing is not the repository. It is a person who has already seen it do that.
Three ways to buy the work
Fixed fees, quoted up front, agreed in writing before anything starts. Each tier says where it ends, because an unbounded yes is the failure mode we actually price against, and we would rather tell you that than discover it together.
We deploy the stack on your chain and hand it over working. You get the private forge suite, the deployment scripts, the runbooks and the technical documentation, plus a walkthrough with your engineers so the system leaves with people who understand it.
Where it ends: One chain, one deployment, our default parameters. Includes 30 days of written asynchronous questions. No bespoke parameter design, no on-call.
Everything in tier one, plus the part that is actually hard. We set the peg, fee, cap and breaker parameters against your risk appetite and write down why each one is what it is, wire your reserve reads, and stand up the signed proof-of-reserves attestation for your token so your transparency surface is live on day one.
Where it ends: One chain, one configuration pass. Includes 90 days of written support. A second chain is a second engagement.
Everything in tier two, plus the frontend and the points engine, and Kerne operating the attestation rails for your token for the first year so the verifiable layer is a service you buy rather than a team you hire.
Where it ends: Scope fixed in writing before work starts. The operations year is quoted separately and renews by agreement, never by default.
What we are not selling
These are the objections your counsel would raise in diligence. We would rather you read them here first.
Hexens reviewed kUSD, skUSD, KUSDPSM, KerneVault, and esKERNE, the five contracts named in the report's own scope section, each pinned to one commit, at commit 0912c870, and the report published on July 31, 2026. It counts 10 findings: 0 critical, 2 high, 2 medium, 4 low and 2 informational, of which 8 are fixed and 2 are acknowledged without a code change. All 10 are in the vault. We will not tell you the code is safe, because a review of five contracts at one commit is a fact about those five contracts at that commit and nothing more. Read it yourself: the full report, and our response to every finding.
The Hexens report covers Kerne's code at a stated commit. Change a parameter, a dependency or a line and you are holding a different artifact that needs its own review. We put that in writing rather than let you infer that our report insures your deployment, because it does not. The same rule binds us: an audit reviews a commit, not a chain, and where our own deployed bytecode differs from the reviewed source we publish the map at /security/deployed-vs-source.
We are selling work. Nothing here transfers risk from your deployment to us, and a license is not an indemnity. Budget for your own review of whatever you ship. A buyer who skips that is the scenario we price against, not for.
If you diligence us properly you will curl both, so here it is first. /api/stats publishes hedgeActive: true while /api/por/signed publishes delta_neutral: false. Both are correct and they answer different questions. The first means the signed attestation measured an open hedge book this cycle, and it did. The second means that book neutralises the collateral backing kUSD, and it does not: the attested vault holds no user deposits, so the hedge base is zero and an open short over an empty base is scored as fully directional. The attestation reports that as a warning against itself rather than rounding it away, and the arithmetic is published in the same payload under hedge_base_basis. We would rather you read that here than conclude we cannot keep our own numbers straight.
Kerne closed public deposits into its vault ahead of the audit and has not reopened them: the remediated build has to be deployed and verified first. That is a live constraint on us, not on what we sell you, and a stack engagement does not wait on it. We state it because you would find it, and because a vendor who hides the state of their own deployment is telling you what their reporting is worth.
Kerne has been live since 2026-05-14 and its own TVL is small. We lead with that rather than hide it, because what is for sale is the machinery and the method, not the size. The unfiltered position is in the data room and on the security pages.
Who this is for
A native dollar is on most chain roadmaps and is usually the thing that slips. This turns an open-ended internal project into a deployment with a date on it.
Teams that already hold the balances and the customers and want to issue rather than integrate, without standing up a Solidity team to reach a first deployment.
Teams with the asset and the distribution but not the issuance machinery: a mint path, a redeem path, and a reserve story a counterparty can check without asking permission.
Studios delivering a dollar for a client who would rather start from a system that runs in production than from a blank repository. You keep the client and the integration work.
Scope an engagement
Tell us what you want to issue and where. You get back a written scope, a fixed fee, and an honest read on whether this beats building it yourself, including the times it does not.
Stack deployment enquiry
No figures needed. Name the chain and the token you have in mind and we will scope it.
Would rather diligence the code first? Read the data room, or read the Hexens report and our response at /security/audits.
Kerne is infrastructure, not a custodian, an auditor or an investment adviser. A stack engagement is engineering work: it conveys deployment, configuration and documentation, never assurance, and never an indemnity for your deployment. The Hexens report covers Kerne's own code at commit 0912c870 and does not extend to a third-party deployment. The core contracts are MIT licensed and their source is public; the fee buys the work, not permission to use the code. Fees are fixed per engagement and confirmed in writing before work begins. Nothing on this page is legal, tax or accounting advice.