Covenant

01The problem

Solidity has been an extraordinary success. More than twelve million contracts deployed, hundreds of billions of dollars secured, one of the most mature ecosystems of tooling and auditors in all of open-source computing. But Solidity was designed for a specific world, at a specific moment.

That world rested on three foundational assumptions: on-chain data transparency is the norm and privacy is opt-in; classical cryptography (ECDSA, keccak, Merkle) will remain sufficient for decades to come; what is written on-chain stays there forever, with no cryptographic alternative.

Each of these assumptions is becoming false.

Privacy is becoming a regulatory requirement, not an opt-in. European right-to-be-forgotten regulations, emerging laws on the confidentiality of financial positions, and the protections coalescing around behavioral data make the integral transparency of public blockchains legally problematic for a growing number of use cases. The post-quantum standards were finalized by NIST in August 2024 — ML-KEM, ML-DSA, SLH-DSA. Cryptographically-relevant quantum computers sit on a ten-to-fifteen-year horizon, and the "harvest now, decrypt later" pattern means that data published today is already being archived by adversaries who will decrypt it tomorrow. Finally, the absolute permanence of on-chain state is becoming a legal liability — not because auditability has lost its value, but because cryptographic techniques now exist that separate auditability (which must persist) from individual opinion (which must be able to disappear).

Beyond these three shifts, a fourth phenomenon imposes itself. Modern smart contracts are built from heterogeneous cryptographic primitives assembled by hand by the developer: an FHE library here, a ZK verifier there, a post-quantum signature scheme elsewhere, a custom key-destruction pattern. Each assembly is an opportunity for an integration bug, and integration bugs are particularly expensive when they touch cryptographic guarantees: they do not crash, they do not raise exceptions — they silently produce incorrect results on data no one can inspect.

The contracts that will be deployed in the next decade need properties that current languages do not express naturally: blind computation on encrypted data, trustless verification of that computation, post-quantum signatures, provable key destruction, and formally verifiable compositions of these guarantees. These properties should exist as primitives of the language, not as libraries to be assembled.

02The observation

The cryptographic primitives required to address this shift already exist, either as Ethereum standards or as mature infrastructure.

The four ERCs of the Styx Protocol (ERC-8227 Encrypted Token, ERC-8228 Cryptographic Amnesia, ERC-8229 FHE Verification, ERC-8231 Post-Quantum Key Registry) define the contracts of these primitives at the Ethereum standard level. They exist, they are officially registered on the Ethereum repository with assigned numbers, they are public under CC0 license. What is missing is not another abstraction layer — it is a language in which these primitives are native, where the compiler prevents integration errors, and where auditors read a specification instead of an implementation.

Covenant is that language.

03The thesis

Three assertions define what Covenant seeks to accomplish.

04The solution

Covenant is a smart contract language designed for cryptographic agility, with the Styx Protocol as its native standard library.

The language is general-purpose in the sense that it expresses everything a modern EVM smart contract can express: arbitrary business logic, interaction with existing contracts, complex data types, inheritance, interfaces. But it is specialized in the sense that its privileged primitives — those the language exposes with the greatest ergonomics and the strongest compile-time guarantees — are the four Styx primitives: blind computation (ERC-8227), trustless verification (ERC-8229), amnesia (ERC-8228), and post-quantum signatures (ERC-8231).

This specialization is a deliberate choice. A language can be balanced like Solidity — maximum expressivity, no privileged treatment of any family of use cases — and become the default standard through its generality. Or it can be specialized like Cairo for ZK, Move for linear resources, Clarity for decidability — and conquer a specific territory by expressing it better than anyone else. Covenant takes the second strategy, with modern cryptography as its territory.

Here is the canonical use case — a private governance where individual votes are encrypted, the result is public, and individual positions are destroyed after the cycle.

contract PrivateDAO {
    using PQKeys           // ERC-8231
    using EncryptedTokens  // ERC-8227
    using FHEVerification  // ERC-8229
    using Amnesia          // ERC-8228

    encrypted uint256 yesVotes;
    encrypted uint256 noVotes;
    mapping(address => bool) hasVoted;

    function vote(encrypted bool choice)
        requires pq_signed_by(msg.sender)
    {
        require(!hasVoted[msg.sender]);
        hasVoted[msg.sender] = true;

        encrypted if (choice) {
            yesVotes += 1;
        } else {
            noVotes += 1;
        }
    }

    function finalize()
        verified_by_ivc_proof
        returns (uint256 yes, uint256 no)
    {
        return (decrypt(yesVotes), decrypt(noVotes));
    }

    amnesia_ceremony {
        trigger: after(finalize)
        custodians: 5
        threshold: 3
        vdf_delay: 72h
        preserve: [yesVotes_decrypted, noVotes_decrypted]
        destroy: [hasVoted, individual_choices]
    }
}

This contract is about fifty lines long. Its equivalent in Solidity with the same guarantees — manually assembling fhEVM, a ZK verifier, a PQ registry, and a custom Shamir ceremony — runs several hundred lines across multiple contracts, with dozens of points where integration can break silently.

Covenant is also capable of expressing classical contracts without advanced cryptographic primitives — a standard ERC-20, a staking pool, a simple AMM. In these cases, ergonomics are comparable to Solidity, with no overhead. The distinctive value of Covenant reveals itself when contracts compose heterogeneous cryptographic primitives: it is at that moment that the compiler delivers value no other tool delivers today.

Covenant is chain-agnostic. It compiles to a combination of artifacts depending on the target: standard Solidity contracts implementing the four Styx ERCs for EVM chains (Base Sepolia as first target, followed by Ethereum mainnet, Arbitrum, Optimism), a native deployment on Aster Chain where Covenant's guarantees compose with Aster's server-side encryption in defense-in-depth, and an abstraction layer over existing FHE co-processors.

05Why now

Four windows have opened simultaneously, and it is their conjunction that makes Covenant relevant in 2026 — not in 2023, and not in 2029.

Post-quantum standards were finalized by NIST in August 2024 — ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures. This is no longer research; it is a stable reference on which to build infrastructure meant to last decades.

Fully homomorphic encryption (FHE) became production-viable during 2025. Zama fhEVM runs on Ethereum, Fhenix launched its L2, benchmarks converge around one hundred milliseconds per TFHE gate. FHE architectures are no longer theoretical — they are deployed and used.

ZK co-processors are operational. Succinct SP1, RiscZero, Nova folding, and Halo2 SNARK form a mature ecosystem in which arbitrary off-chain computation can be proven on-chain in a few hundred bytes. Trustless verification of FHE computation (what ERC-8229 defines) becomes technically implementable without exotic prerequisites.

Finally, the four ERCs of the Styx Protocol have been officially registered in the Ethereum repository and are the subject of active discussions on Ethereum Magicians. They constitute the stable contractual surface on which Covenant can compile.

When these four conditions are simultaneously in place — finalized cryptographic standards, FHE in production, mature ZK co-processors, registered ERCs — a window opens in which a project like Covenant can be built. That window is today.

06Open model

Covenant is a fully open project. No VCs, no token, no proprietary component under NDA. The language specification is published under CC0-1.0, full public domain. The reference compiler, the execution VM, the tooling, and the standard library are published under Apache 2.0. External contributions are welcomed under a public governance process starting from V0.

This decision is strategic. Adoption of a smart contract language is a network effect: adoption speed depends on the project's permeability to developers, contributors, auditors, and chains seeking integration. A proprietary component, however technically justified, slows adoption by several years — as shown by the contrasting trajectories of Rust (fully open, rapid adoption) and historical Java (proprietary components, hindered adoption).

Kairos Lab stewards Covenant as the organization responsible for its initial stewardship. Stewardship may transition to an independent foundation at a later stage if the project requires it, following the model of the Rust Foundation or the Ethereum Foundation.

07Roadmap

Building a smart contract language is a long and demanding project, one that does not lend itself to hasty promises. Comparable projects (Move, Cairo, Sway, Fe) stabilized over three-to-five-year horizons with dedicated teams. Covenant will not be an exception.

The roadmap has begun. The design phase is complete. V0.1 Basics shipped in April 2026 with the first public deployment on Ethereum Sepolia. The remaining phases extend over the next 24–36 months, contingent on team formation and funding. The dates are not commitments; they are reference milestones that will shift based on team size, funding, and adoption signals.

This roadmap is ambitious and requires resources Kairos Lab does not possess alone today. V0.1 demonstrates that execution is real. It becomes fully achievable to the extent that the team forms and funding follows. That is precisely why this document is published — to make the effort visible and invite the right people to contribute.

08Team and recruitment

Covenant requires a technical team to be built, and Kairos Lab is actively recruiting. With the compiler at tag v0.1.0-basics and the first contract live on Ethereum Sepolia, contributors now join a project with a working artifact, not only a specification.

Four profiles are particularly sought over the next twelve months.

These four profiles do not all need to be full-time immediately. Initial engagement can take the form of punctual consulting, academic collaboration, or grant-compensated open-source contributions. The team will grow progressively as funding structures itself.

Interested individuals — contributors, advisors, or institutional partners — can contact Kairos Lab through the channels listed at the end of this document.

09Funding

Covenant is a public infrastructure project. Its economic viability does not depend on generating classical commercial revenue — there will be no token, no SaaS, no paid license on the language. The funding required to build it will be mobilized through three channels.

Public foundation grants

The Ethereum Foundation, the Protocol Guild, the Aster Foundation, and other organizations supporting Web3 public goods are natural targets. With the four Styx ERCs registered as Ethereum standards, Covenant qualifies naturally as infrastructure contributing to the ecosystem. Grant applications will be formalized progressively as intermediate deliverables become available.

Chain-level partnerships

Chains that have an interest in Covenant supporting their environment can co-fund its development — Aster Chain being an obvious candidate given the synergy with its native encryption, but other privacy-oriented chains may join the effort.

Kairos Lab bootstrap

While external funding does not cover the full scope of needs, Kairos Lab allocates its own resources (audits, consulting, bug bounties) to the project. This bootstrap phase is intrinsically rate-limiting on development speed, but it preserves the project's independence until it has demonstrated value to external funders.

No VCs, no traditional private fundraise, no token pre-sale. This red line is drawn to preserve the public-goods nature of the project and avoid the classical conflicts of interest that have compromised other smart contract languages in the past.

10Invitation

Covenant is neither a product nor a startup. It is a software infrastructure project whose value to the Web3 ecosystem depends entirely on who builds it and who deploys it in production. With V0.1 Basics shipped, contributors now have a working compiler to inspect, critique, extend, and port, rather than a specification alone.

The profiles who can contribute fall into several groups. Cryptographers, who can audit the semantics of the language to verify that FHE, PQ, and ZK primitives are exposed without introducing side channels. Compiler implementers, who can port Covenant to new backends or new compilation targets. Smart contract auditors, who can stress-test the correspondence between Covenant source and generated artifacts. Chains and L2s, who can integrate Covenant as a first-class language and raise infrastructure needs we did not anticipate. Foundations and grant programs, who can fund development at a more sustainable pace than bootstrap. And early adopters — advanced DeFi protocols, high-sensitivity DAOs, institutional custody projects — who can adopt the first versions and surface the gaps.