What is Pact? — Kadena's Smart Contract Language

What makes Pact different from Solidity?

Turing-incomplete by design. Solidity allows arbitrary computation including loops that may not terminate. Pact does not allow general unbounded recursion or unbounded loops. The trade-off: Pact cannot express every algorithm Solidity can, but it eliminates an entire class of attacks (gas-exhaustion attacks, infinite-loop denial of service, certain reentrancy patterns) by design rather than by gas limits.

Formal verification as first-class. Pact's design includes properties that can be mathematically proven about contracts. Developers can write specifications alongside code; the verification tooling can prove the code meets the specification. This is more rigorous than Solidity's typical reliance on testing and audits.

Human-readable LISP syntax. Pact uses prefix notation (LISP-style) rather than C-style braces. Some developers prefer this; others find it less familiar. Code is intended to be readable enough that non-developer stakeholders can review what a contract does.

Built-in capabilities model. Pact's permission model uses capabilities — explicit declarations of what an action requires — rather than implicit msg.sender checks. This produces clearer authorization logic and reduces certain bug categories.

Module-and-keyset namespace. Code is organized into modules with explicit governance via keysets (cryptographic key collections). Module ownership and upgrade paths are first-class concerns.

Why is Pact Turing-incomplete?

The choice was intentional. Stuart Popejoy and the Kadena team observed that many of Solidity's most damaging vulnerability classes (DAO-class reentrancy, gas exhaustion, certain integer overflows) depend on properties that a Turing-incomplete language can simply prevent. The price is reduced expressiveness — some computational patterns that work in Solidity require different approaches in Pact.

For most DeFi and tokenization use cases, the trade-off favors Pact's restrictions. For applications that require general computation (running a virtual machine, complex on-chain machine learning, etc.), Pact is not the right choice — those applications would target chains designed for general computation.

Pact vs other smart contract languages

Pact's positioning is distinctive: stricter than typical TM-complete languages, with formal verification as a design principle rather than an add-on.

Existing Pact dApps and protocols

eckoDEX. Largest decentralized exchange on Kadena. AMM (automated market maker) model. Operated by RunOnFlux team. See Kadena Swap.

KDSwap. Alternative DEX with smaller liquidity than eckoDEX. Useful for some pair combinations.

Marmalade (KIP-0011). The primary NFT standard on Kadena. Designed to be expressive enough for novel NFT use cases (royalties, fractional ownership, conditional minting) while preserving Pact's security properties.

Kadena Names. Domain-name service for Kadena. Maps human-readable names to k: addresses.

Various lending, yield, and asset-management protocols. Smaller scale than the above but operational.

Is Pact still maintained post-Foundation?

The Pact compiler is open-source and the existing implementation continues to function. Existing Pact contracts continue to run on the chain.

What changed with the Foundation dissolution: there is no longer a paid team actively shipping new Pact language features. Bug fixes and security patches to the compiler are now community-led where they happen at all; major language additions are not actively in development.

For end users of Pact-based applications, the day-to-day experience is unchanged — eckoDEX, Marmalade NFTs, and other Pact dApps continue to function. For Pact developers writing new contracts, the lack of active language development is a meaningful consideration; the language is essentially in its current stable form rather than an evolving target.

Will Pact coexist with Solidity on Kadena via Chainweb-EVM?

Yes, by design. The Chainweb-EVM extension adds 5 EVM-compatible chains alongside the existing 20 Pact chains. Pact-side chains continue to run Pact contracts; EVM-side chains run Solidity contracts. Cross-chain transfers between the two execution environments are part of the design.

This is a meaningful architectural distinction from chains that pick one execution model. Kadena's design intent is for Pact to handle security-critical applications (where formal verification matters most) and Solidity to access the broader Ethereum developer ecosystem.

Chainweb-EVM testnet is operational; mainnet timing is uncertain after the Foundation dissolution. See Kadena EVM.