Mainnet live

Store.Verify.Build.

The infrastructure layer for durable memory and decentralized intelligent services.

Building with

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

The foundation beneath intelligent systems.

Modern applications increasingly rely on permanent data, identity, verifiable execution, settlement and trust, yet these capabilities typically come from different vendors. Lumera unifies all five within a single architecture. As software becomes more autonomous, with agents that act, spend and make decisions without human intervention, the need for these capabilities to work together only grows.

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 { createLumeraClient } from "@lumera-protocol/sdk-js"

const client = await createLumeraClient({
  preset: "mainnet", signer, address
})

// hashes the file, registers on chain, stores across supernodes
const task = await client.Cascade.uploader.uploadFile(file, {
  fileName: "report.pdf",
  isPublic: true,
  expirationTime
})
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 are introduced as new operations within the network’s existing execution framework, without creating a second settlement path or parallel identity system.
Principle 04
Authority is graded
A fluent answer is not proof. Irreversible actions remain within your application; the protocol returns signed results and structured plans.
The stack

Memory at the base. Everything else stands on it.

Durable memory shipped first because every other capability depends on it. Hover over each capability to see what supports it 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
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.

05
Trust Graph
No portable reputation
Trust
A record of who actually delivered, earned rather than claimed.
+
Today

Providers are often chosen based on a brand name, a website or a recommendation. Traditional reputation systems record opinions rather than verifiable work, and they can be bought, gamed or abandoned by moving to a new account.

On Lumera

Every job leaves a signed record of who performed it, what was delivered and whether the work was verified. Over time, those records build an evidence-based picture of who delivers, earned rather than claimed and tied to a persistent identity.

WhoWhatVerdictPriceTime

Every connection in the graph represents a completed job. Not a review, not a score someone assigned, but work requested, delivered, checked and paid for.

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.

Durable memory, 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.

What you getRetentionIntegrateFAQ
Durable Memory
Cascade

A memory you can prove.

Written once. Readable from any framework, agent or model. Provably intact decades from now.

An agent that forgets is a demo. Every session starts from scratch. The same context must be sent and paid for again, while anything the agent learned about a customer last week disappears.

What memory does exist usually lives in a database controlled by someone else. It can be deleted, lost during a migration or quietly altered, with no way to prove otherwise.

Lumera stores each fact once, ties it to an identity the agent controls rather than a vendor account, and continuously proves the data is still there and unchanged. Your agent reads and writes through an SDK. No wallet, no gas and no blockchain expertise required.

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 created it, not the application or vendor used to write it. Switch models or frameworks and the memory stays with you.

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 network selects a node and byte range
Each epoch, the protocol challenges nodes to return a specific slice of data, making it impractical to precompute a response.
Response
The node returns the slice and its Merkle proof
The proof traces a hash path from the requested data to the root under which the file was committed, verifying that the node still holds it.
Verdict
The result is recorded onchain
A successful response keeps the node earning. A missed challenge can trigger slashing, and the missing 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
How it worksAnatomyDelegationWhat it enables
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. Every action can be traced to the identity authorized to take it.

Explore the architecture →
How it works today
An agent’s identity is often little more than an API key. Whoever holds the key can act as the agent, with no reliable way to prove which agent performed a specific action. Delegation means sharing the same secret, and revoking it ends access without preserving a durable identity.
How it works on Lumera
The agent holds a persistent identity that exists independently of any application. Permissions are explicit and can be delegated for a limited purpose without sharing secrets. Every action remains attributable because the identity outlives the application, model and session behind 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 grants access. An identity carries a permanent record of what it can do, what it has done and where it has delegated authority.

The key
Controlled by the identity owner, never the protocol. Without it, no one can act as that identity.
Permissions
An explicit record of what the identity is authorized to do.
Delegations
Limited authority granted to another party, with a defined scope and expiration.
History
A durable record of every action the identity has signed, readable long after the session ends.
Anchor
Permanently recorded, so revoking access never erases the past.
Handing over authority
Without sharing a secret
You
Control the identity and define what it may do.
Your application or agent
Receives limited authority for a specific task, budget and period.
Another agent
Can receive a narrower delegation, but never more authority than the agent granting it.
Revoking access
Withdraw a delegation and every permission beneath it ends too. No keys need to be rotated because no secret was shared.
Keeping the history
Revocation prevents future actions without erasing the past. Everything already done remains attributable.

What a real identity makes possible.

01
Delegated authority
Grant a limited 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.
A record worth having
History creates trust only when it is tied to a persistent identity, one that cannot be discarded and recreated without consequence. That continuity makes identity the foundation of the trust graph.
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 →
How it worksAnatomyVerificationWhat it enables
Verifiable Execution
Proof of Service

Answers you can verify, not answers you have to trust.

Every action produces a cryptographic receipt showing what was done, so anyone can independently verify the result rather than take it 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
Every action produces a signed receipt recording what was run and what it returned. Another node can re-run the work using the same inputs, making disagreements detectable instead of subjective. Payment can then be tied to verified work.
Anatomy of a receipt

Enough to verify it, without trusting anyone.

A receipt is more than a log saying the job finished. It records what was used, what was run and what came back, giving another party what it needs to replay the work and compare the result.

Inputs
A fingerprint of the exact inputs, so the original request cannot be quietly changed.
Method
Which operator ran the work and what it ran.
Output
A fingerprint of the result, so any difference is immediately detectable.
Signature
Signed by the identity that performed the work, making the result attributable.
Anchor
Permanently recorded so the receipt cannot be altered and can always be retrieved.
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 →
How it worksAnatomyEscrowWhat it enables
Settlement
Global Credits

Payment that waits for proof.

Protocol-native settlement, escrow and incentives for decentralized services. Applications and agents can hold budgets, pay providers and earn payment for completed work.

Explore the architecture →
How it works today
Payment systems are built around people, cards and company accounts. Agents can transact only through credentials and controls created for human users. Automated work still depends largely on invoices, payment terms and trust between companies.
How it works on Lumera
Funds are locked in escrow when a job is accepted and released only after the work is verified. The provider gets paid, the customer can see exactly what was delivered, and the protocol enforces settlement for both sides.
Anatomy of a payment

Payment moves when the work is verified.

No invoice. No net-30. No uncertainty over who holds the funds while the work is being completed. Each stage is recorded and enforced by the protocol.

Requested
The job, its price and what counts as complete are defined.
Escrowed
The agreed amount is locked onchain when the job is accepted.
Verified
A second operator confirms the work before funds are released.
Released
Payment goes directly to the identity that completed the work.
Recorded
Both sides can see 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 →
How it worksAnatomyTrust graphWhat it enables
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
Providers are often chosen based on a brand name, a website or a recommendation. Traditional reputation systems record opinions rather than verifiable work, and they can be bought, gamed or abandoned by moving to a new account.
How it works on Lumera
Every job leaves a signed record of who performed it, what was delivered and whether the work was verified. Over time, those records build an evidence-based picture of who delivers, earned rather than claimed and tied to a persistent identity.
Anatomy of an edge

Every connection in the graph represents a completed job.

It is not a review or a score assigned by someone else. An edge connects two identities because work was requested, delivered, verified and paid for, with every stage recorded by the protocol.

Who
The identity that performed the work and the identity that paid for it.
What
The work that was requested and the result that was returned.
Verdict
Whether another operator independently verified the result.
Price
The amount placed in escrow and the amount released.
When
The block in which the payment settled, giving the record a fixed place in time.
Why trust adds up

Trust compounds with every verified job.

Each completed job leaves a signed receipt. Together, those receipts create a durable record of who consistently 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 in finance. One universal score cannot tell you the difference.

Earned, not copied

Every edge represents a verified, paid job. Copying the data does not transfer the history to another identity.

Backed by stake

Building a false record requires bonding real LUME against work that can be independently checked. Failed verification can put that stake at risk.

Sharper with use

More jobs improve routing. Better routing attracts better work. Each strengthens the other.

Why a record beats a rating.

01
Earned, not bought
Each edge in the graph represents a job that was completed, verified and paid for. Any identity can also bond LUME against its work. A failed job puts both its stake and its standing at risk.
02
Attached to identity
The record follows the identity across applications and vendors. Starting again means starting without the history that earned trust.
03
Readable by anyone
Applications and agents can make routing decisions using a verifiable record instead of an opaque score or vendor list.
What it is used for
Choosing who does the work
When an agent selects an operator or a platform routes a job, it can consult the record directly instead of relying on a vendor list. Every completed job improves the signal, helping better work find the right provider.
The other graph
The intelligence graph
The trust graph records who delivered. The intelligence graph records what was learned: what was asked, what was found and how the findings connect. Both are built on the same permanent foundation.
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 →
Brand

Brand assets.

The wordmark, symbol, colour values and type that make up Lumera. Take what you need. Use it accurately and in good faith, under the terms further down this page.

Logos
SVG for screen and print. PNG where SVG will not go.
Lumera wordmark, light
Wordmark — light
The default. Use on Navy and on any dark surface.
Lumera wordmark, dark
Wordmark — dark
For light backgrounds, documents and print.
Lumera symbol
Symbol
Square contexts only: avatars, favicons, app icons.
Download the full kit →
Construction
Clear space
Keep space equal to the height of the L on all four sides. Nothing enters it, including other logos, type and page edges.
Minimum size
Below this the letterforms break down. Wordmark: 96px on screen, 25mm in print. Symbol: 24px.
96px
24px
Colour
Click any swatch to copy its hex.

Green is a fill colour. As small text on a light background it does not carry enough contrast, so use Teal there instead.

Typeface
Geist
Everything else
The intelligence layer
Get it →
Geist Mono
Technical labels
Proof of service
Get it →
Using the marks

Good faith, plainly stated.

You do not need to ask permission to refer to Lumera accurately. You do need to be straight about what your relationship with the project actually is.

Go ahead
  • + Writing about, reporting on or reviewing Lumera
  • + Linking to lumera.io or the documentation
  • + Saying “built on Lumera” or “supports Lumera” where that is true
  • + Talks, tutorials, community content and educational material
  • + Showing the mark alongside others in an ecosystem or partner list
Do not
  • Suggest a partnership, endorsement or affiliation that does not exist
  • Attach the marks to fraud, phishing, impersonation or an unauthorised token sale
  • Present a fork, clone or unrelated product as Lumera
  • Recolour, stretch, rotate, outline or otherwise alter the artwork
  • Put the marks in your company name, product name, domain or app listing
Terms
01
Use them in good faith

Refer to Lumera as it is. Do not use the marks in a way that misleads people about who made something, who stands behind it, or what it does.

02
No implied endorsement

Using the marks does not make you a partner. Do not present your project as endorsed, certified, audited or affiliated unless we have agreed that in writing.

03
Nothing harmful or deceptive

The marks may not appear in connection with fraud, scams, phishing, malware, impersonation of Lumera or its team, unauthorised token sales, or any unlawful activity.

04
Do not modify the artwork

Use the files as supplied. No recolouring, distortion, rotation, effects, or combining the marks with other logos, words or shapes to form something new.

05
Not part of your own identity

The marks stay ours. Do not register them, or anything confusingly similar, as a trademark, company name, domain, social handle or app-store listing.

06
Permission can be withdrawn

This is a limited, revocable licence to use the marks under these terms. If we ask you to stop or to change how you are using them, please do.

Not sure
Ask first.
If your use is not clearly covered above, send us what you have in mind. It is a short conversation.
brand@lumera.io →
Press
Coverage and interviews.
Media enquiries, background on the protocol, and where Lumera has appeared.
Go to press →
Blog

What we shipped, and why.

Follow on X → RSSSee all posts →
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 power the network.

Validators secure the chain. SuperNodes deliver its services. The roles are separate by design, so consensus never depends on service delivery.

Consensus layer
Validators
50
in the active set

Their job is consensus: agreeing on what happened and in what order.

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 perform the network’s services. The chain records the commitments, proofs and results.

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 records what happened.

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.
MetaMask
MetaMask EVM support
Leading self-custodial crypto wallet, trusted by millions. Now supports LUME directly, since Lumera is fully EVM-compatible.
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.
Luganodes Validator
Swiss-based institutional-grade staking provider and global leader in staking volume, supporting 50+ PoS networks with $3bn+ under management, now running a validator on Lumera mainnet.
Nansen Validator
On-chain analytics leader known for wallet labeling and smart money tracking, now running a validator on Lumera mainnet.
Allnodes Validator
Top-ranked non-custodial node hosting and staking platform with a AAA rating on Staking Rewards, now running a validator on Lumera mainnet.
Citadel.One Validator
Multi-chain staking platform and wallet, verified Staking Rewards provider running active validator nodes across dozens of networks, now securing Lumera mainnet.
Kingnodes Validator
Australian-owned blockchain infrastructure provider delivering secure, high-performance validator and RPC services since 2020, now running a validator on Lumera mainnet.
Silk Nodes Validator
Premier blockchain infrastructure provider known for one of the most decentralized validator operations in the space, now securing Lumera mainnet.
Nodes.Guru Validator
Trusted validator operator known for high-performance infrastructure and robust security, running nodes across LayerZero, Sui, Aptos, Solana, Celestia and more, now on Lumera mainnet.
Data Nexus Validator
Blockchain data infrastructure provider (est. 2022) running validator and staking services across Polygon, BandChain, and other networks, now securing Lumera mainnet.
Polkachu Validator
Long-standing Cosmos ecosystem validator with an experienced team running nodes on 100+ blockchains, known for deep community trust and reliable infrastructure, now on Lumera mainnet.
SCV Security Validator
Trusted Cosmos and CosmWasm security auditor operating validators across the Cosmos ecosystem, including Injective and Xion, now securing Lumera mainnet.
Professional validator running infrastructure across 20+ Cosmos SDK-based networks, offering relayer services, statesync servers, and RPC/API access, now on Lumera mainnet.
US-based professional proof-of-stake validator securing 16+ Cosmos ecosystem chains with 99.9% uptime and DDoS protection, now running a validator on Lumera mainnet.
Rhino Validator
Enterprise Web3 infrastructure provider with 99.9% uptime, a genesis node operator for Aptos and top-5%-performing Lido operator, now securing Lumera mainnet.
Ubik Capital Validator
Proof-of-stake validator and investor with years of industry experience securing major networks like Solana, Cosmos Hub, and Cronos, now running a validator on Lumera mainnet.
BlockHunters Validator
Leading non-custodial staking infrastructure provider running nodes, relayers, and custom tools across the Cosmos ecosystem, now securing Lumera mainnet.
Decentrio Validator
Cosmos protocol engineering and validator services team already running a validator for Lumera, spanning software development, infrastructure, and auditing.
Nodeify Validator
Established validator operator active across Cosmos Hub, Osmosis, and Akash, now running a validator on Lumera mainnet.
Crosnest Validator
Key validator and IBC relayer on networks like dYdX and Provenance, helping secure token transfers across chains, now on Lumera mainnet.
AutoStake Validator
Zero-fee validator known for slash protection and reliable staking rewards across multiple PoS networks, now securing Lumera mainnet.
Forbole Validator
Well-established professional blockchain validator with 4+ years in the staking business, active across the Cosmos ecosystem, now running a validator on Lumera mainnet.
Staker House Validator
World-class staking infrastructure provider offering reliable, secure node operator and validator services across multiple PoS networks, now on Lumera mainnet.
NodeStake Validator
Professional validator, infrastructure provider, and IBC relayer active across Evmos, Uptick, and other Cosmos ecosystem chains, now securing Lumera mainnet.
Helios Validator
One of the largest and earliest validators supporting emerging PoS networks, now running a validator on Lumera mainnet.
AstroStake Validator
Community-driven validator and infrastructure provider known for dependable, enterprise-grade reliability, now running a validator on Lumera mainnet.
Data and coverage
Xangle
Xangle Market data
Korea’s primary crypto data and disclosure platform. Lumera is listed and covered there.
Community
Snag
Snag Ecosystem campaigns
Campaign infrastructure used to reach and reward the people who show up early.
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