Mainnet live

Store.Verify.Build.

The infrastructure layer for permanent data and decentralized intelligent services.

Building with

See every integration →
CosmosCosmos SDK · IBC KeplrWallet support OsmosisCosmos chain · IBC InjectiveCosmos chain · IBC GalxeEcosystem campaigns NTT DigitalInstitutional validator XangleMarket data MidnightZK Layer 1 TalisCosmos chain · IBC CosmosCosmos SDK · IBC KeplrWallet support OsmosisCosmos chain · IBC InjectiveCosmos chain · IBC GalxeEcosystem campaigns NTT DigitalInstitutional validator XangleMarket data MidnightZK Layer 1 TalisCosmos chain · IBC
Lumera

The foundation beneath intelligent systems.

Modern applications increasingly rely on permanent data, identity, execution and verification, and today each one comes from a different vendor. Lumera brings them together on one architecture. The more autonomous the software gets — agents that act, spend and decide without a person in the loop — the more it needs all four at once.

One protocol architecture

Every capability is built on the same architecture and execution framework, so Lumera grows through composition rather than as separate systems.

Explore the architecture →
Durable Memory Live
Permanent storage and state that survives sessions, applications and providers.
Cascade
Identity
Cryptographic passports that enforce permissions and delegated authority.
Lumera ID
Verifiable Execution
Actions that produce cryptographic receipts proving what work was performed.
Proof of Service
Settlement
Protocol-native settlement, escrow and incentives for decentralized services.
Global Credits
Trust
A record built from verifiable protocol activity rather than intermediaries or reputation alone.
Trust graph
Cascade

Permanent data. Durable memory.

Pay once. No recurring storage fees. One payment at the point of writing.
Erasure coded. Efficient redundancy with self-healing mechanisms to ensure permanence and retrievability.
Cryptographically verified. Continuous retention proofs, sampled every epoch.
Economically secured. SuperNodes are bonded and forfeit stake if data is lost.
Portable. Independent of any individual model, provider, or application.
Protocol native. Memory belongs to the identity that wrote it, not to the application or vendor it was written through.
48.2M
Total transactions
2.4 PB
Data storage availability
99.97%
Network uptime
41,600
Active wallets

Pay once and the network keeps your data for good.

One write, then any reader
Watch one file go in, get held, and come back out
Application
Reads it back
A different application
Reads it back
A different model
Application
One file, uploaded once
Independent SuperNodes
Redundancy 1.50×
Threshold
Permanent data
A file enters once and the network keeps proving it is still there.
import { Cascade } from "@lumera-protocol/sdk-js"

const cascade = new Cascade(client)

const result = await cascade.upload(file)

console.log(result.txHash)
console.log(result.contentId)
import { Lumera } from "@lumera-protocol/sdk-js"

const lumera = new Lumera({ apiKey: process.env.LUMERA_API_KEY })

const memory = await lumera.memory.open(agentId)

await memory.remember({
  user: "Alice",
  preference: "Window seat"
})

const context = await memory.recall()

The same primitive in two shapes: a file an application stores, or a fact an agent needs to still have next session.

Live on mainnet Production SDKs TypeScript · Go · Rust Permanent storage available today
Explore Cascade → Read the documentation →
Designed to scale

Consensus where it matters. Execution where it scales.

Lumera separates consensus from decentralized services. The blockchain records requests, payments, governance, and cryptographic proofs while economically bonded SuperNodes perform storage, verification, and decentralized execution. This allows sophisticated protocol services to scale independently without compromising security or decentralization.

Control plane
The chain
ConsensusGovernancePaymentsProofs
Latest block
Request · escrow
Client
Your application
Calls the SDK with an API key.
Data path
Never touches consensus
Receipt · settlement
Execution plane
SuperNodes
StorageVerificationExecutionProtocol services
Memory plane
Cascade, plus hot state
Permanent dataDurable memory
One request A request enters at the application and leaves as a receipt.
Who runs what
Validators secure the chain. SuperNodes do the work.
Validators produce blocks and finalize state. SuperNodes hold data, answer retention challenges and run verification. The two roles are separate, and neither can do the other’s job.
What ties them together
Capacity is backed by capital at risk.
A SuperNode stays active only while its validator meets the self-stake threshold. Fall below it and the SuperNode leaves the active set, so the network can never hold more data than it has bonded stake behind.
Build

Three ways in.

Write to the network, hold data for it, or secure it. Each one is open today.

For developers
Build an app
Store a file, get a receipt, settle work. An API key is enough, and the first write costs around 0.02 LUME per MB.
Quickstart
For operators
Run a SuperNode
Hold erasure-coded data, answer retention challenges, run verification. Bonded against loss, and the full service fee on every verified job goes to you.
Operator guide
For validators
Run a validator
Secure consensus and produce blocks. Fifty in the active set, earning block rewards alongside their delegators.
Validator guide
Community

Where the network talks.

Pick the one that matches what you need.

Discord

Builder support and protocol discussion.

X

Releases, upgrades and announcements.

YouTube

Upgrade walkthroughs and explainers.

Telegram

Day to day community chat.

Blog

Deep dives and release notes.

Build where work is provable.

Start building → Explore the network →
PrinciplesThe stackGaps & answersFailure modes

One Architecture.Five Capabilities

Permanent data, identity, verifiable execution, settlement and trust on a single protocol, with memory live on mainnet and each capability built on the one beneath it.

See the architecture →
Principle 01
The chain commits, SuperNodes execute
Permissions, budgets and payments resolve on chain and stay consistent. The data itself never passes through consensus, so throughput is not bound by block time.
Principle 02
Prove it without publishing it
A receipt commits to an event, not a copy of its content, so the work is auditable afterward without exposing what was in it.
Principle 03
Composition over reinvention
Memory, execution and settlement arrive as new operations on the same execution framework the network already runs, never a second settlement path or a parallel identity system.
Principle 04
Authority is graded
A fluent answer is not a proof. Irreversible effects stay in your application; the protocol returns signed results and structured plans.
The stack

Memory at the base. Everything else stands on it.

Durable memory is the layer that shipped first, because none of the others work without it. Hover any capability to see what it rests on and which parts of the network it uses.

What it serves
Applications and agents
Your framework, your models, your product.
Serves
Identity
Built on memory
Verifiable Execution
Built on memory
Settlement
Built on memory
Trust
Built on memory
Built on
The foundation Live
Durable Memory
Permanent, provable storage. Everything above it needs a record that outlives the session that made it.
Memory
Runs on
Execution plane
SuperNodes
StorageVerificationComputeProtocol services
Memory plane
Cascade, plus hot state
Permanent dataDurable memory
Control plane
The chain
ConsensusGovernancePaymentsProofs
One foundation carries all of it, which is why a new capability does not mean a new network. Data never passes through consensus
The gaps and the answers

What’s missing today, and how Lumera solves it.

The gaps are architectural, not incremental, and they depend on each other. Identity without settlement is unenforceable. Settlement without identity is unaccountable. Open any row to see what breaks today and what replaces it.

01
Lumera ID
No sovereign identity
Trust & Identity
An identity the agent owns, not an API key on someone else’s account.
+
Today

An agent’s identity is an API key belonging to someone else. Revocable, non-portable, carrying no independent reputation. It cannot accumulate a record, delegate authority, or be held accountable for anything.

On Lumera

Lumera ID is the universal on-chain principal for users, agents, applications, data assets and providers. It is a container that accumulates claims over time.

ProfileKeyRotationDelegationCapabilityGrantAppIdentityAssetIdentityAttestation

Delegation chains are the enterprise wedge. Grant an agent a budget class or a dataset. Scoped, time-bound, revocable, enforced on-chain.

02
Proof of Service
No verifiable execution
Verifiable Execution
Proof of what ran, what it cost, and that you accepted it.
+
Today

Nothing proves what model ran, what data it consumed, what it cost, or whether it was the model advertised. The client trusts the provider completely.

On Lumera
Global Credits
Fund once. Provider-agnostic.
Per-Turn Acknowledgment
Only accepted turns are billable.
Transcript Fingerprints
Verifiable in dispute, never in plaintext.
03
Cascade
No durable memory
Durable Memory
Memory that survives switching providers.
+
Today

Agent state lives in provider-controlled databases. Switch providers, lose context. No memory the agent owns, no institutional knowledge that accumulates, no data sovereignty.

On Lumera

Cascade is content-addressed erasure-coded storage with BLAKE3 Merkle proofs. Alongside it sits a leaderless quorum-replicated database for hot state, the tier an application reads from between writes. Large values overflow from one to the other transparently.

ONE / QUORUMVector clocksHinted handoffAnti-entropy repairSigned write receipts
04
LUME · Everlight
No native settlement
Settlement
Someone has to pay for permanence, not just usage.
+
Today

Payment rails assume a human at the end. An agent cannot hold a balance, earn revenue, or settle a transaction on its own behalf.

On Lumera

LUME is the settlement, staking and governance token. Everlight funds what per-use fees cannot: an artifact that must stay available for years, a verifier ready before it is needed, a node paid for capacity.

See the token model →
What happens when it goes wrong

When an agent is wrong, the damage is contained.

Three classes of execution, three consequences when something goes wrong. They never collapse into each other.

Reasoning
Example
A model analyzes a contract
Check
No replay is possible, so output is advisory
Consequence
Reputation only

Quality moves the trust graph. Nothing is slashed.

Deterministic compute
Example
A pack transforms data
Check
A second node replays it
Consequence
Slashable

If runner and verifier disagree, that is objective evidence. No judgement needed.

Effects
Example
A transaction is proposed
Check
Returned as a signed plan
Consequence
App validates

The protocol never fires an irreversible action on its own.

Start at the foundation Live
Durable Memory
None of this holds without a record that is still there when someone checks. Permanent, provable storage is live on mainnet, and it is where the rest of the architecture starts.
Memory

Build where work is provable.

Start building →
LUME

One token, four structural jobs.

LUME is the settlement asset, the security bond, the reputation stake and the governance weight. Each job is tied to activity you can look up on the explorer.

Settlement
Transactional

Every storage write, retention payment, verification job and agent session settles in LUME. Demand scales with real economic activity, not with speculation about it.

Security collateral
Slashable

SuperNodes bond LUME to join the execution plane. Bonds are slashable for objective misbehavior: a deterministic mismatch, a forged receipt, a non-response. More capital flowing through the network requires proportionally more locked LUME.

Reputation collateral
Skin in the game

Staking turns reputation from a score into a commitment that can be lost. An operator or agent with staked reputation has something real at risk.

Governance
Trust-weighted

Parameter changes, fee adjustments and upgrades require LUME-weighted votes, amplified by standing in the trust graph, so those who have done the work carry more weight.

Value accrual

Every job makes the next one easier to trust.

LUME
Settles it all
01
02
03
04
05
01
More data stored and verified → more LUME settlement volume.
02
More settlement → more staking demand for bonds and stakes.
03
More trust data → a richer graph and better routing.
04
Better routing → higher-value workloads.
05
Premium settlement → deeper economic security.

Each turn of the wheel makes the next one cheaper to win. That is the whole argument.

Read the whitepaper → See the economics → See the network
Build

Everything you need to build on Lumera.

Permanent storage, identity, verifiable execution and settlement behind one SDK and one economic model. Build against stable interfaces.

Read the docs → Source code

How settlement works

01
Fund
02
Delegate
03
Invoke
04
Acknowledge
05
Settle
Balance
0
credits
Escrowed
0
credits
Settled
0
credits

Fund a Global Credits balance once, on-chain. Provider-agnostic from the start.

credit values are illustrative
Developer documentation

Network setup, node operation, and protocol interfaces.

Testnet explorer

Watch identities, receipts and settlements as they land.

Source code

The protocol is open. Read it, run it, contribute.

Talk to the team

Bring us what you are building and we will help you ship it.

Durable Memory
Cascade

A memory you can prove.

Written once, readable from any framework, agent, or model, and still provably there decades from now.

An agent that forgets is a demo. Every session starts from nothing, the same context gets re-sent and re-paid for, and anything the agent learned about a customer last week is gone.

The memory that does exist usually sits in a database on someone else’s account. It can be deleted, it can be lost in a migration, and there is no way to show a third party that a record has not been quietly edited.

Lumera stores each fact once, ties it to an identity the agent owns rather than to a vendor account, and keeps re-proving that the data is still held. Your agent reads and writes through an SDK. There is no wallet, no gas and no chain to learn.

Pay once. Prove it forever. Take it anywhere.

01
Store once

Pay once and the fact is kept. There is no renewal to forget and no bill that grows with age.

02
Prove it

The network keeps re-proving that the data is still held, continuously, and anyone can check the result.

03
Take it anywhere

Memory belongs to the identity that wrote it, not to the application or vendor it was written through. Switch model, switch framework, keep the memory.

Retention

Storage nobody has to take on trust.

Paying an operator to hold data is not the same as knowing they still have it. The network settles that question continuously, on its own, without anyone asking.

Challenge
The chain picks a node and a byte range
Each epoch the protocol samples nodes and asks for a specific slice, so a node cannot pre-compute an answer.
Response
The node returns a Merkle proof
A hash path from that slice up to the root the file was committed under. Holding the data is the only way to produce it.
Verdict
The result lands on chain
A pass keeps the node earning. A miss is slashable, and the fragment is rebuilt elsewhere.
One challenge, every epoch, for the life of the file. Retention challenges passed · rolling 30 days 99.982%

Three calls, start to finish

store · recall · prove
import { Lumera } from '@lumera-protocol/sdk-js'

const lumera = new Lumera({ apiKey: process.env.LUMERA_API_KEY })

// 1. open the memory an agent writes under
const memory = await lumera.memory.open(agentId)

// 2. remember a fact once, it is kept forever
await memory.remember({ units: 'metric' })

// 3. recall it from any framework or model
const context = await memory.recall()

// 4. ask the network to prove it is still there
const proof = await memory.prove(context.id)
Works with MCP LangChain CrewAI HTTP API See every adapter →

Questions we get asked

Is this a replacement for Pinecone or S3?
+

No. A vector database makes memory searchable and object storage makes it cheap; neither can prove the data is still there, and both tie the memory to an account you rent. Lumera sits underneath as the permanent, provable copy the agent owns: pay once instead of monthly, retention proven by Merkle challenge instead of promised in an SLA, and every read and write adding to the record the agent carries to its next counterparty. Keep your index, point it here.

Do I need a wallet?
+

No. You call the SDK with an API key, the same as any other service. That key is how you authenticate to Lumera. It is separate from the on-chain identity your data is written under. There is no gas to budget, no token to hold, and no seed phrase for your users.

What happens if we stop paying?
+

Nothing is lost. You pay once at the point of writing, and operators keep being compensated for holding it after that, continuously, out of protocol rewards and a share of network fees. Retention does not depend on a subscription staying current, which is the difference between permanence funded and permanence promised.

Will it work with the framework I already use?
+

Yes, and you do not swap anything out. The MCP connector mounts underneath the harness you already run, so an agent in LangChain, CrewAI or anything else that speaks MCP keeps its loop exactly as it is and gains memory beneath it. There is also a Python and TypeScript SDK, and an HTTP API for everything else.

Can I delete something once it is written?
+

Not in the sense of erasing it, and that is deliberate: a memory you could quietly remove is not evidence. What you control is what goes in, and you can supersede a record so the current answer changes while the history stays intact. Treat it the way you would an append-only ledger, and keep anything you may need to erase out of it.

Built on memory
Identity
A record that outlives the session is what makes an identity worth owning. Next, that memory attaches to a passport the agent holds rather than an account it rents.
Lumera ID
Live on mainnet today
Give it a memory today.

Three calls and an API key. The network keeps the data and keeps proving it is still there.

Read the docs → Open the app
Identity
Lumera ID

An identity you own, not a key a vendor issued.

Cryptographic passports that enforce permissions and delegated authority for people, applications and autonomous systems, so an action can always be traced to whoever was allowed to take it.

Explore the architecture →
How it works today
An agent’s identity is an API key. Whoever holds the key is the agent, there is no way to prove which agent did a particular piece of work, and revoking the key erases the history along with the access. Delegation means sharing a secret.
How it works on Lumera
The identity is a record the agent holds, separate from any application. Permissions are explicit and can be handed to another party for a limited scope without sharing a secret. Every action stays attributable after the fact, because the record outlives the session that made it.
What this is not
Not a login for your users
This is not a sign-in provider and it does not replace how people log into your product. It is the identity the work is signed with, underneath whatever you already use.
Anatomy of an identity

More than a name. A record with a history.

An API key is a secret that grants access. An identity is a thing that accumulates: what it may do, what it has done, and who it lent authority to.

The key
Held by the identity, never by the protocol. Nobody can act as it without it.
Permissions
What this identity is allowed to do, written down rather than implied.
Delegations
Narrow authority handed to another party, with a scope and an expiry.
History
Every action it signed, which stays readable after the session ends.
Anchor
Recorded permanently, so revoking access does not erase the past.
Handing over authority
Without sharing a secret
You
Hold the identity and decide what it may do.
Your application or agent
Gets a narrow permission: this task, this budget, until this point.
Another agent
Can be sub-hired, but never with more authority than it was given.
Revoking access
Withdraw a delegation and everything below it stops too. Nothing has to be rotated, because nothing was shared.
Keeping the history
Revoking stops future actions but leaves the past intact, so what was already done stays attributable.

What a real identity makes possible.

01
Delegated authority
Grant a narrow permission to another agent, for a set scope, without handing over credentials.
02
Attribution
Work is signed, so who did what stays answerable long after the job finished.
03
Portability
The same identity works across applications and models, because it does not belong to any of them.
What it makes possible
A record worth having
A history only counts if it is attached to something that cannot be discarded and started again for free. That is what makes an identity the foundation the trust graph is built on.
Next in the stack
Verifiable Execution
An identity worth trusting needs work that can be checked against it. Next, every job leaves evidence of what actually ran.
Proof of Service
Read the full specification.

The developer documentation carries the detail this page leaves out: the interfaces, the guarantees, and how it fits with everything else.

Read the docs →
Verifiable Execution
Proof of Service

Answers you can check, not answers you have to believe.

Actions that produce cryptographic receipts proving what work was performed, so a result can be re-derived by someone else rather than taken on faith.

Explore the architecture →
How it works today
A model returns an answer and that is the end of it. There is no record of what ran, on what input, at what cost, and no way for a second party to reproduce it. When the answer matters, the only recourse is to trust the vendor that produced it.
How it works on Lumera
Each action leaves a signed receipt naming what was run and what came back. Another node can take the same inputs and re-run the work, so a disagreement is detectable rather than a matter of opinion. Payment can then be tied to work that was checked.
Anatomy of a receipt

Enough to run it again, without trusting anyone.

A receipt is not a log line saying the job finished. It carries everything a second party needs to do the work themselves and compare.

Inputs
A fingerprint of exactly what went in, so nobody can quietly change the question.
Method
Which operator ran it, and what it ran.
Output
A fingerprint of what came back.
Signature
Signed by the identity that did the work, so it is attributable.
Anchor
Written where it cannot be edited later, and can be looked up by anyone.
How a result gets checked
Nobody has to be believed
Work runs
An operator does the job and signs a receipt for it.
Someone else re-runs it
A second operator takes the same inputs and does it independently.
The two are compared
Agreement settles it. Disagreement is visible, not arguable.
They match
The receipt stands, payment releases, and the job becomes a line in the operator’s record.
They differ
Payment stays escrowed and the operator that signed a result it could not defend forfeits part of its bonded stake.

What becomes possible when work is checkable.

01
Re-derivation
A second operator can reproduce the result independently and compare.
02
Dispute resolution
Disagreement resolves against evidence rather than against whoever is larger.
03
Payment on delivery
Money can be released against verified work instead of on a promise.
What this is not
Not a judgement on the answer
The protocol does not decide whether a result is good. It establishes what was run and what came back, so a disagreement has evidence behind it. Quality stays a question for whoever asked.
What it is for
Work that has to answer for itself
An agent spending money, taking a position, or making a call somebody may query months later. The receipt is what turns that from a claim into a record.
How records accumulate →
Next in the stack
Settlement
Once work can be checked, payment can wait for the check. Next, money that only moves when the job is verified.
Global Credits
Read the full specification.

The developer documentation carries the detail this page leaves out: the interfaces, the guarantees, and how it fits with everything else.

Read the docs →
Settlement
Global Credits

Payment that waits for the work to check out.

Protocol-native settlement, escrow and incentives for decentralized services, so an application or an agent can hold a budget, pay a provider, and be paid itself.

Explore the architecture →
How it works today
Payments assume a person with a card. An agent cannot hold a budget, cannot pay another agent, and cannot be paid without a human in the loop. Anything automated runs on invoices and trust between companies.
How it works on Lumera
Funds are escrowed on chain when the job is accepted and released when the work has been verified. Whoever did the work gets paid, whoever paid can see what they paid for, and neither side has to trust the other to settle.
Anatomy of a payment

Money moves in one direction, and only once.

There is no invoice, no net-30, and no dispute window where the money sits with whoever happens to hold it. Each stage is a state the protocol enforces.

Requested
What the job is, and what counts as done.
Escrowed
The amount is locked on chain the moment the job is accepted.
Verified
A second operator confirms the work before anything moves.
Released
Payment goes to whoever did the work, not whoever invoiced for it.
Recorded
Both sides can look up what was paid, for what, and when.
Escrow, end to end
Neither side holds the other’s money
Accepted
Funds leave the buyer and are locked by the protocol.
Held
Nobody can spend them while the work is being checked.
Released
Verification passes and the operator is paid.
If verification fails
The escrow does not release. The operator forfeits part of the stake it bonded against the job, so failing costs money rather than reputation.
If the operator disappears
The job is reassigned and the funds stay locked until someone completes it. The buyer’s money was never in the operator’s hands.

What settlement unlocks.

01
Programmable budgets
An account can be given money to spend within limits it cannot exceed.
02
Agent to agent
One agent hires another and pays it directly, without a human closing the loop.
03
Escrow by default
Payment is held until the work is verified, so neither party carries the other’s risk.
For the people building
No wallet in your product
Your users do not need a wallet, a seed phrase, or a token balance. Settlement happens underneath, and you bill however you already bill. This is how Cascade storage settles today: the fee is escrowed when the write is registered and released when the retention proof lands.
Where the token sits
Underneath, not in front
LUME is what the escrow holds and what operators bond, which is why a failed job can cost the operator something real. It is protocol plumbing rather than a step in anyone’s checkout.
See the economics →
Next in the stack
Trust
Paid, verified jobs are the raw material of a reputation. Next, a record of who actually delivered.
Trust graph
Read the full specification.

The developer documentation carries the detail this page leaves out: the interfaces, the guarantees, and how it fits with everything else.

Read the docs →
Trust
Trust graph

A record of who actually delivered.

Trust built from verifiable protocol activity rather than from intermediaries or reputation alone, accumulated one paid job at a time.

Explore the architecture →
How it works today
You choose a provider on brand name, a landing page, or a recommendation. Nothing in the market records whether a given operator has delivered before, and reputation systems can be bought, gamed, or reset by moving to a new account.
How it works on Lumera
Every job leaves a signed record of who did it and whether it held up. Those records accumulate into a picture of who delivers, earned rather than claimed, and attached to an identity that cannot be discarded and restarted for free.
Anatomy of an edge

Every connection in the graph is one paid job.

Not a review, not a score someone assigned. A line between two identities exists because work was requested, delivered, checked and paid for, and each of those is recorded.

Who
The identity that took the job, and the identity that paid for it.
What
The work requested, and the result that came back.
Verdict
Whether a second operator could reproduce it.
Price
What was escrowed, and what was released.
When
The block it settled in, so the record has a place in time.
Why trust adds up

Every edge is a job that was paid for.

Every job leaves a signed receipt, and the receipts add up into a record of who actually delivers.

Click a participant to see what the network knows about them.

A research agent
illustrative

Research and analysis
0.92
Financial decisions
0.18
Finding data
0.81
1,284 paid jobs · 3 disputes · 40,000 LUME staked
To fake this you would need to pay for 1,284 real jobs and stake 40,000 LUME — and still pass someone else’s verification.

Trusted for research. Untested for finance. A single star rating could never tell you the difference.

Earned, not stored

Every edge is a settled, paid job. Copying the database does not copy the work that produced it.

Backed by stake

Manufacturing a record means bonding real LUME and losing it the moment a verifier disagrees.

Sharper with use

More jobs improve routing. Better routing attracts better work. The loop feeds itself.

Why a record beats a rating.

01
Earned, not bought
Each edge in the graph is a job that was paid for and verified. Any identity can also bond LUME against its own record, operator or not, and a failed job costs it the bond as well as the standing.
02
Attached to identity
The record follows the identity, so a bad history cannot be shed by switching accounts.
03
Readable by anyone
Routing decisions can be made against the record instead of a vendor list.
What it is used for
Choosing who does the work
An agent picking an operator, or a platform routing a job, can read the record directly rather than working from a vendor list. More jobs make routing better, and better routing attracts better work.
The other graph
The intelligence graph
A second graph records what has been learned rather than who delivered: what was asked, what was found, and what it connected to. It is being built on the same permanent layer.
See both in the architecture →
Where it all goes
The whole picture
Memory, identity, evidence, settlement and reputation on one architecture. See what that makes possible.
Vision
Read the full specification.

The developer documentation carries the detail this page leaves out: the interfaces, the guarantees, and how it fits with everything else.

Read the docs →
Press

Lumera in the press.

Coverage, interviews and commentary, including appearances by co-founder Anthony Georgiades.

Coverage
Entries below are slots. Send the coverage list and they fill in.
——
Outlet, headline and link
Featuring Anthony Georgiades, Co-founder
——
Outlet, headline and link
Featuring Anthony Georgiades, Co-founder
——
Outlet, headline and link
Featuring Anthony Georgiades, Co-founder
——
Outlet, headline and link
Featuring Anthony Georgiades, Co-founder
——
Outlet, headline and link
Featuring Anthony Georgiades, Co-founder
Media enquiries
Talk to us.
For interviews, comment or background on the protocol.
press@lumera.io →
Brand assets
Logos and usage.
Wordmark, symbol, color values and the rules for using them.
Download the kit →
Blog

What we shipped, and why.

Follow on X → RSS
Latest Guides · July 20, 2026 · 6 min

How to Migrate Your Lumera Account to EVM

Lumera has upgraded to full EVM compatibility on testnet. If you already hold a Lumera wallet, your account needs to be migrated before it will work with EVM tooling. This walks through every step.

Read the post →
Account migration
Before
lumera1q9x…7f4d
After
0x4Ae2…9C1b
Same keys · same balance · EVM tooling
Updates
July 2, 2026
8 min read
Q2 2026 Update: What’s Ahead

Q2 was Lumera’s strongest quarter yet for on-chain activity and infrastructure growth, a period of consolidation after Q1. Here is what shipped and what comes next.

Releases
June 30, 2026
4 min read
Lumera Is Now EVM-Compatible

Testnet is live and mainnet follows. Everything in this post applies to Lumera Testnet, including the tooling you can point at it today.

Ecosystem
June 19, 2026
3 min read
Xangle Airdrop Campaign for the Korean Community

A campaign run in partnership with Xangle, open to the Korean community, with 10,000 LUME split across 100 winners.

Nothing under that heading yet.
Network

Two roles run the network.

Validators secure the chain. SuperNodes run the services. They are separate on purpose, because consensus should never depend on who is serving a file.

Consensus layer
Validators
50
in the active set

They agree on what happened and in what order. Nothing else.

Fixed set, elected by stake
Responsible for
Block production and finality
Transaction ordering and inclusion
Chain security through staked LUME
Governance execution
Service layer
SuperNodes
128
running today

They do the actual work. The chain only records commitments about it.

Permissionless, bonded
Responsible for
Cascade storage, serving and repairToday
Agent sessions and inferencePlanned
Deterministic pack execution and verificationPlanned
Trust graph indexing and queriesPlanned
Both slashable
Same stake at risk, different failure.
A validator is slashed for
Consensus faults, such as double signing or going dark.
A SuperNode is slashed for
Service faults, such as a deterministic mismatch or a forged receipt.
How work becomes a record

Who does the work, and who keeps the score.

01
SuperNodes do the work
Open set · 128 running
Storage
Keeps files safe
Sessions
Runs the agent
Memory
Holds live state
Compute
Runs and checks work
02
Each step emits a receipt
Signed by the node that did it
Signed receipt ↓
03
Validators order and finalize
Fixed set · 50 validators
They agree what happened and in what order. They never do the work themselves.
04
It becomes the permanent record
One block every 1.9s
Newest block #2,841,902
Come back in a year and the receipt is still there, and so is the thing it points at.

Network at a glance.

Live from the explorer →
Total transactions
48,200,000
Since genesis
Active SuperNodes
128
Across 31 countries
Network uptime
99.98%
Rolling 30 days
Cascade
412 TB used of 2.4 PB total capacity
17% used
2.1M objects stored, each one re-proved on a rolling challenge
Chain
Block height
2,841,902
Block time
1.9s
Active validators
50
Fixed active set
Token
Total supply
1.0B
Circulating
412M
Bonded
41.2%
Staking APR
11.4%
Economics
LUME settled · 30d
1.24M
Everlight pool
8.6M
Funds retention
Uptime · 30d
99.94%
Countries
31
Everlight

Permanence funded, not promised.

A stored artifact must remain available for years. A verifier must be ready before it is needed. An operator must be paid for capacity, not only utilization. Everlight is the economic floor under all five capabilities.

Retention pool

Funded by block rewards, fee shares and endowment yield.

Epoch distribution

Regular, predictable compensation for retained obligations.

Capacity-aware states

Pay reflects readiness and capacity, not just usage.

Endowments

The final stage: principal-preserving funds whose yield will sustain retention indefinitely.

Run a SuperNode.

Bond LUME, serve the network, and take the full service fee on every verified job.

Operator guide →
Economics

The network pays for itself.

Three revenue streams fund the people who secure the chain and the people who hold the data. Every one of them is paid in LUME, settled on chain, and tied to work that was actually done.

Block rewards
98 / 2
98 percent to validators and their delegators for producing blocks, 2 percent to the community pool.
Transaction fees
80 / 20
20 percent is burned, so scarcity tracks usage rather than a fixed emission schedule.
Service fees
100
Paid in full to the SuperNode operators who did the work. Escrowed on chain until the work is verified.
The loop
Usage funds capacity, capacity carries usage
20% burned scarcity tracks usage
Usage 01
Applications store data and settle work.
0.02 LUME / MB
Fees 02
Paid in LUME on every action.
80 / 20 split
Capacity 03
Operators earn, bond more, and hold more.
100% to operators
More capacity carries more usage
What it costs
Roughly 0.02 LUME per MB, paid once. No monthly bill, no egress charge, no renewal.
Priced against the alternatives
Dynamic adjustment keeps storage competitive with centralized providers even as LUME appreciates.
Everlight
Keeps paying operators to hold data after the write is paid for, so permanence is an economic property rather than a company promise.
In full detail
Every fee, split and reward, specified.
Read Protocol Economics → What LUME is for
Ecosystem

Who Lumera connects to, and how.

A logo wall tells you nothing. Each entry below says what the relationship actually is.

Foundation
Cosmos
Cosmos Cosmos SDK · IBC
Lumera is a Cosmos SDK chain. IBC is native, so assets and messages move to any connected zone without a bridge contract.
Wallets
Keplr
Keplr Wallet support
Keplr users can hold and stake LUME with the wallet they already have. No new key material, no separate extension.
Connected chains
Osmosis
Osmosis Cosmos chain · IBC
The DeFi hub of the Cosmos ecosystem. The connection lets LUME holders take part in DeFi without leaving the interchain. IBC-connected.
Injective
Injective Cosmos chain · IBC
A finance-focused chain that needs durable memory for DeFi data, so its users can build trading strategies on a record that is still there later. IBC-connected.
Building on Lumera
Talis
Talis Cosmos chain · IBC
Building on Cascade. Talis stores the documentation behind its real-world asset tokens on Lumera, so provenance stays retrievable and provable long after issuance. IBC-connected.
Midnight
Midnight ZK Layer 1
The Cardano Foundation’s zero-knowledge Layer 1 needed durable memory for its ecosystem builders and uses Lumera to provide it.
Operators
NTT Digital
NTT Digital Institutional validator
An NTT subsidiary running a validator on Lumera mainnet. Institutional operators are what make an active set worth trusting.
Data and coverage
Xangle
Xangle Market data
Korea’s primary crypto data and disclosure platform. Lumera is listed and covered there.
Community
Galxe
Galxe Ecosystem campaigns
Campaign infrastructure used to reach and reward the people who show up early.

Building something on Lumera?

Integrations get listed here with what was built, not just a mark.

Start building → Talk to the team →
Vision

An economy where software can be trusted with real work.

Agents are already doing work that matters. What they lack is everything that makes work accountable: a memory that survives, an identity of their own, evidence of what they did, and a way to be paid for it. Lumera is building all of it on one architecture.

What this makes possible.

Memory is live on mainnet today. The other four are being built on it.

01
Durable memory
Cascade

An agent remembers a customer across every session, every model and every framework it ever runs on, and can prove the record has not changed. Context stops being something you rebuild on each call.

02
An identity it owns
Lumera ID

The agent carries its own passport rather than an account you rent for it. Permissions are explicit, delegation does not mean sharing a secret, and the history follows the agent wherever it works.

03
Work you can check
Proof of Service

Every job leaves evidence of what ran. Another operator can re-derive the result rather than take it on faith, so a disagreement is settled against the record instead of against whoever is larger.

04
Money that moves itself
Global Credits

An agent holds a budget, hires another agent, and pays it when the work checks out. No invoice, no human closing the loop, no counterparty risk on either side.

05
Reputation that is earned
Trust graph

A record of who actually delivered accumulates from paid work. Routing decisions get made against evidence, and a bad history cannot be shed by opening a new account.

Where this ends up

An agent that goes to work without you.

An agent with an identity of its own, a budget you set, a receipt for every step it took, and a reputation it has to earn. You hand it a goal, not a script.

Identity
Owned, not issued
Budget
Set by you, spent by it
Receipts
Every step, checkable
Reputation
Earned, not claimed
Start building → Read the whitepaper