24. The Quorlin Standard Library

The Quorlin Smart Contract Language is designed around expressiveness, readability, and immediate clarity. Unlike legacy smart contract environments that force developers to import large suites of external utility libraries just to execute standard operations—such as token transfers, basic string handling, or cryptographic hashing—Quorlin embeds standard primitives, standard interfaces, and execution context globals directly into the language syntax and runtime.

This chapter details the built-in components that make up the Quorlin Standard Library. It explains how primitive types map directly to Ethereum-compatible Application Binary Interfaces (ABIs), how built-in context variables operate, how standard token interfaces are defined directly within the compiler toolchain, and how cryptographic hashing functions are exposed natively by the Kortana Virtual Machine (KVM).

---

24.1 Standard Primitive Types and Value Identifiers

Quorlin intentionally replaces technical computer science nomenclature with standard human-readable English words. However, under the hood, these human-friendly types map directly to rigorous, low-level data structures defined in the semantic analyzer (sema.cpp), parser (parser.cpp), and ABI generator (abi.cpp).

The primary standard types and their canonical mappings are structured as follows:

Quorlin Standard Keyword	Internal Compiler Type (Type)	Ethereum ABI Type Name	Description
number	Type::U256	uint256	Unsigned 256-bit integer. Default numeric primitive.
truth	Type::Bool	bool	Boolean standard type with literals yes and no.
address	Type::Address	address	20-byte account address representing standard accounts or contract addresses.
text	Type::Text	string	UTF-8 encoded sequence of text characters (bounded size).
nothing	Type::Void	void	Denotes a function that returns no execution value.

Boolean Literals (yes and no)

In standard Quorlin programming, standard boolean constants are spelled yes and no rather than true and false. This makes conditional evaluation read like plain prose:

contract AccessControl {
    truth active;

    constructor {
        active = yes;
    }

    reads truth isOperational() {
        return active;
    }
}

Storage Mappings (map<K, V>)

Key-value associations are first-class standard primitives in Quorlin. Declared using the map<KeyType, ValueType> syntax, standard mappings provide $O(1)$ access times by calculating deterministic storage slot locations using the KVM unified state trie (state_host.cpp).

contract Vault {
    map<address, number> deposits;

    writes truth deposit() {
        deposits[caller] = deposits[caller] + 100;
        return yes;
    }
}

---

24.2 Built-In Context Globals

When executing inside the Kortana Virtual Machine, a smart contract frequently requires information regarding the transaction context. Quorlin exposes these contextual values directly as standard built-in identifiers.

The caller Identifier

The most common context global is caller. It represents the direct address invoking the current execution context (equivalent to msg.sender in Solidity or EVM dialects).

contract OwnerOnly {
    address owner;

    constructor {
        owner = caller;
    }

    writes truth updateOwner(address newOwner) {
        require caller == owner, "Only the contract owner can update ownership";
        owner = newOwner;
        return yes;
    }
}

The semantic analyzer (sema.cpp) automatically checks that caller is evaluated as an immutable Type::Address value during type checking.

---

24.3 Standard Interface Repositories (IERC20)

To facilitate seamless cross-contract composition and token interoperability, Quorlin embeds standard token interfaces directly into the compiler toolchain (standard.cpp). Standard interfaces can be referenced without relying on relative path import statements or third-party package managers.

The IERC20 Built-in Interface

The flagship standard interface baked into Quorlin is IERC20, which standardizes interaction with fungible tokens on the Kortana Blockchain.

As defined in the Quorlin compiler source (quorlin/standard.cpp), the IERC20 standard interface comprises four core methods:

1. totalSupply(): Reads total circulating supply.
2. balanceOf(address owner): Reads token balance for a specific address.
3. transfer(address recipient, number amount): Mutates storage by sending tokens to a recipient.
4. allowance(address owner, address spender): Reads remaining tokens approved for a spender.

// Built-in IERC20 Standard Specification
interface IERC20 {
    reads number totalSupply()
    reads number balanceOf(address owner)
    writes truth transfer(address recipient, number amount)
    reads number allowance(address owner, address spender)
}

Note on Interface Omissions: Optional EIP-20 functions such as name(), symbol(), and decimals() are omitted from the native IERC20 interface definition in standard.cpp. Returning standard text primitives from external contract calls introduces unnecessary memory overhead during pure execution logic; these fields are intended for off-chain display tools rather than programmatic on-chain token movement.

Interoperating with External ERC-20 Tokens

Using the standard built-in IERC20 interface, interacting with any standard token on Kortana is straightforward:

contract TokenSwapper {

    writes truth forwardTokens(address tokenAddress, address recipient, number amount) {
        IERC20 token = IERC20(tokenAddress);
        
        // Execute the ERC-20 transfer standard method
        truth success = token.transfer(recipient, amount);
        require success, "Token transfer failed";

        return yes;
    }
}

---

24.4 Standard Cryptographic & Arithmetic Operations

The Kortana Virtual Machine (KVM) exposes high-performance cryptographic primitives and mathematical instruction sets that underpin Quorlin’s runtime library.

Cryptographic Hashing (keccak256 and blake3)

Quorlin leverages native KVM instructions (interpreter.cpp) for computing cryptographic digests directly inside contracts. Both standard Ethereum Keccak-256 and BLAKE3 hash primitives are supported at the virtual machine layer:

• Keccak-256: Used for generating EVM-compatible function selectors, event signatures, and standard state trie lookup keys.
• BLAKE3: High-throughput hashing primitive leveraged for fast integrity verification and internal Kortana consensus structures.

In the compiler runtime, function selectors are calculated automatically by computing the Keccak-256 digest of the canonical method signature:

$$\text{Selector} = \text{Keccak256}(\text{"transfer(address,uint256)"})[0..3]$$

This mechanism ensures complete ABI parity with traditional Ethereum tooling while executing on the KVM architecture.

Math Operations and Safe Arithmetic

All arithmetic operations in Quorlin (Add, Sub, Mul, Div, Mod) default to 256-bit safe mathematical bounds. As seen in sema.cpp and arith.cpp, signed and unsigned arithmetic are checked carefully during evaluation:

• Unsigned 256-bit operations (number) abort execution on overflow or underflow unless explicitly using wrapping operators.
• Special signed math primitives (SDiv, SMod, SLt, SGt) govern signed arithmetic natively at the KVM ISA level (isa.cpp).

contract MathSafety {
    
    reads number calculateShare(number totalAmount, number shareRatio) {
        require shareRatio > 0, "Ratio must be greater than zero";
        number result = totalAmount / shareRatio;
        return result;
    }
}

---

24.5 The Quorlin ABI Emitter and Standard Type Resolution

To ensure that Quorlin smart contracts remain fully interoperable with existing decentralised application (dApp) frontends, wallet drivers, and block explorers, the compiler includes a dedicated ABI generator (abi.cpp).

When Quorlin code is compiled into executable KVM bytecode, the compiler simultaneously produces a standard JSON Application Binary Interface. The ABI generator converts human-readable Quorlin types back into standard Ethereum ABI data types:

// Excerpt from parser.cpp showing human types vs ABI standard types
std::string_view abi_type_name(Type type) noexcept {
    switch (type) {
        case Type::U256: return "uint256";
        case Type::Bool: return "bool";
        case Type::Address: return "address";
        case Type::Text: return "string";
        case Type::Void: return "void";
        case Type::Invalid: return "<invalid>";
    }
    return "<unknown>";
}

ABI JSON Generation Example

For the following Quorlin contract event and function definitions:

contract StorageHub {
    event Stored(address indexed user, number value);

    writes truth store(number value) {
        return yes;
    }
}

The standard ABI engine (abi.cpp) emits the exact standardized JSON schema required by external Ethereum tools (e.g., web3 libraries):

[
  {
    "type": "event",
    "name": "Stored",
    "inputs": [
      {
        "name": "user",
        "type": "address",
        "internalType": "address",
        "indexed": true
      },
      {
        "name": "value",
        "type": "uint256",
        "internalType": "number",
        "indexed": false
      }
    ]
  },
  {
    "type": "function",
    "name": "store",
    "inputs": [
      {
        "name": "value",
        "type": "uint256",
        "internalType": "number"
      }
    ],
    "outputs": [
      {
        "name": "",
        "type": "bool",
        "internalType": "truth"
      }
    ],
    "stateMutability": "nonpayable"
  }
]

---

24.6 Error Handling and Assertions (require)

Error checking and assertion handling are built directly into the Quorlin language syntax. The standard guard statement is require, which takes a standard truth expression and a diagnostic text string.

require condition, "Error message string";

Internal Execution Dynamics

When a require check evaluates to no (false):

1. The execution aborts immediately.
2. State mutations executed during the call frame are completely reverted.
3. The KVM executes an Opcode::Revert instruction, returning the encoded error string back to the transaction caller.
4. Remaining unconsumed transaction gas is preserved and returned to the originator.

contract Escrow {
    map<address, number> lockedBalances;

    writes truth withdraw(number amount) {
        number available = lockedBalances[caller];
        
        // Guard check using standard require primitive
        require available >= amount, "Insufficient locked balance for withdrawal";

        lockedBalances[caller] = available - amount;
        return yes;
    }
}

---

24.7 Comprehensive Example: A Custom Token standard Contract

To summarize how standard types, standard interfaces, error checking primitives, mappings, and context globals work together, consider this complete implementation of a standard token contract written in Quorlin:

contract StandardToken {

    number totalSupply;
    map<address, number> balances;
    map<address, map<address, number>> allowances;

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

    constructor {
        totalSupply = 1000000000;
        balances[caller] = totalSupply;
        emit Transfer(address(0), caller, totalSupply);
    }

    reads number getTotalSupply() {
        return totalSupply;
    }

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

    writes truth transfer(address recipient, number amount) {
        number senderBalance = balances[caller];
        require senderBalance >= amount, "Transfer amount exceeds balance";

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

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

    writes truth approve(address spender, number amount) {
        allowances[caller][spender] = amount;
        emit Approval(caller, spender, amount);
        return yes;
    }

    writes truth transferFrom(address sender, address recipient, number amount) {
        number currentAllowance = allowances[sender][caller];
        require currentAllowance >= amount, "Transfer amount exceeds allowance";

        number senderBalance = balances[sender];
        require senderBalance >= amount, "Transfer amount exceeds balance";

        allowances[sender][caller] = currentAllowance - amount;
        balances[sender] = senderBalance - amount;
        balances[recipient] = balances[recipient] + amount;

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

Summary of Architectural Benefits

1. Zero External Standard Imports: Standard interfaces (IERC20), primitives (number, truth, address), and primitives are built into the language itself.
2. Deterministic Security: Types are strictly validated during semantic analysis (sema.cpp), preventing standard ABI mismatch bugs before bytecode generation.
3. Cross-EVM Interoperability: Emits standard ABI selector hashes (abi.cpp), allowing seamless contract calls between Quorlin and standard Solidity contracts running on the Kortana Blockchain.