Introducing Photon: The First Quantum-Safe Smart Contract Language

Why a New Language?

Writing a new smart contract language is not a decision made lightly. Solidity has a decade of tooling, audit frameworks, and developer muscle memory behind it. Move brought resource-oriented programming to the space. Rust-based contract frameworks offer memory safety without a garbage collector. Each of these languages was designed carefully for the constraints of its target virtual machine.

The problem is that none of them were designed for the QLVM. Qlorix's virtual machine has a fundamentally different set of requirements. It needs to verify post-quantum signatures as a single native opcode, not through a library call. It needs to read EffectManifest declarations at compile time so Block-STM can schedule transactions in parallel without conservative locking. It needs Groth16 ZK proof verification at the instruction level, not via an expensive precompile. Solidity was designed for ECDSA, EVM storage slots, and a sequential execution model. Grafting post-quantum support and effect declarations onto Solidity as an afterthought would produce something fragile. Photon is built from the ground up for the quantum-safe era.

The core insight: Quantum-safe blockchains need a language where post-quantum key operations, parallel execution hints, and ZK proof verification are first-class citizens, not library imports. Photon treats all three as primitive types and native opcodes.

Language Philosophy

Photon is built around three design commitments that inform every aspect of the language, from syntax to the bytecode the compiler emits.

Safe by default. Integer overflow causes a hard panic unless the developer explicitly annotates a block with unsafe_arithmetic. Reentrancy is structurally impossible because state writes are committed atomically at the end of a transaction, not inline during execution. Uninitialized memory cannot be read. The type system rejects implicit type coercions.

Familiar Solidity-like syntax. Developers who know Solidity will recognize the general shape of a Photon contract within minutes. Modules replace contracts, fn replaces function, and require works exactly as expected. The learning curve is deliberately shallow for the parts that carry over and steep only where the new concepts (effect declarations, resource linearity, quantum key types) require new thinking.

Explicit effect declarations. Every function that reads or writes on-chain state must declare precisely which storage keys it touches. These declarations are not documentation: they are verified by the compiler and embedded into the QLVM bytecode as the EffectManifest. Missing or incorrect declarations are compile errors, not runtime surprises. This constraint is the foundation of Photon's parallel execution story.

Syntax Overview

A Photon source file begins with a pragma photon version declaration, followed by optional imports from the standard library, and then one or more module blocks. Modules are the unit of deployment. The following example shows a minimal fungible token contract covering minting and transfer, including the EffectManifest declarations on each function.

// photon ^1.0
pragma photon ^1.0;
import std::auth::{ caller, is_role };
import std::crypto::{ dilithium3_verify };

module qlorix::token::QLX {

    // Linear resource type: cannot be copied or silently dropped
    resource Balance { amount: u64 }

    fn mint(owner: Address, amount: u64)
      writes [balance(owner)]
      requires is_role(caller(), "minter")
  {
      let bal = balance(owner).amount;
      balance(owner) = Balance { amount: bal + amount };
  }

    fn transfer(from: Address, to: Address, amount: u64)
      reads  [balance(from)]
      writes [balance(from), balance(to)]
  {
      require(balance(from).amount >= amount, "insufficient balance");
      balance(from).amount -= amount;
      balance(to).amount   += amount;
  }

}
    

The resource keyword marks Balance as a linear type. The compiler tracks every instance of a resource through all code paths and rejects any path where a resource value is created without being stored or explicitly destroyed. This eliminates an entire class of token bugs where assets are created in memory and never committed, or where a branch of logic silently discards a value.

EffectManifest Declarations

The reads and writes clauses on each function are the EffectManifest. They are not hints or annotations for documentation purposes. The Photon compiler performs a full data-flow analysis of each function body and verifies that every storage key accessed at runtime is covered by the declared manifest. An access that is not declared is a compile-time error.

At deployment, the EffectManifest is embedded into the QLVM bytecode header as a compact key-set descriptor. When the Block-STM scheduler receives a batch of transactions to execute in parallel, it reads the manifest of each transaction's entry function and computes the conflict graph before any execution begins. Two transactions that touch disjoint key sets run in parallel with no coordination overhead. Transactions with overlapping write sets are serialized only with each other, not with the whole block.

This means the manifest is load-bearing for performance. A function that unnecessarily declares a broad write set will be serialized more aggressively than needed. A function that omits a real write will be rejected by the compiler before it ever reaches the network. The effect is that Photon's type system and Block-STM's scheduler are tightly coupled: the language design directly determines the network's throughput ceiling for a given contract workload.

Quantum-Safe Key Operations

Photon's standard library ships with first-class support for the two NIST post-quantum standards most relevant to smart contract workloads: Dilithium3 for digital signatures and Kyber-768 for key encapsulation. These are not third-party packages. They are part of std::crypto and compile down to single QLVM opcodes, with the QLVM's native instruction set implementing them using constant-time arithmetic to prevent timing side-channels.

import std::crypto::{ dilithium3_verify, kyber_encapsulate, Dilithium3PublicKey, KyberCiphertext };

fn verify_governance_vote(
    msg:    Bytes,
    sig:    Dilithium3Signature,
    pubkey: Dilithium3PublicKey,
)
    reads [voter_registry(pubkey.address())]
{
      // Single QLVM opcode: no external library, no precompile round-trip
      require(
        dilithium3_verify(msg, sig, pubkey),
        "invalid post-quantum signature"
    );
      require(
        voter_registry(pubkey.address()).is_active,
        "voter not registered"
    );
      // ... tally the vote
}

fn establish_shared_secret(recipient_pk: KyberPublicKey) -> KyberCiphertext {
      // kyber_encapsulate returns (ciphertext, shared_secret)
      let (ct, _secret) = kyber_encapsulate(recipient_pk);
      return ct;
}
    

Dilithium3Signature and Dilithium3PublicKey are sized types: 2,420 and 1,952 bytes respectively. The QLVM memory model was designed with these sizes in mind. Stack frames are allocated to accommodate post-quantum key material without heap allocation, keeping gas costs predictable. Developers do not need to think about serialization formats or byte-array manipulation: the types handle that internally and present a clean API surface.

Compile Pipeline

Photon source code passes through four stages before it becomes deployable QLVM bytecode.

Lexer and parser. The Photon lexer produces a token stream that is fed into a recursive-descent parser. The parser produces a typed AST with source-location annotations on every node, which are preserved through to error messages.
Type checker and effect analyzer. Full Hindley-Milner type inference runs first, resolving all generic instantiations. Then the effect analyzer performs a data-flow pass over each function body, computing the concrete set of storage keys accessed and comparing it against the declared manifest. Any discrepancy is reported with a precise source location and a suggested fix.
Optimizer. The Photon optimizer runs dead code elimination, constant folding, and state access coalescing. Coalescing merges multiple reads of the same key into a single load, reducing the number of QLVM storage instructions and lowering gas costs without requiring developer intervention.
Bytecode emitter. The emitter produces QLVM bytecode with the EffectManifest embedded in the module header. The manifest is hashed using BLAKE3 and the hash is included in the deployment transaction, creating an on-chain commitment to the contract's declared effect set.

The toolchain also includes an EVM compatibility layer. Existing Solidity contracts can be compiled to a compatibility bytecode target that runs on QLVM through an EVM emulation layer, allowing protocols to migrate incrementally.

EVM Compatibility: Photon's compiler ships with a Solidity front-end that targets the QLVM EVM compatibility layer. Existing Solidity contracts deploy to Qlorix without modification. Gas semantics are preserved. This is not a fork or a wrapper: QLVM natively interprets EVM bytecode as a first-class execution mode, giving existing dApp teams a zero-friction migration path while they evaluate a full rewrite in Photon.

Developer Experience

The Photon toolchain is designed to be productive from day one for developers who already know Solidity, Move, or Rust. The photon CLI handles project initialization, compilation, testing, and deployment in a single binary with no external dependencies beyond the Rust runtime it is compiled against.

photon CLI. photon build compiles a project. photon test runs the built-in test framework against a local QLVM instance. photon deploy --network devnet deploys to the Qlorix devnet and prints the module address. Error messages include the affected source range, the inferred type, and a suggested correction where one is available.
VS Code extension. The Photon Language Server Protocol implementation provides inline error highlighting, manifest completeness warnings, type hover tooltips, and go-to-definition for module imports. The extension is available in the VS Code Marketplace as Photon Language Support.
Hardhat plugin. For teams with existing Hardhat-based test infrastructure, @qlorix/hardhat-photon integrates Photon compilation and QLVM deployment into the standard Hardhat workflow. Existing test scripts targeting EVM contracts run unchanged against the EVM compatibility layer.
Testnet faucet. The Qlorix devnet faucet at faucet.devnet.qlorix.com provides test QLX tokens via a simple POST request or the developer hub UI. The faucet requires no account creation and has a 24-hour rate limit of 100 QLX per address.
Readable error messages. The Photon compiler never emits a raw type variable in an error message. Every error is phrased in terms of the types the developer wrote, not the internal representation. EffectManifest errors name the specific storage key that was accessed without being declared and suggest the exact clause to add.

Roadmap

Photon is currently in active developer preview on the Qlorix devnet. The language specification is stable and breaking changes require a formal proposal process, but the standard library API surface may still evolve before mainnet.

Photon v1.0 ships with Qlorix mainnet. It includes the full language as described here, the complete std::crypto library with Dilithium3 and Kyber-768, the EVM compatibility layer, and the official VS Code extension and Hardhat plugin.

Photon v1.1 adds formal verification hooks. The v1.1 compiler will emit verification conditions for annotated functions in the SMT-LIB2 format, allowing developers to connect Z3 or CVC5 and prove invariants about their contracts as part of the standard build pipeline. Invariant annotations use a dedicated @invariant decorator on resource types and @ensures post-conditions on functions.

Photon v2.0 targets ZK circuit generation. The long-term vision for Photon is a compiler backend that can lower a subset of the language directly to arithmetic circuits compatible with Groth16 and PLONK proof systems. Developers would write a single Photon function and choose at deploy time whether to run it as a standard on-chain contract or as a ZK-provable off-chain computation with an on-chain verifier. This blurs the line between smart contract development and ZK application development, making privacy-preserving computation accessible to the full Photon developer base without requiring expertise in circuit design.

About Qlorix

Network Explorer

Network Status

Tokenomics

Whitepaper

Start Building

Documentation

API Reference

SDK Tools

Grant Program

Join Us

Governance

Liquid Staking NEW

Staking & Validators

Fundraising

Careers

Blog & Updates

Press Kit