Learn · 8 min read

Smart contracts on XELIS

The problem privacy-preserving programmability is trying to solve, and how XELIS's contract layer is being designed to keep state encrypted by default.

The category gap

Monero is private but barely programmable. Ethereum is programmable but fully transparent — every contract state, balance, and call is public forever. The interesting space is the intersection: private programmable money. XELIS is building toward it.

Why privacy + programmability is hard

Smart contracts need state. Validators execute the same code on the same inputs and must reach consensus on the result. If the inputs (balances, parameters) are encrypted, validators can't just re-run the code — they need to verify computation over ciphertext.

Two tools make this tractable:

  • Homomorphic encryption for additive operations on encrypted balances (transfer, escrow accounting).
  • Zero-knowledge proofs for everything else — proving a function was evaluated correctly on private inputs without revealing them.

XELIS's design direction

Public roadmap details continue to evolve, but the published direction follows three principles:

  1. Encrypted state by default. Contracts hold balances and parameters as ciphertext. Disclosure requires an explicit view key.
  2. Predictable gas without leaking inputs. Worst-case execution costs are public; actual inputs aren't. This avoids the side-channel where gas usage reveals secret values.
  3. Composability across confidential and transparent assets. Contracts can hold XEL alongside future tokens, with mixed privacy levels under user control.

What you'll likely be able to build

  • Private payments with conditions. Time-locked transfers, multi-sig escrow, payroll splits — all amount-hidden.
  • Confidential token issuance. Asset issuers whose total supply and per-holder balance are encrypted on-chain.
  • Private DAOs. Voting weighted by encrypted balances, results provable via ZK proof, individual votes hidden.
  • Auditable charities / payroll. Public-facing aggregates revealed by the entity's view key; individual amounts private.

What you probably won't get on day one

  • EVM compatibility. Solidity assumes transparent state — porting it onto encrypted state is a category error, not a translation.
  • Free composability with public DeFi protocols. Private state doesn't compose with public state without disclosure.
  • Sub-second contract calls in early versions. Generating ZK proofs on the client side adds latency.

How this compares

ChainSmart contractsState privacy
EthereumYes (Solidity / Vyper)None — fully public
AztecYes (Noir)Private notes via SNARKs
MoneroMinimalTransactions private; no general contracts
XELISOn roadmapEncrypted state by default

What this means for users today

The current XELIS Layer 1 already gives you encrypted balances and confidential transactions — without contracts. As the contract layer ships, the same wallet you use today will gain access to programmable money without losing the privacy default. Self-custody, view keys, and stealth addresses persist.

Frequently asked questions

Does XELIS have smart contracts today?

The smart-contract layer is on the active roadmap. Core privacy primitives (encrypted balances, ZK proofs, stealth addresses) are live; the contract VM is being developed and audited.

Will contracts be Solidity-compatible?

Likely no. EVM was built for transparent state. XELIS's contract layer is designed around encrypted state from the ground up — a different programming model.

Can a contract read my encrypted balance?

Only with your explicit view key. Default behaviour is encrypted; you choose what to disclose.

Does Monero have smart contracts?

No. Monero deliberately keeps a minimal scripting surface. XELIS's bet is that programmable privacy is the next category jump.

Related reading

Start with the wallet

Smart contracts arrive on the same keys. Set up your XELIS Wallet now.

Download XELIS Wallet