12. Quorlin — Smart Contract Language

Quorlin is Kortana's native smart contract programming language, engineered specifically to target the 32-register Kortana Virtual Machine (KVM). Syntactically familiar to developers with Java experience, Quorlin acts as a mathematically strict constraint system that enforces capability-based security, checked arithmetic, and bounded execution directly at compile time, compiling directly to high-performance KVM bytecode.

[!TIP] Official Language Documentation: For the complete language guides, tutorials, syntax reference,interactive examples and standard library interfaces,visit the official documentation at quorlin.dev.

Source files use the .ql extension. Quorlin contracts compile directly into .kvm binary modules and Solidity-compatible .abi.json specifications, enabling seamless bidirectional interoperability with Ethereum tooling and smart contracts.

12.1 Language Philosophy & Capability Security

Quorlin is designed around the foundational principle of Mandatory Capability Declarations. In traditional smart contract languages, any function can potentially mutate storage slots, emit event logs, transfer ether, or perform arbitrary external calls unless manually annotated or audited. In Quorlin, there is no generic function keyword. Every function must explicitly declare its state effect (reads or writes) as its very first token.

The compiler strictly verifies these capabilities during semantic analysis (sema.cpp):

• A function declared with reads is statically proven to contain zero storage write operations (SStore, TStore), zero balance transfers, zero contract creations, zero event emissions, and zero non-static external calls. Any attempt to modify state within a reads function results in an immediate compile-time rejection.
• A function declared with writes announces to callers, static analysis tools, and wallets that it modifies persistent contract storage.

This compile-time capability model completely eliminates entire classes of vulnerabilities—including reentrancy attacks, unmetered state modifications, and hidden storage corruption—at the language design level.

12.2 Quick Start Tutorial

The following complete Quorlin contract demonstrates state mapping, constructor initialization, explicit effect declarations, assertions, and event emissions:

contract Token {
    map<address, number> balances;
    map<address, map<address, number>> allowances;
    number supply;

    event Transfer(address indexed from, address indexed to, number value);
    event Approval(address indexed owner, address indexed spender, number value);

    constructor(number initialSupply) {
        supply = initialSupply;
        balances[caller] = initialSupply;
        emit Transfer(nobody, caller, initialSupply);
    }

    reads number totalSupply() {
        return supply;
    }

    reads number balanceOf(address owner) {
        return balances[owner];
    }

    reads number allowance(address owner, address spender) {
        return allowances[owner][spender];
    }

    writes truth approve(address spender, number amount) {
        require spender != nobody, "approve to the zero address";
        allowances[caller][spender] = amount;
        emit Approval(caller, spender, amount);
        return yes;
    }

    writes truth transfer(address recipient, number amount) {
        require recipient != nobody, "transfer to the zero address";
        
        number held = balances[caller];
        require held >= amount, "transfer amount exceeds balance";

        balances[caller] = held - amount;
        balances[recipient] = balances[recipient] + amount;

        emit Transfer(caller, recipient, amount);
        return yes;
    }
}

The contract reads naturally in English, avoids verbose boilerplate, and compiles down to optimized KVM register instructions.

12.3 Types & Arithmetic Safety

Quorlin enforces a strong, static type system with zero implicit type coercions:

• number: Native 256-bit unsigned integer (equivalent to uint256). All arithmetic operations (+, -, *, /, %) are strictly checked for overflow and underflow by default. An overflow or divide-by-zero immediately halts execution and reverts the transaction, eliminating integer wraparound vulnerabilities without requiring third-party math libraries.
• truth: Boolean type with explicit literal values yes and no. Implicit boolean conversions (such as if (balance)) are forbidden and trigger compile-time errors.
• text: Bounded dynamic string type capped at 128 UTF-8 bytes to prevent heap memory exhaustion attacks.
• address: 20-byte account and contract address identifier (compatible with Ethereum 0x and native ktn: addresses).
• record: Single-level structured records for grouping related fields without heap indirection.
• map<K, V>: High-performance key-value mapping storing state persistently in the State Trie.

12.4 Storage Layout & Ethereum Indexer Compatibility

Storage in Quorlin follows standard Ethereum storage slot formulas, ensuring that subgraphs, indexers (The Graph, Dune Analytics), and block explorers can inspect Quorlin storage slots identically to Solidity contracts:

• Mappings: Key-value mappings calculate storage slots using the standard formula:

  Slot = Keccak-256(Key || SlotIndex)
  

• Nested Mappings: Nested mappings evaluate recursively:

  Slot = Keccak-256(Key2 || Keccak-256(Key1 || SlotIndex))
  

• Records (Structs): Fields within a record occupy sequential storage slots starting from the record's base slot:

  Slot = Keccak-256(Key || SlotIndex) + FieldIndex
  

This exact alignment ensures that indexers written for ERC-20, ERC-721, and ERC-1155 contracts parse Quorlin tokens without requiring bespoke decoders.

12.5 Functions, Mutability & Effects

Every Quorlin function explicitly specifies its mutability behavior:

• reads Functions (View): Used for querying contract state. At the bytecode level, external calls to reads functions are dispatched using the StaticCall opcode (0xC1), which enforces read-only execution at the virtual machine level. Even if a reads function invokes an external untrusted contract, that callee is physically prohibited from mutating state.
• writes Functions (Mutating): Used for executing state transitions. External calls from writes functions dispatch via ExternalCall (0xC0), which permits state mutations while transferring gas and calldata atomically.

Functions specify their return types immediately following the capability keyword (e.g. reads number balanceOf(...) or writes truth transfer(...)).

12.6 Control Flow & Provable Complexity

Quorlin supports structured control flow constructs: if, else, and return.

To protect validating nodes against denial-of-service (DDoS) attacks and infinite execution loops, Quorlin deliberately omits dynamic, unbounded looping constructs (while, for (i=0; i<arr.length; i++)). Iteration over fixed, compile-time constants is supported. This deliberate design constraint guarantees that every execution path in a Quorlin smart contract has provably bounded computational complexity and predictable worst-case gas consumption.

12.7 Events & Standard Revert Encodings

• emit EventName(args): Emits structured event logs into the receipt trie. Event topics and data layouts match standard Ethereum ABI encoding, allowing Web3 frontends and WebSocket subscribers to receive event notifications transparently.
• require condition, "reason": Enforces runtime preconditions and state invariants. If the boolean condition evaluates to no, the transaction halts execution immediately, discards all pending state modifications, and serializes the error message using the standard Solidity Error(string) selector (0x08c379a0). This ensures that wallets, SDKs, and explorers display clear, human-readable error messages.

12.8 Context & Built-in Keywords

Quorlin provides dedicated, non-spoofable keywords for accessing transaction and execution context:

• caller: The 20-byte address of the immediate message sender (msg.sender).
• nobody: The canonical zero address (0x0000000000000000000000000000000000000000). Checking require recipient != nobody provides clean, idiomatic zero-address validation.
• this: The 20-byte address of the currently executing contract instance.
• value: The amount of native Dinar ($DNR) transferred with the current message call (in wei).
• now: The verifiable block timestamp derived from the continuous dPOH sequence.
• blockNumber: The current canonical block height.

12.9 Composition & Interfaces

Contracts interact with external contracts through declared interface definitions:

interface IERC20 {
    reads number balanceOf(address owner);
    writes truth transfer(address recipient, number amount);
}

When invoking an interface method (e.g. IERC20(tokenAddr).transfer(recipient, amount)), the compiler validates the argument types at compile time and automatically generates the corresponding 4-byte function selector and ABI calldata envelope, routing the call seamlessly across the unified ExecutionRouter.

12.10 Security by Subtraction (Deliberate Omissions)

[!IMPORTANT] To eliminate entire classes of severe smart contract vulnerabilities, Quorlin deliberately excludes problematic language features:

• No Inheritance: Eliminates diamond-pattern storage collisions, shadowed state variables, and complex multi-contract constructor ordering bugs.
• No Fallback / Receive Functions: Prevents accidental ether loss, unexpected selector fall-throughs, and reentrancy entry points.
• No selfdestruct: Contracts can never be erased or cleared from the State Trie, preventing state resurrection attacks.
• No Dynamic Dispatch: Target function selectors and call sites are statically verified at compile time.
• No Unchecked Arithmetic: Prevents silent integer overflow and underflow vulnerabilities.

12.11 Standard Library & Reference Implementations

The Quorlin toolchain includes a formally verified standard library (quorlin/std/) providing reference implementations of core token and governance standards:

• IERC20.ql & KRS20.ql: Fungible token standard with full ERC-20 parity.
• IERC721.ql & KRS721.ql: Non-fungible token standard with safe receiver hooks.
• IERC1155.ql & KRS1155.ql: Multi-token standard for batch transfers.
• IAccess.ql: Role-based and capability-based access control modules.

All reference contracts undergo differential fuzzing against standard solc implementations to guarantee 100% behavioral equivalence.

12.12 Compiler: quorlinc & Toolchain Integration

The native quorlinc compiler (cmd/quorlinc/main.cpp) compiles Quorlin source code into deployable artifacts:

# Compile Quorlin contract to .bin and .abi.json in the build/ directory
quorlinc Token.ql -o build/

# Verify strict storage layout against KRS standards
quorlinc Token.ql --strict-storage-layout --standard KRS-20 -o build/

The toolchain integrates directly with kortana-cli for one-command deployment, testing, and on-chain verification.

---

Part IV — Economics & Governance

This section covers the financial mechanics, security incentives, and protocol governance of the Kortana blockchain.

---