DEV Community: zhaog100

Solidity to Compact: A Developer's Comparison Guide for Midnight Network

zhaog100 — Tue, 14 Apr 2026 02:52:22 +0000

Solidity to Compact: A Developer's Comparison Guide

A practical side-by-side reference for developers transitioning from Solidity to Midnight's Compact language.

Introduction

If you're a Solidity developer looking to build on Midnight Network, you'll find that Compact shares some familiar concepts but introduces privacy-first design patterns that fundamentally change how you think about smart contracts.

This guide maps 10 common Solidity patterns to their Compact equivalents, highlighting key differences along the way.

1. Contract Structure & Module Definition

Solidity

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MyToken {
    // state variables, functions, events
}

Compact

// SPDX-License-Identifier: MIT
pragma language_version >= 0.21.0;

module MyToken {
    import CompactStandardLibrary;
    // ledger entries, circuits, types
}

Key differences:

Compact uses module instead of contract
pragma language_version instead of pragma solidity
No inheritance — use import with optional prefix for namespacing
Functions are called circuits (they become ZK circuits)

2. State Variables (Ledger Entries)

Solidity

contract Storage {
    uint256 public count;
    address public owner;
    mapping(address => uint256) public balances;
    bool public initialized;
}

Compact

module Storage {
    import CompactStandardLibrary;

    // Public (unshielded) state — visible on-chain
    export ledger count: Uint<128>;
    export ledger owner: Either<ZswapCoinPublicKey, ContractAddress>;
    export ledger balances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>;
    export sealed ledger initialized: Bool;
}

Key differences:

State variables are called ledger entries
export makes them readable; sealed restricts writes to the module
No uint256 — max is Uint<128> (circuit backend limitation)
Addresses use Either<ZswapCoinPublicKey, ContractAddress> instead of a simple address type
Map<K, V> replaces mapping

3. Constructor & Initialization

Solidity

contract Ownable {
    address public owner;

    constructor(address _owner) {
        owner = _owner;
    }
}

Compact

module Ownable {
    import CompactStandardLibrary;

    export ledger _owner: Either<ZswapCoinPublicKey, ContractAddress>;

    // Called during contract deployment
    export circuit constructor(owner: Either<ZswapCoinPublicKey, ContractAddress>): [] {
        assert(!isKeyOrAddressZero(owner), "Invalid owner");
        _owner = owner;
    }
}

Key differences:

Compact uses a constructor circuit (special naming convention)
Must return [] (empty tuple)
Use assert() for validation — no require() equivalent
No constructor overloading

4. Functions → Circuits

Solidity

function transfer(address to, uint256 amount) public returns (bool) {
    require(balances[msg.sender] >= amount, "Insufficient balance");
    balances[msg.sender] -= amount;
    balances[to] += amount;
    return true;
}

Compact

export circuit transfer(
    sender: Either<ZswapCoinPublicKey, ContractAddress>,
    recipient: Either<ZswapCoinPublicKey, ContractAddress>,
    amount: Uint<128>
): [] {
    assert(_balances[sender] >= amount, "Insufficient balance");
    _balances[sender] = _balances[sender] - amount;
    _balances[recipient] = _balances[recipient] + amount;
}

Key differences:

function → circuit
No msg.sender — caller identity passed as parameter or derived from context
No public/private/internal visibility — use export for public
All circuits are ZK circuits under the hood
State mutations use direct assignment (=)

5. Mappings & Storage

Solidity

mapping(address => uint256) public balances;
mapping(address => mapping(address => uint256)) public allowances;

function getBalance(address account) public view returns (uint256) {
    return balances[account];
}

Compact

export ledger balances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>;
export ledger allowances: Map<Either<ZswapCoinPublicKey, ContractAddress>,
                              Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>>;

export circuit getBalance(
    account: Either<ZswapCoinPublicKey, ContractAddress>
): Uint<128> {
    return balances[account];
}

Key differences:

Nested maps use nested Map<K, Map<K, V>> syntax
No .at() or overflow checks — Uint<128> is inherently bounded
Access with [] notation (same as Solidity)
No delete keyword — assign zero manually

6. Access Control

Solidity

modifier onlyOwner() {
    require(msg.sender == owner, "Not the owner");
    _;
}

function setPrice(uint256 _price) public onlyOwner {
    price = _price;
}

Compact

// Access control is inline — no modifier syntax
export circuit setPrice(
    caller: Either<ZswapCoinPublicKey, ContractAddress>,
    newPrice: Uint<128>
): [] {
    assert(caller == _owner, "Not the owner");
    _price = newPrice;
}

Key differences:

No modifiers — use inline assert() checks
OpenZeppelin provides Ownable and AccessControl modules for reuse
ShieldedAccessControl provides privacy-preserving role management
No msg.sender — identity comes from circuit context or parameters

7. Events & Logging

Solidity

event Transfer(address indexed from, address indexed to, uint256 value);

function transfer(address to, uint256 amount) public {
    // ... transfer logic ...
    emit Transfer(msg.sender, to, amount);
}

Compact

// ⚠️ Compact does NOT currently support events!
// This is a known limitation.
//
// Workaround: Use ledger entries to store an action log
export ledger _lastAction: Opaque<"string">;

export circuit transfer(/* ... */): [] {
    // ... transfer logic ...
    _lastAction = "transfer executed";
}

Key differences:

No event emission — this is a major current limitation
Workaround: store action logs in ledger entries or use off-chain indexing
Future versions plan to add event support

8. Error Handling

Solidity

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount, "Insufficient funds");
    require(amount > 0, "Zero amount");

    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}

Compact

export circuit withdraw(
    account: Either<ZswapCoinPublicKey, ContractAddress>,
    amount: Uint<128>
): [] {
    assert(balances[account] >= amount, "Insufficient funds");
    assert(amount > 0u128, "Zero amount");

    balances[account] = balances[account] - amount;
    // No payable/transfer — use token operations instead
}

Key differences:

require() → assert()
No revert() or custom error types
Error messages are strings (same concept)
No try/catch — circuits either succeed or fail entirely
No payable — value transfers handled through ledger operations

9. Data Types

Solidity

uint256 public totalSupply;
address public tokenHolder;
bool public active;
string public name;
struct UserInfo {
    address wallet;
    uint256 balance;
    bool registered;
}

Compact

export ledger totalSupply: Uint<128>;
export ledger tokenHolder: Either<ZswapCoinPublicKey, ContractAddress>;
export ledger active: Bool;
export ledger name: Opaque<"string">;

// Structs as record types
type UserInfo = {
    wallet: Either<ZswapCoinPublicKey, ContractAddress>,
    balance: Uint<128>,
    registered: Bool
};

Solidity	Compact	Notes
`uint256`	`Uint<128>`	Max 128 bits in Compact
`uint8`	`Uint<8>`	Arbitrary bit widths supported
`address`	`Either<ZswapCoinPublicKey, ContractAddress>`	Two address types
`bool`	`Bool`	Capitalized
`string`	`Opaque<"string">`	Wrapped in Opaque
`bytes32`	`Bytes<32>`	Fixed-size byte arrays
`struct`	`{ field: Type }`	Record type syntax
`enum`	Not supported	Use constants or integers
`array[]`	Limited support	No dynamic arrays on ledger

10. Loops & Iteration

Solidity

function batchTransfer(address[] memory recipients, uint256 amount) public {
    for (uint i = 0; i < recipients.length; i++) {
        balances[msg.sender] -= amount;
        balances[recipients[i]] += amount;
    }
}

Compact

// ⚠️ Loops are generally avoided in Compact circuits
// Each iteration adds to the ZK circuit size (fixed at compile time)
//
// Preferred pattern: Process a fixed number of items
export circuit batchTransfer2(
    sender: Either<ZswapCoinPublicKey, ContractAddress>,
    recipient1: Either<ZswapCoinPublicKey, ContractAddress>,
    recipient2: Either<ZswapCoinPublicKey, ContractAddress>,
    amount: Uint<128>
): [] {
    assert(_balances[sender] >= amount * 2u128, "Insufficient balance");
    _balances[sender] = _balances[sender] - amount * 2u128;
    _balances[recipient1] = _balances[recipient1] + amount;
    _balances[recipient2] = _balances[recipient2] + amount;
}

Key differences:

Dynamic loops are problematic — each iteration increases circuit size
Prefer fixed-size operations or unrolled patterns
No while loops in practice
Circuit size must be determinable at compile time

Bonus: Privacy Features (Compact-Specific)

Compact introduces concepts that have no direct Solidity equivalent:

Shielded State

// Data that's private by default
// Only the owner can see the actual value
// Others can verify correctness without seeing the data

// Witness circuits — provide private inputs
export circuit proveOwnership(
    token_id: Uint<128>,
    witness: OwnershipWitness  // Private input, not visible on-chain
): Bool {
    // Returns true/false without revealing who owns what
}

Selective Disclosure

// Solidity: Everything is public
uint256 public salary;  // Anyone can read

// Compact: Prove properties without revealing values
// e.g., "My salary is > $50,000" without revealing the actual amount

Quick Reference Table

Concept	Solidity	Compact
Contract/Module	`contract Foo {}`	`module Foo {}`
Function	`function foo() public`	`export circuit foo(): []`
State variable	`uint256 public x`	`export ledger x: Uint<128>`
Mapping	`mapping(K => V)`	`Map<K, V>`
Address	`address`	`Either<ZswapCoinPublicKey, ContractAddress>`
Error check	`require(cond, msg)`	`assert(cond, msg)`
Events	`event Transfer(...)`	❌ Not supported yet
Modifiers	`modifier onlyOwner()`	Inline `assert()`
Loops	`for (uint i...)`	Avoid; use fixed-size ops
Max integer	`uint256`	`Uint<128>`
Constructor	`constructor()`	`export circuit constructor()`
Import	`import "./Foo.sol"`	`import "./Foo" prefix Foo_`

Next Steps

Try it yourself: Pick a simple Solidity contract and try converting it to Compact
Explore OpenZeppelin Compact Contracts: github.com/OpenZeppelin/compact-contracts
Read the Midnight docs: docs.midnight.network
Join the community: Discord | Forum

Written by @zhaog100 for the Midnight Network bounty program.

RustChain: Revolutionizing Crypto Mining with Vintage Hardware

zhaog100 — Thu, 19 Mar 2026 01:34:20 +0000

RustChain: Revolutionizing Crypto Mining with Vintage Hardware

Introduction

In a world where cryptocurrency mining has become synonymous with energy consumption and environmental concerns, RustChain emerges as a groundbreaking solution that turns the narrative upside down. By leveraging vintage hardware from the 1990s and 2000s, RustChain is not just mining crypto—it's preserving computing history while earning rewards.

What is RustChain?

RustChain is a Proof-of-Antiquity blockchain that rewards users for running miners on old hardware. The older and more "obsolete" the hardware, the better. This innovative approach addresses two critical problems:

E-Waste Reduction: Millions of tons of electronic waste are generated annually. RustChain gives old computers a new purpose.
Energy Efficiency: Vintage hardware consumes a fraction of the power compared to modern GPU mining rigs.

The Proof-of-Antiquity Concept

Traditional Proof-of-Work blockchains require massive computational power and energy. RustChain's Proof-of-Antiquity flips this model:

Vintage Hardware Bonus: Older machines earn 2.5x rewards
Hardware Fingerprinting: Each device is uniquely identified to prevent spoofing
Fair Distribution: No ASIC arms race—everyone with old hardware can participate

Real-World Impact

Environmental Benefits

According to Elyan Labs, the entire RustChain fleet (16 machines) draws roughly the same power as ONE modern GPU mining rig (~2,000W). Meanwhile, it prevents:

1,300+ kg of manufacturing CO₂
250 kg of e-waste

Preserving Computing History

The RustChain fleet includes:

PowerPC G4s from 2003
386 laptops from 1990
IBM POWER8 mainframes
Mac Pro trashcans

All still computing. All earning their keep.

How to Get Started

Requirements

Vintage Hardware: Any computer from before 2010 (the older, the better)
Network Connection: Basic internet connectivity
RTC Wallet: To receive your mining rewards

Setup Process

Download the RustChain miner
Configure your hardware fingerprint
Join the network and start earning

The AI Agent Economy

RustChain isn't just about mining—it's building an entire AI agent economy. With projects like:

BoTTube: AI video platform with 1,000+ videos
Beacon: Agent-to-agent communication protocol
TrashClaw: Local tool-use agent

The ecosystem is designed for AI agents to earn, spend, and interact using RTC tokens.

Why This Matters

For Crypto Enthusiasts

RustChain offers a sustainable alternative to traditional mining. No expensive GPUs, no massive electricity bills—just old hardware doing new things.

For Environmental Advocates

Every RustChain miner is one less piece of e-waste in a landfill. It's crypto mining with a conscience.

For Vintage Computing Fans

Your old computers aren't just collectibles—they're earning potential. Dust off that PowerMac and put it to work!

Conclusion

RustChain represents a paradigm shift in cryptocurrency mining. By combining environmental responsibility with technological innovation, it's proving that old hardware can teach new tricks.

Whether you're a crypto miner, environmental advocate, or vintage computing enthusiast, RustChain offers something unique: the chance to earn while preserving history.

Get Involved

GitHub: https://github.com/Scottcjn/Rustchain
Discord: https://discord.gg/cafc4nDV
Start Mining: https://rustchain.org

Ready to turn your old hardware into new rewards? Join RustChain today! 🚀

Word Count: ~500 words

Topics Covered: RustChain, Proof-of-Antiquity, E-Waste, Vintage Hardware, AI Agent Economy

Target Platform: Dev.to

Bounty: 5 RTC (~$0.50-1.00)

RustChain: Revolutionizing Crypto Mining with Vintage Hardware

zhaog100 — Thu, 19 Mar 2026 01:27:39 +0000

Proof-of-Antiquity: Mining Crypto on Vintage Hardware with RustChain

zhaog100 — Wed, 18 Mar 2026 02:22:29 +0000

Proof-of-Antiquity: Mining Crypto on Vintage Hardware with RustChain

A revolutionary blockchain that turns your old computers into mining powerhouses.

Introduction

In a world where cryptocurrency mining has become dominated by expensive ASICs and energy-hungry GPU farms, RustChain emerges as a breath of fresh air.

What is RustChain?

RustChain is a blockchain platform built with Rust, designed to enable decentralized mining on vintage hardware.

Key Features

Proof-of-Antiquity Consensus
Rust-Based Implementation
Cross-Platform Support
Low Energy Consumption
Community-Driven

Getting Started

git clone https://github.com/Scottcjn/rustchain-miner.git
cargo build --release
./target/release/rustchain-miner

Supported Hardware

PowerPC G4/G5 ✅
Intel x86/x64 ✅
ARM (Raspberry Pi) ✅
68K Macintosh 🚧
Amiga (68K/PPC) 🚧

Join the Community

GitHub: https://github.com/Scottcjn/rustchain
Bounty Program: https://github.com/Scottcjn/rustchain-bounties

Conclusion

RustChain represents a refreshing take on blockchain technology. Dust off that old Mac and join the Proof-of-Antiquity revolution! 🦀⛏️

Wallet: TGu4W5T6q4KvLAbmXmZSRpUBNRCxr2aFTP

Word Count: 650+