ConfidentialERC20: encrypted tokens in standard Solidity

Celar is fully EVM-equivalent — standard Solidity, wallets, JSON-RPC, and tooling work unmodified. Encrypted computation enters through precompiles exposed by a standard library: encrypted integers (euint8…euint64) and booleans (ebool) that contracts manipulate as 32-byte handles while ciphertext lives in the FHE data plane.

A confidential transfer

import {TFHE, euint64, ebool} from "celar/TFHE.sol";

contract ConfidentialVault {
  mapping(address => euint64) private bal;

  function transfer(address to, euint64 amt) external {
    ebool ok = TFHE.and(
      TFHE.le(amt, bal[msg.sender]),      // funds check
      TFHE.le(amt, TFHE.sub(MAX, bal[to])) // overflow guard
    );
    euint64 m = TFHE.select(ok, amt, ZERO);
    bal[msg.sender] = TFHE.sub(bal[msg.sender], m);
    bal[to]         = TFHE.add(bal[to], m);
    // no revert, no branch, no leakage
  }
}

Branchless by rule, safe by construction

Notice there is no require on the encrypted check. That's the branchless rule: no revert may depend on encrypted data, because a data-dependent revert would turn confidential state into a public oracle. Comparisons flow only into select — the transfer moves the amount or an encrypted zero, and the transaction is valid either way. The rule is enforced at compile time and re-checked by bytecode analysis at deployment: a privacy leak is a build error, not an audit finding.

What developers get

• balanceOf returns a handle decryptable only by its owner (threshold re-encryption).
• Uniform events and flat per-class gas tiers — outcomes and realized gas never fingerprint encrypted control flow.
• Backend-agnostic ABI: the FHE engine is swappable at node level, invisible to deployed contracts.