XE Research
The hard problems of a machine economy, solved in the open.
How does a network prove a machine was really there? How fast is it, really? Whose clock decides what it’s owed? XE works these out as proofs of concept, attacks them, and publishes every spec, open question and release.
For machines to earn in their own right, a network has to know what they did. Not what they claim. What they did, proven, and small enough to keep on chain.
An agent renting a GPU, a node selling an hour of compute, a fleet paying for its own bandwidth: each is a deal between parties who’ve never met. Clouds settle that trust with contracts and reputation. An open network has neither.
So the questions become cryptographic and economic. How do you prove a machine stayed online? How do you measure its hardware without trusting its benchmark? Whose clock decides how long a job ran? And how do you make cheating cost more than it pays? Some of the answers are running on testnet, some are being built, and some are still open, and written down as open.
- Problems a machine economy has to solve
- 6
- Shipped to testnet
- 4
- Proofs of concept, for uptime alone
- 5
- Testnet releases, v0.1.0 to v0.6.0
- 7
Six problems a machine
economy has to solve.
Each is a question the network must answer before a stranger’s machine can be paid fairly. Here is where every one of them stands.
How does a network know a machine was really there?
In research5 proofs of conceptA customer pays a machine to run their work. The machine could claim to be running and do nothing. The customer could claim it was down and refuse to pay. Or the two could agree to fake it together and split what the network pays out.
Clouds settle this with contracts and reputation. An open network has neither, and whatever proof it keeps has to be small enough to live on chain.
XE Uptime Proofs: about once a minute, machine and customer both sign a heartbeat, each linked to the last. An hour folds into one root and a day into one small claim on the chain, and any single minute can still be proven later.
A day of uptime,
proven in one claim.
About once a minute the machine signs a heartbeat and the customer countersigns it. Each is linked to the one before, so neither side can forge one alone, and none can be slipped in later.
one a minute · both sides signSixty heartbeats fold into a single root that stands for the whole hour, and each hour’s root points to the hour before.
60 heartbeats → one rootTwenty-four hourly roots fold once more, into one small claim that settles on chain with the lease: 3,681 times smaller than the heartbeats themselves.
24 roots → one claim · 3,681× smallerIf the customer disputes hour 15, the machine hands over that one heartbeat and the hashes beside its path: six up to the hour, five up to the day. That’s all it takes to settle it.
1 heartbeat + 11 hashesA day of uptime,
proven in one claim.
- 01Both sides sign, every minute
About once a minute the machine signs a heartbeat and the customer countersigns it. Each is linked to the one before, so neither side can forge one alone, and none can be slipped in later.
one a minute · both sides sign - 02An hour folds into one root
Sixty heartbeats fold into a single root that stands for the whole hour, and each hour’s root points to the hour before.
60 heartbeats → one root - 03A day becomes one claim
Twenty-four hourly roots fold once more, into one small claim that settles on chain with the lease: 3,681 times smaller than the heartbeats themselves.
24 roots → one claim · 3,681× smaller - 04Any minute can still be proven
If the customer disputes hour 15, the machine hands over that one heartbeat and the hashes beside its path: six up to the hour, five up to the day. That’s all it takes to settle it.
1 heartbeat + 11 hashes
Five proofs of concept,
one recommendation.
Proof of uptime wasn’t settled on a whiteboard. Each approach was built, measured and attacked before the next one.
- PoC 1Linked heartbeatsAddedHeartbeats signed by both sides, each linked to the last.LearnedNeither side can fake it alone. Together, they could fake 1,000 heartbeats in about a millisecond.
- PoC 2Hourly roll-upsAddedAn hour of heartbeats folded into one root.LearnedAny heartbeat can be proven with six hashes, and the record is 480 times smaller.
- PoC 3Forced delaysAddedA built-in delay in every heartbeat: about 6 ms of work that can’t be run in parallel.LearnedFaking a day now takes real time. But honest machines pay the cost too, and it only raises the price of cheating by a constant.
- PoC 4RecommendedProduction candidateAddedLinked heartbeats, hourly roll-ups and daily claims, in three layers.LearnedA day of proof in one small claim, with collusion left to the economics.
- PoC 5DesignedSession modelAddedWhat happens when the customer goes offline mid-lease.LearnedThree proof tiers: both signatures at full weight, confirmed later at 75%, never reviewed at 50%.
Why the forced delays were left out. They work, but they tax every honest machine to stop a cheat the economics already stop.
For a machine and a customer to fake uptime together, the XE minted would have to be worth more than the XUSD the lease burns, and the network is set so it never is. Forced delays stay on the shelf, ready for governance to switch on if the economics ever change.
Six stages, each built on the last.
No single defence is enough. Each stage adds another way to catch a cheat without changing the ones below it.
- Stage 0Heartbeats and collateralDual-signed heartbeats, with stake on the line. Built in the proof-of-concept code.
- Stage 1SessionsProof tiers for an offline customer, confirmed when they’re back.
- Stage 2Sentinel nodesNodes run by the network that check machines independently.
- Stage 3Open challengesAnyone can challenge a machine, and earn a bounty for catching it.
- Stage 4Trusted hardwareProof from the machine’s own secure hardware, where it has it.
- Stage 5Confidential VMsThe workload’s integrity verified by the hardware itself.
No machine sets
its own clock.
How long a lease ran decides how much XE is minted for it. So the start and the end are witnessed by XE Timekeepers, and a machine’s own clock is never asked.
A benchmark that can’t be
faked, borrowed or rushed.
Every machine that takes leases proves its hardware first: about a minute of work, timed by the network, signed and valid for seven days. Try to cheat it.
- One test
- ~60 s
- Tuned for mid-range hardware. Testnet machines took 59 s and 62 s
- Slower if outsourced
- 10,000×
- Every step waits on the machine’s own memory. Over a network, each waits a round trip
- Per certificate
- 7 days
- Then the machine proves itself again
- Checked against it
- Every lease
- A lease is only accepted against a valid certificate that belongs to the machine
Unsolved,
and written down.
The problems still open on XE. If you work on verifiable compute, mechanism design or distributed systems, these are the ones worth your time.
- 01PerformanceHow do you prove a machine is still delivering, an hour into a lease?
A certificate proves the hardware at startup. Heartbeats prove the machine is there. Neither proves it’s still giving the lease what was paid for.
The lead idea: small benchmarks carried inside the heartbeats, so degradation shows up while the lease runs.
Where it stands
- 02UptimeHow do you catch a machine that has promised more than it has?
Each lease is checked on its own, so a host with 8 vCPUs that has sold 12 still looks healthy, one lease at a time.
Candidates: machines declaring their total capacity, sentinel nodes watching commitments across leases, and hardware proofs.
Where it stands - 03UptimeWhat is an absent customer’s silence worth?
Heartbeats need both signatures. When the customer goes offline, the machine carries on signing alone.
A session model with three proof tiers is designed: full weight for both signatures, 75% if the customer confirms later, 50% if they never do.
Where it stands - 04VerificationHow should strangers be paid to catch cheats?
The strongest check comes from someone with nothing to gain from either side of the lease.
Open challenges, stage 3 of the rollout: anyone can challenge a machine, and earns a bounty when the challenge holds.
Where it stands - 05PerformanceCan a benchmark be checked without running it again?
Checking a benchmark today means running every one of its steps again.
Checkpoints along the way, so a checker can spot-check parts of it instead of replaying the whole thing.
Where it stands - 06SettlementHow should the chain rule on a dispute?
The proof is specified: one heartbeat and the hashes beside its path to the claim. How the chain weighs it and decides is still being written.
On-chain arbitration logic is on the list of work to finish before production.
Where it stands - 07HardwareHow far can hardware vouch for the work?
Secure hardware and confidential VMs can vouch for what’s running, but not every machine has them.
Stages 4 and 5 of the rollout. Nothing below them depends on them, so machines without the hardware still take part.
Where it stands
Paying for what the hardware actually delivers.
Today every vCPU costs the same, so a high-end server and a Raspberry Pi earn the same rate. The model being designed prices a lease by measured performance, with one lever for what compute costs and another for how much XE is minted.
A fast machine for one hour is worth the same as a machine half as fast for two. Two coefficients mean the price of compute and the supply of XE can be set apart.
The measurement has to be reproducible, hard to game and cheap enough to run often.
Benchmark on provisionSelf-reported, then verifiedMicro-benchmarks in heartbeatsA machine is more than its cores. What it’s worth depends on the whole of it.
CPU, single and multi-coreMemory bandwidthDisk IOPS and throughputNetwork latency and bandwidthA machine benchmarking itself could inflate its score. A customer running it could deflate it.
The machineThe customerA timekeeperA sentinel nodeMeasure once and it goes stale. Measure constantly and the measuring eats the work.
At registrationPer leaseContinuouslyThe cost coefficient prices compute. The emission coefficient sets how fast XE supply grows.
Protocol constantsDAO governanceThe market, for priceIf stake rises with claimed performance, an inflated benchmark puts more at risk.
Flat share of costScaled to claimed scoreResearch, running
on testnet.
Seven releases in under eight weeks, from the first XE Lattice to shared accounts. Each with a changelog.
- 21–23 Feb 2026v0.1.0The XE Lattice
- A chain for every account
- Keys for identity and signing
- XE Signatures on every block
- 24 Feb – 6 Mar 2026v0.2.0Two assets and compute leasing
- XE and XUSD, tracked per account
- Leasing compute on other machines
- The explorer and the web wallet
- 10–12 Mar 2026v0.3.0The XE State Chain, VMs, messaging and XE Timekeepers
- A chain of its own for the network’s rules
- Nodes finding each other across the XE Mesh
- XE Timekeepers for lease timing
- 13 Mar 2026v0.3.1Multi-resource leases and the account directory
- Leases priced by vCPUs, memory and disk
- An account directory, so any account can be reached
- Account-to-account chat, routed through the directory
- 1 Apr 2026v0.4.1One CLI, XE Timekeepers required
- A single xe app, with the node included
- Leases can’t be accepted or settled without XE Timekeepers
- The network’s ID sealed into every block, so blocks can’t be replayed elsewhere
- 2 Apr 2026v0.4.2The XE Benchmark
- A one-minute test on startup, witnessed by XE Timekeepers
- A memory phase, so the test can’t be outsourced
- Certificates shared with every node and checked on every lease
- 13 Apr 2026v0.6.0Shared wallets and the testnet token model
- Accounts that need several of their keys to spend, with keys you can rotate
- A one-time genesis mint of XE; XE can no longer be claimed
- Voting weight now follows XUSD balances
How the work gets done.
Every spec, attack and open issue.
The most complete description of the protocol todayXE Uptime ProofsThe problem, five proofs of concept, and the recommendationThreat analysisThe red-team review of how uptime is proven, open issues includedXE BenchmarkThe test, why it can’t be cheated, and future workXE ConsensusWhen representatives vote, and how a conflict is settledEconomicsToday’s pricing, its problems, and the model being designedChangelogEvery testnet release, and what changed in itWhitepaperIn preparationThe protocol in one documentStraight answers.
What XE’s research covers, how it’s done, and how to take part.
What does XE’s research work on?
The problems a network has to solve before machines can be paid by strangers: proving a machine was online (XE Uptime Proofs), proving what its hardware can do (the XE Benchmark), agreeing on time (XE Timekeepers), settling conflicts without global consensus, pricing compute by performance, and governing the network’s own settings.
What are XE Uptime Proofs?
A way for a network to prove a machine was really running a customer’s work. Machine and customer both sign a heartbeat about once a minute, each linked to the last. An hour folds into one root and a day into one small claim, 3,681 times smaller than the heartbeats themselves, and any single minute can still be proven later.
Why doesn’t XE force a delay into every heartbeat?
Forced delays stop a colluding pair faking heartbeats in bulk, but they cost honest machines too and only raise the price of cheating by a constant. XE relies on economics instead: the network is set so the XE minted for fake uptime is always worth less than the XUSD the lease burns, so collusion loses money. Forced delays stay available as an option governance can switch on.
How does XE know how fast a machine is?
Every machine that accepts leases runs the XE Benchmark: about a minute of steps that can only run one after another, then a phase in the machine’s own memory that’s about 10,000 times slower if outsourced. Its start and end are witnessed by XE Timekeepers, and the result is a signed certificate, valid for seven days and checked on every lease.
Does XE run consensus on every transaction?
No. Every account has its own chain, so a block that conflicts with nothing is final as soon as it’s checked. Representatives only vote when an account publishes two blocks in the same place, and the fork is settled at 67% of the voting weight frozen when it was detected.
Is XE’s research public?
Yes. Specifications, proofs of concept, threat analyses and known issues are published in the XE docs, with a changelog for every testnet release.
Is there an XE whitepaper?
It’s being prepared. Until it’s published, the architecture docs are the most complete description of the protocol, with more detail on the XE Lattice, XE Consensus and compute leasing.
How can researchers get involved?
Read the specs and the open questions on this page, then join the discussion in the community. The questions marked open are where outside work helps most.