Lighthouse Journal

Build a Second Brain for Your Company with Lighthouse Memory

N
Nandit Mehra
September 26, 2026
schedule8 min read
Build a Second Brain for Your Company with Lighthouse Memory

Every company already has a second brain. It is spread across Slack threads, meeting notes, onboarding docs and the heads of people who might leave next quarter. The job is to make it something agents can actually use.

"Second brain" started as a personal productivity idea: capture what you learn so you do not have to keep it in your head. For a company, the stakes are higher. Decisions get made and forgotten. The reason a customer is on a special plan lives in one person's memory. New hires and new AI agents both start from zero.

A company second brain is a shared, durable memory that people and agents both read from and write to. This post shows how to build one on Lighthouse Memory, and why the memory layer matters as much as the model on top.

What a Company Second Brain Needs

RequirementWhyLighthouse Memory feature
Recall by meaning, not keywordsNobody remembers the exact wordingHybrid semantic plus keyword recall
Structure without a schema projectKnowledge is messyTags, metadata, and fact extraction with analyze()
Boundaries between teamsSales notes are not for everyoneNamespaces
Survives people and tools leavingKnowledge must outlast vendorsContent addressed blobs on Filecoin, Walrus or your S3
Proof of what was knownDecisions get questioned laterCIDs on every record, snapshots as checkpoints
Works with every AI toolTeams use different assistantsMCP server plus SDK
Private where neededHR and finance dataSEAL-encrypted memwal engine

memory-05-diagram.png

Step 1: Design Namespaces Around Access, Not Org Charts

A namespace isolates memories per agent or project. Snapshots and pointers are namespace checked, so memory never leaks across namespaces by accident. Design them around who should read what.

NamespaceContentsEngine
company-sharedMission, product facts, policies, glossaryBatched on Filecoin
eng-decisionsArchitecture decisions, incident learnings, runbooksBatched on Filecoin
sales-accountsCustomer context, commitments, renewal notesMemwal (encrypted)
people-opsLeave, preferences, onboarding statusMemwal (encrypted)

Anything involving personal or commercially sensitive information goes on the memwal engine, where every memory is SEAL-encrypted on Walrus. The batched engine stores plaintext blobs today, so it is the right home for knowledge you would be comfortable publishing internally. See Encrypted Memory for AI Agents with Memwal and SEAL.

Step 2: Build a Tag Vocabulary Before You Ingest Anything

Tags are not decoration. They are a second retrieval axis. recall(query, { tags }) restricts results to memories carrying at least one of those tags, and in the batched engine each tag that appears in the query adds 0.5 to the keyword score.

The docs recommend a small, consistent lowercase vocabulary shared across agents. For a company, start with around a dozen:

decision  policy  customer  pricing  incident  runbook
product   roadmap  onboarding  preference  owner  deadline

Agree on it once. Every agent and integration uses the same list.

Step 3: Ingest Knowledge as Discrete Facts

Paragraphs make poor memories. A meeting note contains five facts, and you want each one recallable on its own. The memwal engine's analyze() does this: give it free text and the relayer extracts discrete facts, storing each as its own memory with its own CID, tagged analyzed.

import { MemwalMemory } from '@lighthouse-ai/engine-memwal'

const sales = await MemwalMemory.fromEnv() // MEMWAL_NAMESPACE=sales-accounts

await sales.analyze(
  `Call with ACME, Oct 2. They are moving 40 seats to the enterprise plan in January.
   Their security team requires SSO before rollout. Champion is Dana, VP Ops.`,
  { occurredAt: '2026-10-02T15:00:00.000Z' }
)
// { factCount: 3, succeeded: 3, failed: 0, memories: [ … ] }

For knowledge that belongs on the batched engine, write facts directly with tags and metadata that point back to the source:

await eng.remember('Payments service moved from Postgres 14 to 16 on Sep 30; rollback plan is in RB-112.', {
  tags: ['decision', 'runbook'],
  metadata: { source: 'adr-0042', owner: 'platform-team' },
})

Step 4: Let Every Assistant and Agent Use It

A second brain nobody queries is an archive. Connect it where people already work.

Recall works by meaning. The docs' own example: the question "which hosting platform is used for releases?" finds "deploys to Vercel on the main branch" with zero shared keywords.

const answer = await companyShared.recall('what is our refund window for annual plans?', {
  tags: ['policy'],
  limit: 3,
})

Step 5: Keep It Honest Over Time

A second brain decays. Policies change and old facts linger. Three habits keep it trustworthy.

Supersede, do not overwrite. Write the new fact with a tag like decision and metadata supersedes: <old id>, then forget() the old one. The history remains visible in earlier snapshots.

Checkpoint regularly. snapshotIndex() produces one CID for an entire namespace. Keep a monthly checkpoint and you can answer "what did we believe in March?" by loading that CID into a clean engine with rebuildLocal(cid).

Watch status(). The batched engine reports pendingMemories, embeddings and lastSnapshotCid. The memwal engine reports pendingPins and relayer health. How to Audit and Monitor AI Agents with Verifiable Memory covers the alerting.

Why Not Just Use a Wiki or a Vector Database

WikiHosted vector DBLighthouse Memory
Recall by meaningNoYesYes
Usable by any AI toolVia custom integrationsVia custom integrationsMCP plus SDK
Tamper evident recordsNoNoCIDs on every record
Portable if you switch vendorsExportExport and re-embedContent addressed blobs, restore from a snapshot CID
Encryption for sensitive areasAccess control onlyVariesSEAL-encrypted memwal engine
Bring your own bucketNoNoS3, R2 and MinIO adapters

The last row matters to enterprises. The batched engine stores memory in your own S3, R2 or MinIO bucket if you prefer, with the same API. See Composable Memory for AI Agents on S3 R2 and Open Source Models.

Frequently Asked Questions

What is a company second brain? A shared, durable memory of company knowledge, including decisions, policies, customer context and runbooks, that both people and AI agents can read from and write to.

How is it different from a knowledge base? A knowledge base stores documents. A second brain for agents stores discrete, recallable facts with tags and provenance, retrieved by meaning at the moment an agent needs them.

How do I keep sensitive knowledge separate? Use separate namespaces, and put sensitive namespaces on the memwal engine, which SEAL-encrypts every memory.

Can I store the company memory in our own cloud? Yes. The batched engine supports S3, Cloudflare R2 and MinIO with the same API.

How do I load existing documents? Use analyze() on the memwal engine to extract discrete facts from notes, transcripts and docs, or write facts directly with remember().

Get Started

Planning a rollout across teams? Talk to our team.

Stay in Touch

Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

Read More Articles

Build a Second Brain for Your Company with Lighthouse Memory
Articlecalendar_todaySep 26, 2026

Build a Second Brain for Your Company with Lighthouse Memory

Every company already has a second brain. It is spread across Slack threads, meeting notes, onboarding docs and the heads of people who might leave next quarter. The job is to make it something agents can actually use. "Second brain" started as a personal productivity idea: capture what you learn so you do not have to keep it in your head. For a company, the stakes are higher. Decisions get made and forgotten. The reason a customer is on a special plan lives in one person's memory. New hires and new AI agents both start from zero. A company second brain is a shared, durable memory that people and agents both read from and write to. This post shows how to build one on Lighthouse Memory, and why the memory layer matters as much as the model on top. --- What a Company Second Brain Needs | Requirement | Why | Lighthouse Memory feature | |---|---|---| | Recall by meaning, not keywords | Nobody remembers the exact wording | Hybrid semantic plus keyword recall | | Structure without a schema project | Knowledge is messy | Tags, metadata, and fact extraction with analyze() | | Boundaries between teams | Sales notes are not for everyone | Namespaces | | Survives people and tools leaving | Knowledge must outlast vendors | Content addressed blobs on Filecoin, Walrus or your S3 | | Proof of what was known | Decisions get questioned later | CIDs on every record, snapshots as checkpoints | | Works with every AI tool | Teams use different assistants | MCP server plus SDK | | Private where needed | HR and finance data | SEAL-encrypted memwal engine | !memory-05-diagram.png --- Step 1: Design Namespaces Around Access, Not Org Charts A namespace isolates memories per agent or project. Snapshots and pointers are namespace checked, so memory never leaks across namespaces by accident. Design them around who should read what. | Namespace | Contents | Engine | |---|---|---| | company-shared | Mission, product facts, policies, glossary | Batched on Filecoin | | eng-decisions | Architecture decisions, incident learnings, runbooks | Batched on Filecoin | | sales-accounts | Customer context, commitments, renewal notes | Memwal (encrypted) | | people-ops | Leave, preferences, onboarding status | Memwal (encrypted) | Anything involving personal or commercially sensitive information goes on the memwal engine, where every memory is SEAL-encrypted on Walrus. The batched engine stores plaintext blobs today, so it is the right home for knowledge you would be comfortable publishing internally. See Encrypted Memory for AI Agents with Memwal and SEAL. --- Step 2: Build a Tag Vocabulary Before You Ingest Anything Tags are not decoration. They are a second retrieval axis. recall(query, { tags }) restricts results to memories carrying at least one of those tags, and in the batched engine each tag that appears in the query adds 0.5 to the keyword score. The docs recommend a small, consistent lowercase vocabulary shared across agents. For a company, start with around a dozen: text decision policy customer pricing incident runbook product roadmap onboarding preference owner deadline Agree on it once. Every agent and integration uses the same list. --- Step 3: Ingest Knowledge as Discrete Facts Paragraphs make poor memories. A meeting note contains five facts, and you want each one recallable on its own. The memwal engine's analyze() does this: give it free text and the relayer extracts discrete facts, storing each as its own memory with its own CID, tagged analyzed. javascript import { MemwalMemory } from '@lighthouse-ai/engine-memwal' const sales = await MemwalMemory.fromEnv() // MEMWALNAMESPACE=sales-accounts await sales.analyze( Call with ACME, Oct 2. They are moving 40 seats to the enterprise plan in January. Their security team requires SSO before rollout. Champion is Dana, VP Ops., { occurredAt: '2026-10-02T15:00:00.000Z' } ) // { factCount: 3, succeeded: 3, failed: 0, memories: [ … ] } For knowledge that belongs on the batched engine, write facts directly with tags and metadata that point back to the source: javascript await eng.remember('Payments service moved from Postgres 14 to 16 on Sep 30; rollback plan is in RB-112.', { tags: ['decision', 'runbook'], metadata: { source: 'adr-0042', owner: 'platform-team' }, }) --- Step 4: Let Every Assistant and Agent Use It A second brain nobody queries is an archive. Connect it where people already work. - Assistants such as Claude Code and Claude Desktop connect through the hosted MCP server and get memoryrecall and memoryremember as tools. See Give Claude Code Persistent Memory with Lighthouse MCP. - Internal agents such as a support bot, an onboarding buddy or a sales prep agent use the SDK and recall before they answer. - Different models read the same memory, so a team on Claude and a team on an open source model share one brain. See One Memory Layer Shared Across Every AI Model. Recall works by meaning. The docs' own example: the question "which hosting platform is used for releases?" finds "deploys to Vercel on the main branch" with zero shared keywords. javascript const answer = await companyShared.recall('what is our refund window for annual plans?', { tags: ['policy'], limit: 3, }) --- Step 5: Keep It Honest Over Time A second brain decays. Policies change and old facts linger. Three habits keep it trustworthy. Supersede, do not overwrite. Write the new fact with a tag like decision and metadata supersedes: <old id, then forget() the old one. The history remains visible in earlier snapshots. Checkpoint regularly. snapshotIndex() produces one CID for an entire namespace. Keep a monthly checkpoint and you can answer "what did we believe in March?" by loading that CID into a clean engine with rebuildLocal(cid). Watch status(). The batched engine reports pendingMemories, embeddings and lastSnapshotCid. The memwal engine reports pendingPins and relayer health. How to Audit and Monitor AI Agents with Verifiable Memory covers the alerting. --- Why Not Just Use a Wiki or a Vector Database | | Wiki | Hosted vector DB | Lighthouse Memory | |---|---|---|---| | Recall by meaning | No | Yes | Yes | | Usable by any AI tool | Via custom integrations | Via custom integrations | MCP plus SDK | | Tamper evident records | No | No | CIDs on every record | | Portable if you switch vendors | Export | Export and re-embed | Content addressed blobs, restore from a snapshot CID | | Encryption for sensitive areas | Access control only | Varies | SEAL-encrypted memwal engine | | Bring your own bucket | No | No | S3, R2 and MinIO adapters | The last row matters to enterprises. The batched engine stores memory in your own S3, R2 or MinIO bucket if you prefer, with the same API. See Composable Memory for AI Agents on S3 R2 and Open Source Models. --- Frequently Asked Questions What is a company second brain? A shared, durable memory of company knowledge, including decisions, policies, customer context and runbooks, that both people and AI agents can read from and write to. How is it different from a knowledge base? A knowledge base stores documents. A second brain for agents stores discrete, recallable facts with tags and provenance, retrieved by meaning at the moment an agent needs them. How do I keep sensitive knowledge separate? Use separate namespaces, and put sensitive namespaces on the memwal engine, which SEAL-encrypts every memory. Can I store the company memory in our own cloud? Yes. The batched engine supports S3, Cloudflare R2 and MinIO with the same API. How do I load existing documents? Use analyze() on the memwal engine to extract discrete facts from notes, transcripts and docs, or write facts directly with remember(). --- Get Started - Lighthouse Memory introduction - Store memories - Recall memories - Encrypted memory with memwal Planning a rollout across teams? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
One Memory Layer Shared Across Every AI Model
Articlecalendar_todaySep 26, 2026

One Memory Layer Shared Across Every AI Model

Every AI tool you use has its own memory, and none of them talk to each other. Switch from one model to another and you start over. A shared memory layer fixes that. Most people now use several AI systems in a week: one for code, one for writing, one for research, a custom agent at work. Each keeps its own private notion of who you are and what you are working on. Your project brief lives in one chat history. Your preferences live in another. Decisions made in a Claude session are invisible to the agent you run on Llama. The Lighthouse homepage frames the fix in four words: different minds, shared memory. This post explains how that works technically, and how to connect any model to the same memory. --- Why Built In Memory Does Not Travel Built in memory features are tied to one vendor's product. That creates three problems. | Problem | What it looks like | |---|---| | Lock in | Months of context you cannot take to another model | | Fragmentation | Each tool knows a different, partial version of you or your project | | No proof | You cannot check what a tool remembered, or whether it changed | A memory layer that lives outside any single model solves all three. The context is yours, every model reads the same record, and every record has a CID you can verify. !memory-04-diagram.png --- How Lighthouse Memory Connects Different Models There are two ways in, and they reach the same memory. 1. MCP for assistants and agent runtimes Lighthouse runs a hosted Model Context Protocol server at https://memory-api.lighthouse.storage/mcp. It is Streamable HTTP and stateless, and it exposes memory as tools: memoryremember, memoryrecall, memorylist, memoryget, memoryforget, memorystatus, plus snapshot tools. Any MCP capable client can use them, including Claude Code and Claude Desktop, and the server publishes OAuth protected resource metadata at /.well-known/oauth-protected-resource for client discovery. Client configuration is a few lines: json { "mcpServers": { "lighthouse-memory": { "type": "http", "url": "https://memory-api.lighthouse.storage/mcp", "headers": { "Authorization": "Bearer <SESSIONJWT" } } } } Once connected, the experience looks like this, straight from the docs: You: remember that our staging environment is at staging.acme.dev and redeploys on every merge to develop Agent: (calls memoryremember) Saved. days later, new session You: where do I check the latest staging build? Agent: (calls memoryrecall) Your staging environment is at staging.acme.dev. Now do the second half in a different client. Because the memory lives in Lighthouse, not in the client, the answer is the same. A step by step setup for Claude Code is in Give Claude Code Persistent Memory with Lighthouse MCP. 2. The SDK for custom agents on any model For agents you build yourself, on OpenAI, Anthropic, Llama, Qwen, Mistral or anything else, use the TypeScript SDK directly. The memory layer does not care which model generates the text. javascript import '@lighthouse-ai/store-lighthouse' import '@lighthouse-ai/embed-local' import { createStorage, createEmbedder } from '@lighthouse-ai/core' import { BatchedEngine } from '@lighthouse-ai/engine-batched' const memory = new BatchedEngine( await createStorage('lh-ipfs-filecoin', { apiKey: process.env.LIGHTHOUSEAPIKEY }), { namespace: 'launch-project', agent: 'writer-llama', embedder: await createEmbedder('local') } ) // Any model, same memory const context = await memory.recall('brand voice and launch date', { limit: 5 }) const prompt = Context:\n${context.map((m) = - ${m.content}).join('\n')}\n\nWrite the launch email. const draft = await yourModel.generate(prompt) // OpenAI, Claude, Llama via Ollama, anything Recall ranking in the batched engine runs on an open source embedding model, all-MiniLM-L6-v2, in process. No embedding API is involved, so shared memory does not tie you to any model vendor even at the retrieval step. --- Sharing Across Agents Without Sharing Everything Shared does not mean everything goes everywhere. The homepage example is a good one: share the project brief with your writing agent, share brand guidelines with your design agent, keep personal notes private. Lighthouse Memory gives you three tools for scoping. | Tool | How it scopes | Use it for | |---|---|---| | Namespace | Hard isolation; memories, snapshots and pointers are per namespace | Separate projects, teams, or private versus shared memory | | Tags | recall(query, { tags }) returns only memories carrying those tags | Topic scoping inside a namespace | | Snapshot CIDs | snapshotIndex() gives one CID for a whole namespace | Handing a complete context to another agent or machine | A practical layout for a small team: text namespace: launch-shared - brief, decisions, brand voice (all agents) namespace: design-shared - guidelines, asset decisions (design agent) namespace: my-private - personal notes (only you) With the SDK, each agent is constructed only with the namespaces it should see. A new agent joining the project loads the shared namespace from a snapshot CID and is up to speed in one call: javascript await newAgentMemory.rebuildLocal(snapshotCid) // { added: 214, total: 214 } --- Why Verifiability Matters for Shared Memory When two agents share memory, a new failure mode appears: they may not actually be looking at the same thing. One has a stale copy, or a record changed between reads. Content addressing removes that ambiguity. Every flushed memory carries the CID of the blob it lives in, and the same content always produces the same CID. If two agents cite the same CID, they have the same bytes. If the CIDs differ, something changed, and you can see exactly where. What Is Verifiable Memory for AI Agents goes deeper. --- Moving Between Devices, Not Just Models Shared memory also has to follow you across machines. The pointer service in @lighthouse-ai/cloud-sync tracks the latest snapshot CID per namespace and network, so a fresh laptop restores your memory without anyone copying a CID by hand. Recover Agent Memory on Any Machine with Snapshots and Pointers walks through it. --- Frequently Asked Questions Can ChatGPT, Claude and other models share the same memory? Yes, when memory lives outside the model. Lighthouse Memory exposes one memory layer over MCP for MCP capable clients and over a TypeScript SDK for custom agents on any model. What is an MCP memory server? A Model Context Protocol server that exposes memory as tools an AI client can call. Lighthouse hosts one at memory-api.lighthouse.storage/mcp. Do I need a specific model or embedding API? No. The batched engine ranks recall with an open source MiniLM model running locally, and the memory layer works with any model that produces text. How do I keep some memories private from other agents? Put them in a separate namespace. Namespaces isolate memories, snapshots and pointers. How does a new agent get existing context? Load a snapshot CID with rebuildLocal(cid), or restore the latest snapshot automatically through the pointer service. --- Get Started - MCP overview - MCP tools for both engines - SDK overview - Cross device backup tutorial --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Encrypted Memory for AI Agents with Memwal and SEAL
Articlecalendar_todaySep 26, 2026

Encrypted Memory for AI Agents with Memwal and SEAL

Agents remember the things people tell them. Some of those things are private. Encrypted memory means the storage network holds your agent's memories without being able to read them. A customer's account details. An employee's performance notes. A company's pricing strategy. The moment an agent is useful, its memory contains something sensitive. Decentralized storage makes memory durable and verifiable, but durable and verifiable are not the same as private. Anything stored in plaintext on a public network can be read by anyone who finds its identifier. Lighthouse Memory offers encrypted memory through its memwal engine, where every memory is SEAL-encrypted before it reaches Walrus. This post explains how it works, exactly what is and is not encrypted, and when to choose it. --- Two Engines, Two Privacy Models Lighthouse Memory has two engines behind the same remember, recall and forget interface. | | Batched engine | Memwal engine | |---|---|---| | Who embeds | You, locally (MiniLM) | The relayer | | Where search runs | Locally, over your index | In the relayer, over encrypted blobs | | Encryption at rest | Not yet; native encryption is under development | SEAL-encrypted on Walrus | | Writes | Buffered, then flushed as one blob | Direct, every remember goes to the network | | Storage choice | Filecoin, Walrus, S3, R2, MinIO, local disk | Walrus, owned by the relayer | | Needs | A storage and an embedder | MEMWALPRIVATEKEY and MEMWALACCOUNTID | If you need memory encrypted by default with no extra code, memwal is the engine. If you need full control over where bytes live, the batched engine is the one, with your own encryption layered on top until native encryption ships. !Encrypted memory flow with the memwal engine --- How the Memwal Engine Works The memwal engine is a full engine, not just a storage adapter. On every remember, the relayer: 1. Embeds the memory for vector search. 2. SEAL-encrypts it. 3. Uploads the encrypted blob to Walrus. 4. Adds it to a vector index so it can be recalled by meaning. Your machine keeps a local index of tags, CIDs and blob IDs. There is no batching and no flush(): every write is on the network when remember returns, so there is no pending queue to lose if the process dies. Setup Get credentials from the dashboard at memory.walrus.xyz for mainnet, or staging.memory.walrus.xyz for testnet. Credentials are per network, so testnet keys do not work on mainnet. bash npm install @lighthouse-ai/engine-memwal dotenv bash .env MEMWALPRIVATEKEY=<hex-delegate-key MEMWALACCOUNTID=0x... MEMWALNETWORK=testnet start here, then mainnet MEMWALNAMESPACE=hr-assistant MEMWALIPFSPIN=off no public mirrors for sensitive memory (see below) javascript import 'dotenv/config' import { MemwalMemory } from '@lighthouse-ai/engine-memwal' const memory = await MemwalMemory.fromEnv() const stored = await memory.remember('Priya prefers async standups and is on leave Oct 14 to 18.', { tags: ['team', 'preference'], }) // { id, blobId, cid, pinned, walrusUrl, network, namespace } const hits = await memory.recall('who is out mid October?', { limit: 5 }) // [{ blobId, content, distance, score, tags, indexed, … }] blobId is the SEAL-encrypted Walrus blob. score is 1 − distance, clamped to 0 to 1. You can pass maxDistance to drop weak matches. --- Exactly What Is Encrypted, and What Is Not This is the part most vendors blur. Here it is plainly, from the docs. | Artifact | Encrypted? | Who can read it | |---|---|---| | Memwal blob on Walrus | Yes, SEAL-encrypted | Only through your credentials | | IPFS mirror of each record (when pinning is on) | No, plaintext | Anyone with the CID | | Index snapshot from snapshotIndex() | No, plaintext | Anyone with the CID | | Local index in .memory-sdk/memwal/ | No, it sits on your disk | Anyone with your disk | | Batched engine blobs and snapshots | No, plaintext | Anyone with the CID | | Your saved Lighthouse API key (BYOK) | Stored encrypted, only last4 returned | The backend | The key setting is MEMWALIPFSPIN. By default, if a LIGHTHOUSEAPIKEY is present, the SDK pins a public, plaintext IPFS mirror of each record so it gets a publicly resolvable CID. That is useful for verification and sharing. It is wrong for sensitive memory. Set MEMWALIPFSPIN=off and the SDK computes CIDs locally without publishing a mirror. The same logic applies to snapshots. snapshotIndex() is how you move memory between machines, but the snapshot is plaintext. For sensitive namespaces, skip snapshots and lean on the relayer instead: recall() works from any machine with your credentials, even without a local record (those results come back as indexed: false), and restore() repairs the relayer's vector index from onchain data. --- Encrypted Memory Features You Get With Memwal Fact extraction with analyze(). Give it free text and the relayer extracts discrete facts, storing each as its own encrypted memory tagged analyzed. javascript await memory.analyze('Alice moved to Lisbon in June and prefers dark mode.', { occurredAt: '2026-06-15T00:00:00.000Z', }) // { factCount: 2, succeeded: 2, failed: 0, memories: [ … ] } Integrity checks with verify(). Pinned records are fetched and compared byte for byte; unpinned records are re-hashed locally. See What Is Verifiable Memory for AI Agents. Recovery with restore(). If recall seems to miss older memories, ask the relayer to rebuild missing vector index entries from onchain data: await memory.restore({ maxBlobs: 200 }). Walrus native IDs with blobIds(). Returns the encrypted memwal blob ID for Sui ecosystem tooling. --- forget() on Encrypted Memory Deletion semantics matter more for private data, so be precise. On memwal, forget() removes the local copy and unpins the IPFS mirror. The relayer has no delete API. The encrypted blob stays on Walrus until its storage period lapses and may still appear in recall results as indexed: false. Because the blob is encrypted, the practical exposure is small. But if your obligations require immediate hard deletion, use the batched engine on S3 or local disk, where forget() is a real delete, and encrypt content before it is stored. --- Using the Batched Engine With Your Own Encryption If you need the batched engine's storage flexibility today, encrypt before remember and keep the searchable parts in tags you are comfortable exposing. javascript import { encrypt } from './crypto.js' // your AES-GCM helper, key from your KMS await memory.remember(await encrypt('Contract value is 1.2M, renewal Jan 2027.'), { tags: ['contract', 'acme'], // tags stay plaintext: keep them non-sensitive metadata: { enc: 'aes-256-gcm', keyId: 'kms/contracts-2026' }, }) The tradeoff is clear: encrypted content cannot be semantically searched by the local embedder, so recall relies on tags. That is why memwal, which searches server side over encrypted blobs, is the better default for sensitive memory. --- When to Choose Encrypted Memory - HR, legal and finance assistants holding personal or confidential information. - Customer support agents that remember account details across tickets. - Company second brains where some knowledge is restricted. See Build a Second Brain for Your Company with Lighthouse Memory. - Trading agents whose strategy memory is commercially sensitive. --- Frequently Asked Questions Is Lighthouse Memory encrypted? The memwal engine SEAL-encrypts every memory on Walrus. The batched engine stores plaintext blobs today; native encryption is under development, so encrypt sensitive content yourself or use memwal. What is SEAL encryption? SEAL is the encryption and access control system from the Sui ecosystem. The memwal relayer applies it to each memory before uploading to Walrus, so storage nodes hold only ciphertext. Can encrypted memories still be searched? Yes, with memwal. The relayer runs vector search over encrypted blobs and returns matches with scores. Are IPFS mirrors encrypted? No. Pinned mirrors and snapshots are plaintext. Set MEMWALIPFSPIN=off for sensitive namespaces. Can I permanently delete an encrypted memory? forget() removes the local copy and mirror immediately. The encrypted Walrus blob lapses when its storage period ends. --- Get Started - Encrypted memory with memwal, full tutorial - Memwal engine reference - Memwal MCP tools - Configuration and env vars --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
How to Audit and Monitor AI Agents with Verifiable Memory
Articlecalendar_todaySep 26, 2026

How to Audit and Monitor AI Agents with Verifiable Memory

When an autonomous agent does something unexpected, the first question is always the same: what did it know when it did that? Most teams cannot answer it. Logs tell you what an agent did. They rarely tell you what it remembered, and they almost never prove that the record has not been edited since. As agents take on work with real consequences, that gap becomes the difference between an agent you can deploy and an agent you can defend. This guide shows how to make agents auditable and observable with Lighthouse Memory: decision records with CIDs, checkpoints you can replay, and health signals you can alert on. --- Three Questions Every Agent Audit Asks | Question | What you need | Lighthouse Memory primitive | |---|---|---| | What did the agent know? | The memories it recalled at decision time | recall() results carry id, cid, score, tags | | Has the record been changed? | Tamper evidence | Content addressed CIDs (CIDv1, raw, sha2-256) | | What did its whole memory look like at a point in time? | A checkpoint of the full index | snapshotIndex() returns one CID for everything | Plus one operational question: is the agent healthy right now? That is what status() is for. !memory-02-diagram.png --- Step 1: Give Every Agent an Identity and a Namespace Two fields make audit possible later, and they cost nothing to set now. - namespace isolates memories per agent or project. Snapshots are namespace checked, so a snapshot from one agent will not load into another. - agent is recorded on every memory. When several agents share infrastructure, this is how you attribute a record. javascript import '@lighthouse-ai/store-lighthouse' import '@lighthouse-ai/embed-local' import { createStorage, createEmbedder } from '@lighthouse-ai/core' import { BatchedEngine } from '@lighthouse-ai/engine-batched' const storage = await createStorage('lh-ipfs-filecoin', { apiKey: process.env.LIGHTHOUSEAPIKEY }) const memory = new BatchedEngine(storage, { namespace: 'claims-agent-prod', agent: 'claims-agent@v3.2', embedder: await createEmbedder('local'), flushEvery: 1, // audit-critical: upload on every write }) Note flushEvery: 1. By default the batched engine buffers 10 memories before uploading, and pending memories live only on the local machine until flushed. For audit logs, that window matters. Setting flushEvery to 1 uploads every write immediately, at the cost of more requests. On Filecoin, quota tracks real bytes, so this is affordable. --- Step 2: Record Decisions as Memories, With Their Inputs The audit pattern is simple: before the agent acts, it recalls the context it will rely on, then remembers a decision record that references those memories by ID and CID. javascript async function decide(task) { // 1. What the agent knows, with provenance const context = await memory.recall(task.question, { tags: ['policy', 'customer'], limit: 5 }) const decision = await task.model.decide(task, context) // 2. The decision record, linked to the exact memories it used const record = await memory.remember( Decision on claim ${task.claimId}: ${decision.outcome}. Reason: ${decision.reason}, { tags: ['decision', 'claims'], metadata: { claimId: task.claimId, model: task.model.id, usedMemories: context.map((m) = ({ id: m.id, cid: m.cid, score: m.score })), }, } ) return { decision, recordId: record.id, recordCid: record.cid } } Every recall() result returns its ranking breakdown, score, semanticScore and keywordScore, so an auditor can also see why a memory was retrieved, not just that it was. With the default local embedder, score = 0.7 × cosine + 0.3 × min(1, keywordScore). --- Step 3: Checkpoint the Whole Memory With Snapshots Individual records answer "what did it decide." Snapshots answer "what did its memory look like on March 3rd." javascript const snap = await memory.snapshotIndex() // { cid: 'baf…', entries: 1284, gatewayUrl: 'https://…' } snapshotIndex() pins the entire local index, including pending memories, as one mem-index.<namespace.json blob. That single CID is a complete, tamper evident checkpoint. Take one on a schedule, before deployments, and after incidents. To investigate later, load a checkpoint into a clean engine and query it as it was: javascript const replay = new BatchedEngine(storage, { namespace: 'claims-agent-prod', dataDir: './audit-replay', embedder }) await replay.rebuildLocal(snap.cid) // { added: 1284, total: 1284 } await replay.recall('refund policy for water damage', { limit: 5 }) This is time travel for agent memory. You can ask the same question of last month's memory and today's, and compare. --- Step 4: Monitor Health With status() Auditing is after the fact. Monitoring catches problems while they happen. Both engines expose status(): javascript await memory.status() // batched: // { engine: 'batched', storage: 'lh-ipfs-filecoin', namespace, agent, // memories: 1284, pendingMemories: 0, flushEvery: 1, // embeddings: 'local:Xenova/all-MiniLM-L6-v2', indexPath, lastSnapshotCid: 'baf…' } | Signal | Engine | What it means | Alert when | |---|---|---|---| | pendingMemories | batched | Memories not yet on durable storage | Above zero at session end | | embeddings | batched | keyword:off means semantic recall fell back to keyword | Not the expected model | | lastSnapshotCid | batched | Most recent checkpoint | Older than your checkpoint window | | pendingPins | memwal | Records whose IPFS pin failed | Above zero; run repinPending() | | relayer | memwal | Relayer health, ok (v…) or unreachable | Not ok | The docs recommend the same habits: check pendingMemories before ending a session, pendingPins after writes, and embeddings when recall quality drops. Wire those three into your existing monitoring and you will catch the most common silent failures. --- Step 5: Understand What forget() Leaves Behind Auditors will ask what "deleted" means. Lighthouse Memory's forget() tells the truth per backend: | Backend | What forget() does | |---|---| | Batched, pending | Dropped locally, never uploaded | | Batched on S3 or local-fs | Hard delete once no other memory references the blob | | Batched on Lighthouse | Stops renewal; content stays readable until the period expires | | Memwal | Local copy removed and IPFS mirror unpinned; the encrypted Walrus blob lapses on its own | For audit, this is a feature: memory on Lighthouse storage cannot be quietly erased the moment something goes wrong. For privacy obligations, it means you should choose the backend deliberately. S3 gives hard deletes; see Composable Memory for AI Agents on S3 R2 and Open Source Models. --- Step 6: Anchor Checkpoints Where Others Can See Them A snapshot CID in your own database is evidence only you control. Publishing it somewhere independent turns it into evidence others can rely on. Two options: - The pointer service (@lighthouse-ai/cloud-sync) records the latest snapshot CID per namespace and network. - An onchain registry records every checkpoint CID with a block timestamp. Onchain Agent Memory on Robinhood Chain with Smart Contracts shows the contract. --- Frequently Asked Questions How do you audit an AI agent? Record what the agent recalled and decided as memories with content identifiers, checkpoint its full memory with snapshots, and keep those CIDs somewhere independent so records cannot be altered after the fact. What is the difference between agent logs and verifiable memory? Logs record events and can be edited by whoever controls them. Verifiable memory gives every record a CID derived from its content, so any change is detectable by anyone. How do I monitor an AI agent's memory in production? Poll status() and alert on pending memories at session end, keyword fallback in embeddings, stale lastSnapshotCid, and for memwal, pendingPins or an unhealthy relayer. Can a deleted agent memory still be audited? On Lighthouse storage, forget() stops renewal rather than erasing immediately, and snapshot CIDs taken earlier still reference the full index. --- Get Started - Batched engine reference - List, get, forget and status - Rebuild and recovery Start with the foundations in What Is Verifiable Memory for AI Agents. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
What Is Verifiable Memory for AI Agents
Articlecalendar_todaySep 26, 2026

What Is Verifiable Memory for AI Agents

An agent's memory is only useful if you can trust it. Verifiable memory means you do not have to take the agent's word for what it remembers. You can check. Most agent memory today is a row in a vector database or a JSON file on a server. The agent writes to it, reads from it, and nobody outside the system can tell whether a memory was edited, replaced, or silently dropped between the day it was written and the day it was used. That is fine for a chatbot remembering your favorite color. It is not fine for an agent that trades, files documents, answers customers, or makes decisions someone will later need to explain. Lighthouse Memory is built around a different idea: every memory is persisted as a content addressed blob with a CID. This post explains what that means, what it proves, what it does not prove, and how to use it. --- Verifiable Memory in One Sentence Verifiable memory is agent memory where each stored record has an identifier derived from its own bytes, so anyone holding that identifier can confirm the content they retrieve is byte for byte what was saved. The identifier is a CID, a content identifier. Lighthouse Memory uses CIDv1 with the raw codec and a sha2-256 hash. Same content always produces the same CID. Change one character and the CID changes. | | Typical agent memory | Verifiable memory | |---|---|---| | Identifier | Row ID or UUID assigned by the database | CID computed from the content | | Edited after the fact | Undetectable from outside | Produces a different CID | | Who can check integrity | Only the operator | Anyone with the CID | | Survives the app | Tied to one database | Retrievable from any gateway that serves the CID | | Portable across agents | Export and import code | Hand over a CID | --- What a CID Proves, and What It Does Not The Lighthouse homepage puts this plainly, and it is worth repeating: a CID confirms content integrity, not factual accuracy. It proves: - The memory you retrieved is exactly the memory that was stored under that CID. - Nobody altered it in storage, in transit, or on a gateway. - Two agents holding the same CID are looking at the same bytes. It does not prove: - That the memory was true when it was written. - That the agent recalled the right memory for the question. - Who wrote it, unless you record that separately (Lighthouse Memory records an agent field on every memory). That boundary matters. Verifiability does not make an agent correct. It makes an agent accountable: when something goes wrong, you can establish exactly what it remembered, instead of arguing about it. !memory-01-diagram.png --- How Lighthouse Memory Makes Memory Verifiable Lighthouse Memory gives agents three primitives, remember, recall and forget, over two engines. Both produce CIDs, in slightly different ways. The batched engine: one CID per batch With the batched engine, memories buffer locally as pending and then flush as a single batch blob, by default one blob per 10 memories (flushEvery). Each flushed memory is assigned the CID of the batch blob that holds it. javascript import '@lighthouse-ai/store-lighthouse' import '@lighthouse-ai/embed-local' import { createStorage, createEmbedder } from '@lighthouse-ai/core' import { BatchedEngine } from '@lighthouse-ai/engine-batched' const storage = await createStorage('lh-ipfs-filecoin', { apiKey: process.env.LIGHTHOUSEAPIKEY }) const embedder = await createEmbedder('local') const memory = new BatchedEngine(storage, { namespace: 'research-agent', embedder }) await memory.remember('Q3 revenue guidance was raised to 4.2B on the Oct 24 call.', { tags: ['earnings', 'guidance'], metadata: { source: 'call-transcript-2026-10-24' }, }) const { cid, gatewayUrl } = await memory.flush() // cid: 'baf…' - the batch blob holding this memory The batch blob is plain JSON with a stable shape: a version, the namespace, a batch ID, a timestamp and the records, each with its content, tags, metadata, agent, createdAt and embedding. Because the blob is content addressed, the CID commits to all of it. The memwal engine: one CID per memory With the memwal engine, every remember goes straight to a relayer that embeds, SEAL-encrypts and uploads the memory to Walrus. The SDK then pins a canonical JSON record to IPFS and gets a CID for that single memory. It also exposes a dedicated integrity check: javascript import { MemwalMemory } from '@lighthouse-ai/engine-memwal' const memory = await MemwalMemory.fromEnv() const stored = await memory.remember('Customer ACME is on enterprise.', { tags: ['customer'] }) await memory.verify(stored.id) // pinned: { id, cid, pinned: true, verified: true, method: 'gateway-fetch' } // unpinned: { id, cid, pinned: false, verified: true, method: 'local-hash' } verify() answers a precise question: is what the gateway serves byte identical to my local record? Pinned records are fetched and compared byte for byte. Unpinned records are re-hashed locally. --- Verify It Yourself, Without Trusting Lighthouse The strongest property of content addressing is that verification does not need the vendor. Anyone can fetch a memory blob from a public gateway and recompute its CID with standard open source libraries: javascript import { CID } from 'multiformats/cid' import as raw from 'multiformats/codecs/raw' import { sha256 } from 'multiformats/hashes/sha2' async function verifyMemoryBlob(expectedCid) { const res = await fetch(https://gateway.lighthouse.storage/ipfs/${expectedCid}) const bytes = new Uint8Array(await res.arrayBuffer()) const actual = CID.create(1, raw.code, await sha256.digest(bytes)) return actual.toString() === expectedCid } console.log(await verifyMemoryBlob(cid)) // true, or the memory was altered This is what "verifiable by design" means in practice. An auditor, a counterparty or a second agent can check your agent's memory with 10 lines of code and no account. --- Where Verifiable Memory Matters Most Trading and financial agents. Record the inputs an agent read before it acted, and the CID proves those inputs were not rewritten after a bad trade. See AI Trading Agents on Robinhood Chain Need Verifiable Memory. Research and prediction agents. Keep sources, forecasts and outcomes together, and let a later review prove which evidence the agent had at the time. Tokenized assets. Issuer research and document references stay addressable and checkable. Multi agent systems. When one agent hands context to another, a CID guarantees both are working from the same memory. See One Memory Layer Shared Across Every AI Model. Regulated workflows. An audit trail where each record's integrity can be checked by someone outside the company. See How to Audit and Monitor AI Agents with Verifiable Memory. --- One Honest Caveat Verifiable and private are different properties. Batched blobs, index snapshots and pinned memwal mirrors are plaintext. Anyone with the CID can read them. Native encryption for the batched engine is under development. Until then, encrypt sensitive content yourself before storing it, or use the memwal engine, whose blobs on Walrus are SEAL-encrypted. Encrypted Memory for AI Agents with Memwal and SEAL covers the tradeoffs. --- Frequently Asked Questions What is verifiable memory for AI agents? Agent memory where each record has a content identifier (CID) computed from its bytes, so anyone can confirm that retrieved memory matches what was stored. Does verifiable memory mean the agent is correct? No. A CID confirms content integrity, not factual accuracy. It proves what was remembered, not whether it was true. What CID format does Lighthouse Memory use? CIDv1 with the raw codec and a sha2-256 hash. The same content always yields the same CID. Can I verify a memory without a Lighthouse account? Yes. Fetch the blob from a public gateway and recompute the CID with an open source library such as multiformats. Which engine should I use for verification? Both produce CIDs. The memwal engine adds a built in verify() method and encrypts blobs on Walrus. The batched engine assigns each memory the CID of its batch blob. --- Get Started - Lighthouse Memory introduction - Quick start - Store memories - Memwal engine and verify() New to the building blocks? Read Lighthouse Memory Concepts Explained for Developers. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
NFTs on Arc with USDC Gas and Permanent Storage
Articlecalendar_todaySep 22, 2026

NFTs on Arc with USDC Gas and Permanent Storage

On most chains, minting an NFT means asking a user to buy a volatile token first. On Arc, the fee is in dollars. That changes who can collect, and what an NFT can be used for. Arc is a payments chain first, but it is fully EVM compatible, so ERC-721 and ERC-1155 contracts deploy unchanged. Gas is paid in USDC, finality is sub second, and consumer wallets such as MetaMask, Phantom and Ledger were live at mainnet. For consumer brands, ticketing, loyalty and creator platforms, a chain where users only ever see dollars is an easier product to ship. What Arc does not change is the oldest problem in NFTs: the token points at files, and the files have to stay put. This post covers minting on Arc with metadata and media on Lighthouse, plus the use cases that fit a dollar denominated chain best. --- Why Arc Suits Consumer NFTs | Property | Why it matters | |---|---| | USDC gas | Users see fees in dollars; no second token to buy | | Sub second deterministic finality | A mint or ticket scan confirms before the user looks away | | Prices in USDC | Primary sales and royalties in a stable unit | | EVM compatible | Standard contracts, OpenZeppelin, Foundry, Hardhat | | Circle wallets and App Kits | Embedded wallets and onramps for mainstream users | The combination points toward NFTs as utility: tickets, memberships, receipts, warranties, certificates and access passes, where the holder cares more about what the token does than what it might sell for. --- The Storage Side: Where NFTs Actually Break The contract stores ownership and a tokenURI. Everything a wallet displays comes from fetching that URI. If it points at a project's server, the NFT is only as durable as that server. IPFS for NFT Metadata: How Token URIs Break catalogs the ways this goes wrong. The fix: - Store media and metadata on content addressed storage. - Use ipfs:// URIs, not gateway URLs. - Back the data with persistence that does not depend on one pinning node. Lighthouse does all three. Uploads return CIDs, data is pinned on IPFS and held in Filecoin storage deals with ongoing proofs, and dedicated gateways serve it fast, including image resizing at retrieval and 4K video streaming. !arc-05-diagram.png --- Minting on Arc, Step by Step 1. Upload the collection javascript import lighthouse from "@lighthouse-web3/sdk"; const apiKey = process.env.LIGHTHOUSEAPIKEY; // Upload the media folder: one directory CID for the whole collection const media = await lighthouse.upload("./collection/images", apiKey); const mediaDirCID = media.data.Hash; // Generate metadata that references media by CID // e.g. metadata/0.json - { "name": "Access Pass 0", "image": "ipfs://<mediaDirCID/0.png", ... } const meta = await lighthouse.upload("./collection/metadata", apiKey); const baseURI = ipfs://${meta.data.Hash}/; 2. A contract that sells for USDC solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; contract AccessPass is ERC721 { IERC20 public immutable usdc; // USDC ERC-20 interface on Arc (6 decimals) uint256 public constant PRICE = 25000000; // 25 USDC address public immutable treasury; string private base; // "ipfs://<metadataDirCID/" uint256 public nextId; constructor(IERC20 usdc, address treasury, string memory base) ERC721("Access Pass", "PASS") { usdc = usdc; treasury = treasury; base = base; } function mint() external returns (uint256 id) { require(usdc.transferFrom(msg.sender, treasury, PRICE), "payment failed"); id = nextId++; safeMint(msg.sender, id); } function baseURI() internal view override returns (string memory) { return base; } } Two Arc specific details. Price with the USDC ERC-20 interface, which uses 6 decimals, not the 18 decimal native representation used for gas. And the buyer pays both the mint price and the gas in the same currency, which makes checkout copy simple: one dollar amount. 3. Deploy bash forge create src/AccessPass.sol:AccessPass \ --rpc-url https://rpc.mainnet.arc.io \ --private-key $DEPLOYERKEY \ --constructor-args $USDCADDRESS $TREASURY "ipfs://<metadataDirCID/" Chain ID 5042 on mainnet and 5042002 on testnet. Get the USDC contract address from the official Arc docs rather than from a third party list. --- Pay to View Media, Priced in Dollars The most natural NFT product on a dollar chain is paid content. A creator sells a pass for a few dollars in USDC; holders unlock a film, a course, a research series or a music release. Lighthouse encrypts the content client side and splits its key across independent nodes with threshold cryptography. Decryption can be granted to specific addresses, or gated on conditions such as holding an NFT or the return value of a payment contract. The file itself never has to leave decentralized storage, and Lighthouse never holds a complete key. javascript // Encrypt the premium video before upload const { data } = await lighthouse.uploadEncrypted( "./premium/episode-01.mp4", process.env.LIGHTHOUSEAPIKEY, creatorAddress, signedMessage ); const videoCID = data[0].Hash; // Grant access to a buyer after their USDC mint confirms await lighthouse.shareFile(creatorAddress, [buyerAddress], videoCID, signedMessage); Chain support note. Condition based gating, such as "decrypt if you hold an Access Pass," reads contract state from chains on Lighthouse's Chains Supported list, and Arc is not listed yet. Until it is, grant access per buyer as above by listening for mint events, or request Arc support on Discord. The pattern is covered end to end in Creating a Pay-to-View Model Using Lighthouse Storage, and video delivery in Serving Video from IPFS Without Buffering. --- NFT Ideas Built for Arc Event tickets. Priced in USDC, confirmed in under a second at the door. Ticket art and venue details by CID; recordings unlocked for holders afterwards. Receipts and warranties. A purchase settled in USDC mints a receipt NFT whose metadata points to the encrypted invoice and warranty terms. Pairs with Cross Border Payments on Arc with Private Verifiable Records. Credentials and certificates. Course completions and professional certifications with the certificate PDF stored by CID, so anyone can verify it has not been altered. Membership passes. Monthly or annual passes that gate a content vault, bought with dollars from an embedded wallet. Agent identity. An NFT representing an AI agent, with its capabilities and service terms by CID, for agents selling services on Arc. See Agentic Commerce on Arc with x402 Nanopayments and Lighthouse. --- Frequently Asked Questions Can you mint NFTs on Arc? Yes. Arc is EVM compatible, so standard ERC-721 and ERC-1155 contracts work, and minting fees are paid in USDC. What is the gas token for NFT mints on Arc? USDC. The native representation has 18 decimals; the USDC ERC-20 interface used for prices and transfers has 6. Where should Arc NFT metadata be stored? On IPFS with Filecoin backed persistence, referenced with ipfs:// URIs. Lighthouse handles upload, pinning, Filecoin deals and gateways. Can NFTs on Arc unlock private content? Yes. Encrypt content with Lighthouse and grant decryption to holders, per address today, or through onchain conditions once Arc is supported for condition evaluation. --- Get Started - Minting NFTs on EVM chains - Create pay to view media - Resize images at retrieval - Connect to Arc New to the chain? Read What Is Arc by Circle and How Lighthouse Adds the Storage Layer. Launching NFTs on Arc? Start on the free tier, 5 GB with no card, or talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Cross Border Payments on Arc with Private Verifiable Records
Articlecalendar_todaySep 22, 2026

Cross Border Payments on Arc with Private Verifiable Records

A payment is a number and a reason. Arc makes the number move across borders in under a second. The reason, the invoice, the remittance advice and the compliance file, still travels by email. Cross border payments are one of Arc's headline use cases. USDC is the gas token, EURC is native, Circle StableFX supports round the clock onchain FX between stablecoins, and settlement is deterministic and sub second. The founding validator set includes Visa, Mastercard, MoneyGram and Worldpay, companies that move money for a living. The part blockchains do not solve is the paperwork that travels with every business payment. This post covers how to attach that paperwork to Arc payments in a way that is private, verifiable and durable, using Lighthouse. --- What Travels With a Business Payment A single supplier payment in B2B trade usually involves: | Record | Who needs to see it | |---|---| | Invoice | Payer, payee, both finance teams | | Purchase order and delivery proof | Payer, payee, sometimes a financier | | Remittance advice | Payee's accounts receivable | | FX quote and confirmation | Both parties, treasury | | Sanctions and KYB screening results | Payer's compliance, regulators on request | | Tax documents | Both parties, tax authorities | In a traditional wire, these ride alongside the payment through email, portals and message fields with strict length limits. Reconciliation breaks when they get separated. And in a dispute, each side produces its own copy of the invoice, and nobody can prove which one was paid. On Arc, you can bind the payment to the documents permanently, without exposing the documents to the public. --- The Pattern: Encrypted Record, Public Commitment !arc-04-diagram.png 1. Encrypt and store. The payer's system encrypts the invoice bundle client side and uploads it to Lighthouse. The result is a CID. 2. Share. Decryption is granted to the payee's address, and to any other named party such as a trade financier. 3. Pay with a commitment. The USDC or EURC payment on Arc carries the CID, in the calldata of a payments contract or in an event. 4. Verify anytime. Either party, or an auditor they authorize, decrypts the bundle and confirms it matches the CID that was paid against. The CID is public. The contents are not. Anyone can see that a payment is bound to a specific document; only authorized parties can read it. javascript import lighthouse from "@lighthouse-web3/sdk"; // 1. Encrypt the invoice bundle before it leaves the payer's system const { data } = await lighthouse.uploadEncrypted( "./outgoing/INV-88213-bundle.zip", process.env.LIGHTHOUSEAPIKEY, payerAddress, signedMessage ); const recordCID = data[0].Hash; // 2. Give the supplier access await lighthouse.shareFile(payerAddress, [supplierAddress], recordCID, signedMessage); // 3. Pay on Arc with the CID bound to the payment await walletClient.writeContract({ address: INVOICESETTLEMENT, abi: invoiceSettlementAbi, functionName: "settle", args: [supplierAddress, EURCADDRESS, 48250000000n / 48,250 EURC /, recordCID], chain: arc, // chain ID 5042 }); And a minimal settlement contract: solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; contract InvoiceSettlement { event Settled(address indexed payer, address indexed payee, address token, uint256 amount, string recordCID); function settle(address payee, address token, uint256 amount, string calldata recordCID) external { require(IERC20(token).transferFrom(msg.sender, payee, amount), "transfer failed"); emit Settled(msg.sender, payee, token, amount, recordCID); } } The Settled event is the reconciliation key. The payee's accounts receivable system watches for events addressed to it, reads the CID, decrypts the remittance data and matches the payment automatically, whatever the payer typed in a free text field. --- Privacy on Two Layers Arc is adding opt in confidential transfers and balances with view keys, so amounts can be hidden from the public while remaining visible to parties holding a view key. That protects the payment. Lighthouse protects the documents in the same spirit: - Encrypted before upload. Storage providers and Lighthouse only ever see ciphertext. - No single key holder. The key is split with BLS threshold cryptography across independent nodes. Reconstructing it requires a threshold of nodes, each checking access rules. - Selective disclosure. Share with specific addresses: payee, financier, auditor. Each grant is independent. - Revocation. When a relationship ends, revoke access. The CID and the onchain commitment do not change. Public IPFS alone would be the wrong tool here. Anything uploaded unencrypted is readable by anyone with its CID, a point covered in Is IPFS Private? What Content Addressing Hides, and What It Doesn't. --- FX Payments and Quote Records Circle StableFX brings onchain FX between stablecoins with near instant settlement. For a treasury team, the FX quote is itself a record: the rate offered, the time, the counterparty. Store the quote and confirmation by CID and include it in the settlement event, and the rate a payment was converted at is provable long after the fact. This matters most in the cases people argue about: a disputed rate, a late payment across a weekend, or a regulator asking how a conversion was priced. --- Retention Without a Records Server Payment records often must be retained for years under tax and anti money laundering rules. On the Filecoin path, Lighthouse holds files in storage deals with ongoing cryptographic proofs. Retention becomes something you can demonstrate, not just assert. Deals run for a term and are renewed; What Happens When a Filecoin Deal Expires? explains how. For teams whose records pipeline already writes to S3, Lighthouse's L3 is S3 compatible, with each object's CID returned in the x-amz-meta-cid header. Existing archival jobs can point at it with a configuration change. --- Where This Fits Payment companies and PSPs building on Arc can offer reconciliation that just works, because every payment carries a document commitment. Trade finance platforms can finance invoices whose integrity is anchored onchain, reducing double financing risk: the same invoice CID cannot be presented twice unnoticed. Payroll and contractor platforms can pay globally in USDC or EURC and deliver payslips to each worker encrypted to their address. Marketplaces can bind order, delivery and dispute evidence to the payment that settled them. Chain support note. Everything above works on Arc today, because it depends only on storing CIDs and sharing with addresses. Lighthouse can also gate decryption on onchain conditions for chains on its Chains Supported list; Arc is not listed yet. For Arc native conditions, request support on Discord. --- Frequently Asked Questions Can Arc be used for cross border payments? Yes. Arc settles USDC and EURC with deterministic sub second finality, uses USDC for gas, and supports onchain FX through Circle StableFX. How do you attach an invoice to a stablecoin payment? Store the invoice with Lighthouse, then include its CID in the payment transaction or an event. The CID permanently binds the payment to that exact document. Are invoices stored on IPFS private? Only if encrypted. Lighthouse encrypts client side and shares decryption with named addresses, so the public sees a CID and nothing else. How long can payment records be kept? As long as needed. On the Filecoin path, records are held in renewable storage deals with ongoing storage proofs. --- Get Started - Upload encrypted data - Secure file sharing tutorial - L3, the S3 compatible API - Connect to Arc New to Arc? Start with What Is Arc by Circle and How Lighthouse Adds the Storage Layer. Building payments on Arc? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Tokenized Assets on Arc Need Documents That Cannot Change
Articlecalendar_todaySep 22, 2026

Tokenized Assets on Arc Need Documents That Cannot Change

Arc settles a tokenized fund share in under a second with finality that cannot be reversed. If the fund's offering document can be edited quietly afterwards, the weakest link in the system is now a PDF. Arc was designed for capital markets. Its founding validators include BlackRock, DTCC, ICE, Standard Chartered and Sumitomo Corporation. Circle lists asset tokenization, capital markets settlement, treasury management and onchain credit among Arc's primary use cases, and the chain combines USDC gas, deterministic finality and opt in privacy for exactly that audience. Institutional tokenization lives or dies on documentation. This post covers the document layer for tokenized assets on Arc and how Lighthouse makes it verifiable, durable and private where it needs to be. --- Why Institutions Care About the Document Layer In traditional markets, the integrity of documents is enforced by institutions: transfer agents, custodians, auditors and registrars who keep the canonical copy. Tokenization moves ownership and settlement onchain, but usually leaves the canonical documents on the issuer's systems. That creates an odd split. Ownership is public, final and verifiable by anyone. The terms that define what is owned are private, mutable and verifiable by no one outside the issuer. | Onchain on Arc | Usually offchain | |---|---| | Who holds the token | What the token entitles them to | | When it moved | Which version of the terms applied | | Settlement price in USDC | The NAV report that justified the price | | Compliance flags on transfers | The KYC evidence behind them | Closing that gap does not mean putting PDFs onchain. It means putting commitments to PDFs onchain. --- Content Addressing, Explained for Capital Markets A CID is a fingerprint computed from a file's bytes. Two important properties: 1. The same file always produces the same CID, on any machine. 2. Any change, even one character, produces a different CID. Record a CID on Arc and you have a timestamped, final, publicly verifiable commitment to one exact document. Anyone can later fetch the file, recompute the CID and confirm it matches, without trusting the issuer, Lighthouse or anyone else. What Is a CID? Content Identifiers, v0 vs v1, and How to Read One covers the format. !arc-03-diagram.png --- The Documents, and Where Each Belongs | Document | Visibility | Lighthouse storage path | Why | |---|---|---|---| | Offering memorandum, fund terms | Public | IPFS with Filecoin deals | Long retention, provable storage | | Daily or weekly NAV reports | Public or holders | Walrus | Read constantly by apps and lenders | | Custody and reserve attestations | Holders, auditors | Filecoin, encrypted | Restricted, retained for years | | Corporate actions and notices | Public | Walrus or IPFS | Must reach every integrator fast | | Subscription agreements | Named parties | Filecoin, encrypted | Private, legally significant | | KYC and accreditation evidence | Transfer agent, regulator | Filecoin, encrypted | Personal data, revocable access | Mixing paths is normal. Lighthouse puts both behind one interface, with the same CIDs, so choosing Walrus for NAV reports and Filecoin for agreements is a per file decision, not a platform decision. Walrus vs Filecoin: Erasure Coding or Replication? has the tradeoffs. --- Publishing a NAV Report on Arc A daily NAV publication that anyone can verify: javascript import lighthouse from "@lighthouse-web3/sdk"; // 1. Store the signed NAV report const report = await lighthouse.upload("./nav/2026-09-18.pdf", process.env.LIGHTHOUSEAPIKEY); // 2. Publish NAV and document CID together on Arc (chain ID 5042) await walletClient.writeContract({ address: FUNDORACLE, abi: fundOracleAbi, functionName: "publishNav", args: [ fundId, 1000432100n, // NAV per share, 6 decimals, in USDC terms report.data.Hash, // CID of the full report ], chain: arc, }); A lending protocol that accepts fund shares as collateral now reads a number and a CID from the same transaction. If the number is ever disputed, the report behind it is one fetch away and cannot have been edited. --- Private Documents Without a Private Server Arc is adding confidential transfers with view keys, so institutions can hide amounts while granting auditors visibility. Documents need the same model: private by default, readable by specific parties, revocable. Lighthouse encrypts files on the client before upload. The key is split with BLS threshold cryptography across independent key nodes, and no single node, including Lighthouse, holds a complete key. Storage providers only ever see ciphertext. Then you grant access: javascript // Upload a subscription agreement encrypted const { data } = await lighthouse.uploadEncrypted( "./agreements/sub-2026-0418.pdf", process.env.LIGHTHOUSEAPIKEY, issuerAddress, signedMessage ); const cid = data[0].Hash; // Share with the investor and the fund administrator await lighthouse.shareFile(issuerAddress, [investorAddress, administratorAddress], cid, signedMessage); The public CID can go onchain as a commitment, even though the contents stay private. An auditor with access can confirm the decrypted agreement matches the committed CID. Everyone else can confirm only that a commitment exists and has not changed. Chain support note. Lighthouse can also gate decryption on onchain conditions such as token holdings or a custom contract's return value, for chains on its Chains Supported list. Arc is not on that list yet. Named address sharing and revocation work today. For conditions evaluated against Arc contracts, such as "holds fund shares" or "is on the allowlist contract," request Arc support on Discord. --- Retention and Proof of Storage Regulated records often have retention periods measured in years. "We still have it" is a claim; a storage proof is evidence. On the Filecoin path, documents sit in storage deals where providers submit ongoing proofs that they hold the data. You can check deal status for any CID, and How to Verify Your File Is Actually Stored on Filecoin explains how to confirm it independently. Deals have terms and Lighthouse manages renewal; What Happens When a Filecoin Deal Expires? explains the lifecycle. --- An Issuer Checklist for Arc - Every public document uploaded, its CID recorded onchain alongside the event it supports. - Document history kept as an append only list of CIDs, never overwritten. - NAV and pricing reports published with their CIDs in the same transaction as the value. - Private documents encrypted client side, shared with named parties, with revocation owners assigned. - Retention on the Filecoin path for records with regulatory lifetimes. - A public page listing current document CIDs so integrators can verify independently. --- Frequently Asked Questions Is Arc built for tokenized assets? Yes. Circle lists asset tokenization, capital markets settlement and treasury management among Arc's primary use cases, and its founding validators include BlackRock, DTCC, ICE and Standard Chartered. How do you prove a tokenized asset's documents have not changed? Record each document's CID onchain. A CID is derived from the file's content, so any edit produces a different CID and is detectable. Can private fund documents be stored on decentralized storage? Yes, if encrypted client side. Lighthouse uses threshold encryption so only named parties can decrypt, and access can be revoked. Where should NAV reports be stored? Somewhere fast to read and verifiable, with the CID published next to the NAV value. Lighthouse's Walrus path suits frequently read reports. --- Get Started - Upload data - Upload encrypted data - Check Filecoin deal status - Connect to Arc Background on the chain: What Is Arc by Circle and How Lighthouse Adds the Storage Layer. Tokenizing assets on Arc? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Agentic Commerce on Arc with x402 Nanopayments and Lighthouse
Articlecalendar_todaySep 22, 2026

Agentic Commerce on Arc with x402 Nanopayments and Lighthouse

The agent economy needs three things at once: money that settles instantly, prices small enough to charge per request, and a place to keep what was bought. Arc supplies the first two. Lighthouse supplies the third. Circle's own figure is striking: USDC accounts for 98.8 percent of agent driven transaction volume. Arc is Circle's bet that agents will transact on a chain where the gas token is the same dollar they spend, finality is sub second, and payments can be smaller than a cent without the fee eating them. This post explains how agentic commerce works on Arc, where x402 fits, and how Lighthouse gives agents storage they can pay for in USDC, memory that survives restarts, and receipts that prove what they bought. --- The Circle Agent Stack on Arc | Component | What it does | |---|---| | Agent Wallets | Wallets agents control within policies their owners set | | Nanopayments | Sub cent USDC payments using x402, settled in batches through Circle Gateway | | Agent Marketplace | Discovery of x402 services agents can pay for | | AgentVM (in development) | Execution for agents handling sensitive data, with immutable records | | USDC gas | Agents budget in dollars, with no second token to manage | | Sub second finality | Payments are final before the agent's next step | The piece that ties it together is x402. --- x402 in One Paragraph HTTP has had a 402 Payment Required status code since the 1990s with nothing behind it. x402 gives it a job. A client requests a resource. The server replies 402 with a price and a pay to address. The client pays in USDC, retries with proof of payment, and receives the resource. No API key, no account, no subscription. For agents this is ideal: payment becomes part of the request, the same way authentication is. Circle Nanopayments make x402 economical at tiny prices. Instead of settling every call onchain, buyers fund a Gateway balance once, sign offchain payment authorizations per request, and Gateway settles net positions in bulk on Arc. That is how prices as low as $0.000001 per call become workable. !arc-02-diagram.png --- What Agents Buy, and What They Must Keep An agent on Arc might pay per call for market data, per page for a research API, per inference for a specialist model, or per task for another agent's work. Each purchase produces something: - An artifact. A dataset, a generated report, an image, a model output. - A receipt. Proof of what was paid, to whom, for what. - Context. What the agent learned that it should remember for next time. If all three live in a container's memory, they vanish on restart. The agent paid real dollars for them. It should keep them in storage that outlives the process, that it can pay for itself, and that it can prove. --- Storage an Agent Can Pay For: Lighthouse over x402 Lighthouse already sells storage over x402. An agent POSTs a file, receives a 402 quote priced by file size, pays in USDC, and gets back a CID. No API key and no human with a credit card. javascript import { x402Client, wrapFetchWithPayment } from "@x402/fetch"; import { registerExactEvmScheme } from "@x402/evm/exact/client"; import { privateKeyToAccount } from "viem/accounts"; const signer = privateKeyToAccount(process.env.AGENTKEY); const client = new x402Client(); registerExactEvmScheme(client, { signer }); const payFetch = wrapFetchWithPayment(fetch, client); // Persist something the agent just bought const artifact = new Blob([JSON.stringify(purchasedReport)], { type: "application/json" }); const res = await payFetch(${LIGHTHOUSEX402URL}/api/upload, { method: "POST", headers: { "Content-Type": "application/octet-stream", "x-file-name": "report.json" }, body: artifact, }); const { cid } = await res.json(); Two properties make this useful for agents: Two proofs per upload. The CID proves what was stored. The payment response header carries the settlement transaction hash, which proves what was paid. Together they are an audit trail an agent produces without extra work. Retention is renewable the same way. Storage bought over x402 on the IPFS and Filecoin path carries a one year term. Renewing is another x402 call, so an agent can be given a budget and a renewal schedule and left alone. Chain note, stated plainly. Lighthouse's x402 endpoints settle in USDC on Base mainnet today, not on Arc. An Arc native agent can hold USDC on Arc for its purchases and keep a storage budget on Base, moving USDC between the two with Circle's crosschain infrastructure. The request pattern is identical, and both sides speak x402. Lighthouse x Base: Storage That Agents Can Pay For Themselves covers the Base integration in full. --- Memory That Travels With the Agent Receipts and artifacts are files. An agent also needs working memory: its owner's instructions, spending policies, which vendors delivered, which ones failed. Lighthouse Memory provides remember, recall and forget for agents, with every memory persisted as a verifiable blob addressed by an IPFS compatible CID. - Memory lives on the network, so an agent resumes across sessions, machines and runtimes, and rebuilds its store from nothing but an API key. - Semantic recall runs locally with an in process embedding model. No extra API key; no embedding data leaves the machine. - A bundled MCP server exposes memory as tools to Claude Code, Claude Desktop and any MCP capable runtime. A purchasing agent can remember that a data vendor returned stale prices last Tuesday and recall it before paying that vendor again. Over weeks, that is the difference between an agent that spends money and one that spends it well. Limitation: Memory blobs are currently stored unencrypted, and anyone with a CID can read them. Do not store secrets, keys or personal data in Memory yet. For sensitive material, use encrypted uploads. --- Selling to Agents: Data Vendors on Arc The other side of agentic commerce is the seller. If you run a dataset, a research feed or a model on the Agent Marketplace, your deliverables are files. A clean pattern for x402 sellers: 1. Store the paid resource encrypted on Lighthouse. 2. When the Nanopayment settles, share decryption with the buyer's address, or return a short lived link to the decrypted content. 3. Log the CID of what was delivered with the payment reference. If a buyer later disputes what they received, the CID settles it. The delivered bytes either match the CID or they do not. --- Agent Patterns Worth Building on Arc Research agents with citations by CID. Every source an agent paid for is stored and cited by CID in its final report. Procurement agents with policy memory. Spending rules and vendor history in Memory, recalled before every purchase. Agent to agent work markets. One agent pays another per task on Arc; deliverables are exchanged by CID so both sides can prove what changed hands. Dataset licensing. Evaluation or training data shared under conditions and revocable later. See Storing AI Training Data on Filecoin: Provenance You Can Prove. Compliance trails for regulated agents. Receipts retained on the Filecoin path, paired with Arc transaction hashes, for records that auditors will ask for. --- Frequently Asked Questions What is agentic commerce? AI agents buying and selling services autonomously, paying per use in stablecoins without a human approving each transaction. What are Circle Nanopayments? Sub cent USDC payments built on x402 and Circle Gateway. Buyers sign offchain authorizations per request and Gateway settles net positions onchain in batches on Arc. How does an AI agent pay for storage? With x402. Lighthouse returns a 402 price quote for an upload, the agent pays in USDC, and the upload completes with a CID. Lighthouse's x402 endpoints currently settle on Base. Where should an AI agent keep its memory? Outside the process, in persistent storage it can rebuild from. Lighthouse Memory stores memories as CID addressed blobs and exposes them over MCP. --- Get Started - x402 pay per use upload - Memory introduction - Connect agents via MCP - Circle Agent Nanopayments New to Arc? Read What Is Arc by Circle and How Lighthouse Adds the Storage Layer. Building agents on Arc? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
What Is Arc by Circle and How Lighthouse Adds the Storage Layer
Articlecalendar_todaySep 22, 2026

What Is Arc by Circle and How Lighthouse Adds the Storage Layer

Arc makes the dollar the native unit of a blockchain. Settlement becomes instant and predictable. The contracts, invoices and records that explain each payment still need somewhere to live. Circle launched Arc mainnet on September 16, 2026. It is an open, EVM compatible Layer 1 where gas is paid in USDC, finality is deterministic and sub second, and the founding validators include BlackRock, DTCC, Visa, Mastercard and Standard Chartered. During its testnet year Arc processed more than 700 million transactions across more than 1,200 projects, and over 100 institutional builders were live at mainnet. This post explains what Arc is, what makes it different from the EVM chains you already build on, and where Lighthouse fits in an Arc application. --- Arc at a Glance | | Arc | |---|---| | Built by | Circle | | Type | Open Layer 1, EVM compatible | | Mainnet | Live since September 16, 2026 | | Mainnet chain ID | 5042 | | Testnet chain ID | 5042002 | | Gas token | USDC (18 decimals natively, 6 decimals through the ERC-20 interface) | | Consensus | Malachite, Circle's Tendermint style BFT engine | | Finality | Deterministic, sub second | | Execution | EVM, built on Reth | | Validators | Permissioned founding set today, proof of stake planned for 2027 | | Founding validators | BlackRock, DTCC, Galaxy, ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation, Visa, Worldpay | | Explorer | explorer.arc.io | --- Four Ideas That Make Arc Different 1. Dollars as gas On most chains a user must hold a volatile token to pay fees. On Arc, fees are paid in USDC, so costs are quoted and budgeted in dollars. For a payments company, a treasury desk or an AI agent with a budget, that removes an entire class of operational work: nobody has to top up ETH or hedge fee exposure. A developer detail worth knowing: native USDC balances use 18 decimals at the protocol level, such as ethgetBalance and msg.value, while the USDC ERC-20 interface uses the familiar 6 decimals. Mixing the two is the most common first bug. 2. Deterministic finality Arc runs Malachite, a BFT consensus engine. A transaction is either not yet committed or final, with no probabilistic reorg window. For payments and capital markets settlement, "final in under a second" is a different product from "probably final after a few blocks." 3. Opt in privacy Arc is building confidential transfers and balances with view keys, so an institution can keep amounts private while still granting an auditor or regulator visibility. This is opt in and still rolling out. 4. Built for agents and FX Circle's Agent Stack brings Agent Wallets, Nanopayments and an Agent Marketplace. Nanopayments combine the x402 protocol with Circle Gateway batching, so payments as small as a millionth of a dollar become practical. Circle StableFX enables round the clock onchain FX between stablecoins such as USDC and EURC. javascript import { defineChain } from "viem"; export const arc = defineChain({ id: 5042, name: "Arc", nativeCurrency: { name: "USDC", symbol: "USDC", decimals: 18 }, // native representation rpcUrls: { default: { http: ["https://rpc.mainnet.arc.io"] } }, blockExplorers: { default: { name: "Arc Explorer", url: "https://explorer.arc.io" } }, }); --- What Arc Does Not Store Arc settles value. It is not designed to hold files, and no EVM chain is: contract storage costs grow with every byte, and documents do not belong in a state trie. Yet Arc's target use cases are document heavy: - Tokenized assets need prospectuses, NAV reports and attestations. - Cross border payments need invoices, remittance advice and compliance records. - Capital markets settlement needs trade confirmations and legal agreements. - AI agents need memory, datasets and receipts for what they bought. - Consumer apps and NFTs need media and metadata. A USDC transfer that settles in under a second is not much use if the invoice it paid lives in an email attachment that nobody can verify later. !arc-01-diagram.png --- How Lighthouse Fits Into Arc Lighthouse is a storage layer across IPFS, Filecoin and Walrus with client side encryption and programmable access control. On Arc it plays four roles. Content addressed records. Every file gets a CID derived from its bytes. Put the CID in an Arc transaction, event or contract, and the payment is permanently bound to one exact document. Verifiable persistence. Files on the Filecoin path are held in storage deals with ongoing cryptographic proofs. Files on the Walrus path are erasure coded for fast reads. Privacy that matches Arc's. Arc's opt in privacy protects amounts and balances. Lighthouse protects the documents. Files are encrypted client side and the key is split with BLS threshold cryptography across independent nodes, so Lighthouse never holds a complete key. Share with named addresses and revoke later, the file equivalent of a view key. Dollar denominated storage for agents. Lighthouse already sells storage over x402 for USDC, the same protocol behind Circle Nanopayments. Today that rail settles on Base; see the chain note below. javascript import lighthouse from "@lighthouse-web3/sdk"; // Store an invoice, then settle it on Arc with the CID in the memo const { data } = await lighthouse.upload("./invoice-INV-20931.pdf", process.env.LIGHTHOUSEAPIKEY); await walletClient.writeContract({ address: PAYMENTSCONTRACT, abi: paymentsAbi, functionName: "payInvoice", args: [supplier, 125000000n / 125 USDC, 6 decimals ERC-20 /, data.Hash], chain: arc, }); Chain support notes. Lighthouse x402 payments settle in USDC on Base today, not on Arc; USDC moves between the two through Circle's crosschain infrastructure. Lighthouse access conditions also evaluate against chains on the published Chains Supported list, which does not yet include Arc. Storage, CIDs, encryption, sharing and revocation work on Arc applications today. For Arc native conditions, request support on Discord. --- Where to Go Next - Agents buying services with nanopayments: Agentic Commerce on Arc with x402 Nanopayments and Lighthouse - RWAs and capital markets documents: Tokenized Assets on Arc Need Documents That Cannot Change - Payments with private, verifiable records: Cross Border Payments on Arc with Private Verifiable Records - Collectibles and creator media: NFTs on Arc with USDC Gas and Permanent Storage --- Frequently Asked Questions What is Arc? Arc is an open, EVM compatible Layer 1 blockchain built by Circle. It uses USDC as its gas token, reaches deterministic sub second finality with Malachite consensus, and targets payments, tokenized assets, FX and AI agent commerce. Mainnet launched on September 16, 2026. What is the Arc chain ID? Mainnet is 5042. Testnet is 5042002. Does Arc have a native token? Gas is paid in USDC. Circle has minted an ARC token at genesis for security, utility and governance, but has not committed to a public launch, and fees remain payable in USDC. Who runs Arc validators? A permissioned founding set including BlackRock, DTCC, Galaxy, ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation, Visa and Worldpay. Circle plans to move to proof of stake in 2027. Where do Arc apps store files? Offchain, in content addressed storage such as Lighthouse on IPFS, Filecoin or Walrus, with the CID recorded onchain. --- Get Started - Create a Lighthouse API key - Upload encrypted data - x402 pay per use upload - Connect to Arc Building on Arc? Start on the free tier, 5 GB on Filecoin with no card, or talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Building DeFi Apps on Robinhood Chain with Decentralized Storage
Articlecalendar_todaySep 22, 2026

Building DeFi Apps on Robinhood Chain with Decentralized Storage

A DeFi protocol is only as decentralized as its weakest dependency. On most protocols, that dependency is a frontend on a single cloud account. Robinhood Chain launched with a DeFi stack in place on day one: a dedicated Uniswap AMM for public liquidity, Pleiades for prop trading, Morpho for lending, Lighter and Arcus for perpetuals, Chainlink oracles, LayerZero messaging and Paxos USDG as a dollar stablecoin. Stock Tokens can be deposited into lending pools and used as trading collateral. That is a lot of new surface area for builders: lending markets for tokenized equities, structured products, vaults, aggregators and risk dashboards. The contracts get audited. The offchain half of each protocol rarely gets the same attention. This guide covers that half and where Lighthouse fits. --- The Offchain Half of a DeFi Protocol | Component | Typical home | Risk | Better home | |---|---|---|---| | Web frontend | Cloud hosting behind a DNS name | Takedown, DNS hijack, silent code change | IPFS, versioned by CID | | Audit reports | PDF on a website | Swapped or removed after an incident | CID recorded onchain | | Governance proposals and specs | Forum post, doc link | Edited after the vote | CID in the proposal | | Oracle and price snapshots | Internal database | Unverifiable during disputes | Archived by CID, backed by Filecoin deals | | Liquidation and risk reports | Internal database | Cannot be independently checked | Published by CID | | Historical analytics datasets | Cloud buckets | Lock in, egress costs | S3 compatible decentralized storage | Every row has the same theme. The data that users and integrators rely on to trust a protocol can be changed or removed by whoever controls a server. Content addressing turns each of these into something verifiable. !robinhood-05-diagram.png --- 1. Host the Frontend on IPFS A user interacting with a lending market for Stock Tokens signs transactions the frontend builds. If an attacker changes the frontend, users sign the attacker's transactions. Frontend compromise through DNS hijacking or a leaked deploy credential has drained users on major protocols more than once. Publishing the built frontend to IPFS gives every release a CID. The CID is the exact set of files users load, and it cannot be modified without producing a different CID. bash Build and publish a static frontend with the Lighthouse CLI npm run build lighthouse-web3 upload ./out = CID: bafybei... (this CID is your release) Then point a stable name at it. An IPNS key lets you publish new releases under one name; DNSLink maps your domain to the current CID. Publish each release CID in your repo and on your governance forum so users can verify what they are loading. IPNS or DNSLink? Choosing a Mutable Pointer explains how to choose. --- 2. Anchor Audits and Governance by CID When a proposal says "upgrade to the implementation described in the attached spec," the attachment should be a CID, not a link. The vote then binds to an exact document. javascript import lighthouse from "@lighthouse-web3/sdk"; const audit = await lighthouse.upload("./audits/lending-v2-final.pdf", process.env.LIGHTHOUSEAPIKEY); // Store the CID in the protocol's metadata registry on Robinhood Chain (chain ID 4663) await registry.write.setAuditReport(["lending-v2", audit.data.Hash]); Anyone can later fetch the audit by CID, hash it, and confirm it is the report the contract points to. A post incident edit becomes detectable instead of deniable. --- 3. Archive Oracle, Liquidation and Risk Data Lending against tokenized equities means liquidations will happen around price moves in the underlying stock, including moves that happen while traditional markets are closed and Stock Tokens keep trading. When a user disputes a liquidation, the protocol needs to show the price data and parameters it acted on. A useful pattern: every hour, or every liquidation batch, the keeper serializes the oracle readings, market parameters and positions touched, uploads the bundle to Lighthouse, and emits the CID in an event. javascript const snapshot = { block: await publicClient.getBlockNumber(), market: "STOCK-TOKEN/USDG", oracle: { source: "chainlink", price: latestPrice, updatedAt }, params: { lltv: "0.77", liquidationIncentive: "0.05" }, liquidated: batch.map((p) = ({ account: p.account, repaid: p.repaid, seized: p.seized })), }; const { data } = await lighthouse.uploadText(JSON.stringify(snapshot), process.env.LIGHTHOUSEAPIKEY, liq-${snapshot.block}.json); await keeper.write.recordSnapshot([snapshot.block, data.Hash]); On the Filecoin path, these archives are held in storage deals with ongoing proofs, which matters for records you may need to produce long after the fact. See How to Verify Your File Is Actually Stored on Filecoin. --- 4. Analytics Data Without Rewriting Your Pipeline Risk teams and analytics services already have pipelines that write to S3. Lighthouse's L3 is an S3 compatible API that speaks AWS Signature V4, so the AWS CLI, boto3, rclone and the AWS SDKs work unchanged. Every object response includes its CID in the x-amz-meta-cid header. bash aws s3 cp ./positions-2026-09-18.parquet s3://robinhood-risk/daily/ \ --endpoint-url https://s3.lighthouse.storage Moving the data is a config change, not a migration project, and each dataset gains a content identifier you can cite in reports. --- 5. Gated Research and Partner Data Not all protocol data should be public. Institutional depositors may receive detailed risk reports; integration partners may get pre release parameters. Lighthouse encrypts client side with threshold key management, so you can publish the CID openly while sharing decryption with named addresses, and revoke access when a relationship ends. Chain support note. Condition based gating reads contract state from chains on Lighthouse's Chains Supported list, and Robinhood Chain is not there yet. Address based sharing and revocation work today. For conditions such as "holds at least 1,000 USDG on Robinhood Chain," request support on Discord. --- A Checklist Before Mainnet - Frontend published to IPFS, release CID announced, stable name via IPNS or DNSLink. - Audit reports uploaded and their CIDs recorded in a contract or deployment manifest. - Governance templates that require CIDs for attached specs. - Keeper snapshots archived by CID with events emitted onchain. - Analytics buckets pointed at an S3 compatible, content addressed endpoint. - Sensitive reports encrypted, with an owner for access reviews and revocation. None of this changes your contracts. All of it changes what you can prove when something goes wrong. --- Frequently Asked Questions What DeFi protocols are on Robinhood Chain? At launch: Uniswap (dedicated AMM), Pleiades, Morpho for lending, Lighter and Arcus for perpetuals, Chainlink oracles, LayerZero for cross chain messaging and Paxos USDG. Can I host a dApp frontend on IPFS? Yes. Upload the static build to IPFS with Lighthouse, then use IPNS or DNSLink so a stable name points at the latest release CID. Why store DeFi data by CID? A CID is derived from the content, so it proves a file has not changed. Recording CIDs onchain makes audits, proposals and liquidation data independently verifiable. Does Lighthouse work with S3 tools? Yes, through L3, an S3 compatible API at s3.lighthouse.storage that returns each object's CID. --- Get Started - Lighthouse quick start - L3, the S3 compatible API - IPNS and mutable data - Robinhood Chain developer docs Related reading: Stock Tokens and RWA Documents on Robinhood Chain with Lighthouse Storage. Building a protocol on Robinhood Chain? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
NFT Metadata on Robinhood Chain That Never Breaks
Articlecalendar_todaySep 22, 2026

NFT Metadata on Robinhood Chain That Never Breaks

An NFT is a pointer. If the thing it points at disappears or changes, the token still exists and means nothing. Robinhood Chain is marketed around Stock Tokens and DeFi, but it is a general purpose EVM Layer 2. ERC-721 and ERC-1155 contracts deploy unchanged, gas is paid in ETH, and blocks land every 100 milliseconds. Membership passes, loyalty collectibles, event tickets, trading badges and creator drops all fit naturally on a chain whose distribution runs through a very large consumer brokerage. Every one of those NFTs has the same weak point: the tokenURI. This guide shows how to mint on Robinhood Chain with metadata that stays verifiable and available, using Lighthouse on IPFS and Filecoin. --- How NFT Metadata Breaks An ERC-721 contract stores almost nothing about the item itself. It stores an owner and a tokenURI, and wallets fetch the URI to learn the name, description, image and attributes. The common failure modes, all avoidable: | Failure | What happens | Fix | |---|---|---| | HTTPS URI on a project server | Server goes down, every NFT shows a blank image | Use ipfs:// URIs | | Mutable server path | Project swaps images after mint | Content addressing: the CID changes if bytes change | | Gateway URL baked into the URI | That one gateway goes down or rate limits | Store ipfs://CID, let wallets choose gateways | | Pinned once, never persisted | The only node holding the data stops pinning it | Pinning plus Filecoin deals | | Image on IPFS, JSON on a server | Half decentralized, fully breakable | Put both behind CIDs | IPFS for NFT Metadata: How Token URIs Break covers each case in detail. The short version: both the media and the metadata JSON should be content addressed, and the URI should use the ipfs:// scheme, not a gateway URL. --- The Minting Flow !robinhood-04-diagram.png 1. Upload the media to Lighthouse. Get the image CID. 2. Build the metadata JSON referencing ipfs://<imageCID. Upload it. Get the metadata CID. 3. Mint on Robinhood Chain with tokenURI = ipfs://<metadataCID. 4. Lighthouse keeps the data pinned on IPFS and backed by Filecoin storage deals. Step 1 and 2: Upload media and metadata javascript import lighthouse from "@lighthouse-web3/sdk"; const apiKey = process.env.LIGHTHOUSEAPIKEY; // Media first const image = await lighthouse.upload("./art/founders-pass-001.png", apiKey); const imageCID = image.data.Hash; // Metadata references the media by CID, not by gateway URL const metadata = { name: "Founders Pass 1", description: "Early member pass for the Horizon trading community on Robinhood Chain.", image: ipfs://${imageCID}, attributes: [ { traittype: "Tier", value: "Founder" }, { traittype: "Chain", value: "Robinhood Chain" }, ], }; const meta = await lighthouse.uploadText(JSON.stringify(metadata), apiKey, "founders-pass-001.json"); const tokenURI = ipfs://${meta.data.Hash}; For a full collection, upload a folder with lighthouse.upload("./metadata-folder", apiKey) and use a single directory CID as your base URI, so token 42 resolves at ipfs://<dirCID/42.json. Step 3: The contract solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; contract FoundersPass is ERC721, Ownable { string private baseURI; // "ipfs://<directoryCID/" uint256 public nextId; constructor(string memory base) ERC721("Founders Pass", "PASS") Ownable(msg.sender) { baseURI = base; } function mint(address to) external onlyOwner returns (uint256 id) { id = nextId++; safeMint(to, id); } function baseURI() internal view override returns (string memory) { return baseURI; } } There is deliberately no setBaseURI. Leaving the base URI immutable is a promise to holders that the art cannot be swapped. If your project needs evolving metadata, make that explicit, and consider an IPNS name so the change is a published pointer update rather than a quiet server edit. IPNS or DNSLink? Choosing a Mutable Pointer compares the options. Step 4: Deploy to Robinhood Chain bash forge create src/FoundersPass.sol:FoundersPass \ --rpc-url https://rpc.mainnet.chain.robinhood.com \ --private-key $DEPLOYERKEY \ --constructor-args "ipfs://<directoryCID/" Chain ID 4663 for mainnet, 46630 for testnet. Verify on Blockscout at robinhoodchain.blockscout.com. --- Beyond the Image: Unlockable and Token Gated Content Many consumer NFTs are access passes. The token is public; the thing it unlocks should not be. Lighthouse encrypts files client side before upload and splits the key across independent nodes with BLS threshold cryptography. You then attach conditions that decide who can decrypt: holding an NFT from a collection, holding an ERC-20 balance, a time window, or any custom contract return value. The unlockable file can be a research report, a high resolution original, a video, or a members only playbook. javascript // Holder only content: decrypt if the wallet owns at least one pass const conditions = [ { id: 1, chain: CHAIN, // see chain support note below method: "balanceOf", standardContractType: "ERC721", contractAddress: FOUNDERSPASS, returnValueTest: { comparator: "=", value: "1" }, parameters: [":userAddress"], }, ]; await lighthouse.applyAccessCondition(ownerAddress, unlockableCID, signedMessage, conditions, "([1])"); Chain support note. Robinhood Chain is not yet on the published Chains Supported list for condition evaluation. Until it is, you can share encrypted content directly with holder addresses, or request Robinhood Chain support on Discord. Storage and ipfs:// token URIs work on Robinhood Chain today with no dependency on this. For video unlockables, Serving Video from IPFS Without Buffering covers streaming from Lighthouse gateways. For paid unlocks, Creating a Pay-to-View Model Using Lighthouse Storage shows the pay to view pattern. --- NFT Ideas That Fit Robinhood Chain Trader achievement badges. Soulbound tokens for milestones, with metadata by CID so badge art and criteria cannot be retroactively changed. Stock Token holder passes. A collectible for early holders of a particular tokenized equity, gating a community research vault. Event tickets. Mint tickets, store the ticket art and venue details by CID, and unlock recorded sessions for holders after the event. Agent identity cards. An NFT that represents an AI agent, with its strategy description and track record stored by CID. Pairs with AI Trading Agents on Robinhood Chain Need Verifiable Memory. --- Frequently Asked Questions Can I mint NFTs on Robinhood Chain? Yes. Robinhood Chain is fully EVM compatible, so standard ERC-721 and ERC-1155 contracts deploy with Foundry, Hardhat or any EVM tooling. Where should NFT metadata be stored? On content addressed storage such as IPFS, with persistence backed by Filecoin. Use ipfs:// URIs in the token, not gateway URLs or project server URLs. What happens if my pinning service shuts down? The CID stays valid, and anyone who still holds the data can serve it. With Lighthouse, data is also held in Filecoin storage deals, so it does not depend on one pinning node. Can I update NFT metadata later? Only if your contract allows it. For deliberate updates, use IPNS or a versioned registry so every change is visible and old versions remain verifiable. --- Get Started - Minting NFTs on EVM chains - Upload data - Token gating NFTs - Robinhood Chain: deploy smart contracts Launching a collection on Robinhood Chain? Start on the free tier, 5 GB with no card, or talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
AI Trading Agents on Robinhood Chain Need Verifiable Memory
Articlecalendar_todaySep 22, 2026

AI Trading Agents on Robinhood Chain Need Verifiable Memory

An agent that moves money has to answer one question later: why did it do that? If it cannot show what it read and what it decided, nobody should let it trade. Robinhood calls its chain AI native. The homepage says it plainly: the chain is purpose built for AI agents that trade, swap, lend and transact with tokenized real world assets. Crypto focused Agentic Accounts are rolling out in the US, and at the mainnet launch in London an agent paying with Robinhood's agentic credit card sourced and ordered gifts for the attendees on its own. The chain supplies the execution: 100 millisecond blocks, first come first served ordering, and ERC-4337 accounts with session keys. What it does not supply is the agent's memory. That gap decides whether an autonomous trader can be audited, resumed and trusted, or whether it is a black box with a wallet. --- What Robinhood Chain Gives an Agent | Capability | Why it matters for agents | |---|---| | ERC-4337 account abstraction | The agent operates a smart account, not the owner's private key | | Session keys | Scoped, expiring permissions: specific contracts, specific limits | | Gas sponsorship | The agent does not need to manage ETH balances to act | | 100 ms blocks | Decisions settle fast enough for reactive strategies | | FCFS sequencing | Order depends on arrival time, not priority fee bidding | | Stock Tokens, Uniswap, Morpho, Lighter | Real assets and venues to act on, 24/7 | This is a strong execution layer. An owner can hand an agent a session key that can only trade on specific pools, only up to a limit, and only until Friday. That solves "what can the agent do." It does not solve "what did the agent know when it did it." --- The Three Memory Problems State dies with the process. Most agents keep context in memory or in a local vector database inside a container. Restart the container and the agent forgets its open positions, its reasoning, and the constraints its owner gave it last week. Logs are assertions, not evidence. An agent can write "I read the Q3 earnings summary and the price was 187.40" to a log file. Anyone with access to that file can edit it afterwards. When a trade goes wrong, the log is the first thing questioned. Context is not portable. An agent built in one framework, running on one machine, cannot hand its accumulated knowledge to another runtime without custom export code. Onchain settlement makes these problems more acute, not less. The trade is permanent and public. The reasoning behind it is private and mutable. That asymmetry is exactly what a regulator, an auditor or an unhappy owner will focus on. --- Decision Receipts: Pairing a CID With a Transaction The simplest fix is also the most powerful. Before an agent acts, it writes the inputs and its reasoning to content addressed storage and gets back a CID. Then it acts onchain. Then it records the CID next to the transaction hash. !robinhood-03-diagram.png The result is two independently verifiable facts: - A CID that proves exactly what the agent read and decided. Change a byte and the CID no longer matches. - A transaction hash on Robinhood Chain that proves what it did. Together they are a decision receipt. The log stops being a claim and becomes evidence that someone who was not there can check. javascript import lighthouse from "@lighthouse-web3/sdk"; async function tradeWithReceipt(agent, intent) { // 1. Snapshot inputs and reasoning before acting const receipt = { agent: agent.address, strategy: agent.strategyVersion, inputs: intent.inputs, // price feeds, filings, signals the agent read reasoning: intent.rationale, // model output that justified the trade order: intent.order, createdAt: new Date().toISOString(), }; const { data } = await lighthouse.uploadText( JSON.stringify(receipt), process.env.LIGHTHOUSEAPIKEY, receipt-${Date.now()}.json ); // 2. Execute on Robinhood Chain through the agent's session key const txHash = await agent.smartAccount.sendUserOperation(intent.order.calls); // 3. Link the two: CID of the reasoning, hash of the action await agent.journal.record({ cid: data.Hash, txHash }); return { cid: data.Hash, txHash }; } You can go one step further and emit the CID onchain in the same user operation, for example as calldata to a small journal contract. That costs a little gas and makes the link itself immutable and publicly indexed. --- Memory That Survives Restarts: Lighthouse Memory Receipts cover individual decisions. An agent also needs working memory: what its owner told it, what it has learned, which positions it holds and why. Lighthouse Memory gives agents three primitives, remember, recall and forget, with each memory persisted as a blob addressed by an IPFS compatible CID. - Resumes anywhere. Memory lives on the network, not in the container. Rebuild the entire store on a fresh machine from nothing but an API key. - Semantic recall stays local. An in process embedding model ranks memories by a hybrid of similarity and keyword or tag overlap. No second API key, and no embedding data leaves the machine. - Every flush is a backup. Pending memories batch into a single blob that carries the new records and a full index snapshot. - Works over MCP. A bundled Model Context Protocol server exposes memory as tools to Claude Code, Claude Desktop and any MCP capable runtime. In practice, the agent's system prompt tells it to remember owner constraints ("never hold more than 20 percent in one Stock Token") and to recall them before every order. When the agent migrates from a laptop prototype to a production server, the constraints come with it. One limitation to hear from us first: Memory blobs are currently stored unencrypted, so anyone with a CID can read them. Keep secrets, keys and personal data out of Memory for now. Encrypted memory follows our encrypted upload support. For sensitive receipts, use encrypted uploads instead, covered below. Walrus for AI Agents: Storage Shaped Like Agent Workloads goes deeper on why agent read and write patterns favor the Walrus backend for Memory. --- Private Strategy, Auditable Outcome A trading agent's reasoning is often commercially sensitive. Publishing it to public IPFS would hand the strategy to competitors. The answer is to encrypt the receipt and share it selectively. With Lighthouse encrypted uploads, the file is encrypted client side and its key is split across independent key nodes with threshold cryptography. The CID is still public and still anchors the receipt onchain, so integrity is verifiable by anyone. Contents are readable only by parties you name, such as the account owner and an auditor. Access can be revoked later. That gives you the combination regulated finance needs: everyone can verify the record exists and has not changed, and only authorized parties can read it. --- Patterns Worth Building on Robinhood Chain Owner facing agent dashboards. Every trade in the UI links to its receipt CID. The owner clicks through to see exactly what the agent read. Strategy versioning. Store each strategy prompt and parameter set by CID. A receipt that references strategyCID proves which version of the strategy produced the trade. Multi agent desks. A research agent writes filing summaries to storage; an execution agent recalls them. Each handoff is a CID, so a bad trade can be traced to the input that caused it. Evaluation datasets. Replay historical receipts against a new model version to compare decisions before promoting it. Storing AI Training Data on Filecoin: Provenance You Can Prove covers dataset provenance. Compliance archives. Receipts retained on the Filecoin path with deal proofs, for records that must be kept for years and read rarely. --- Frequently Asked Questions Is Robinhood Chain built for AI agents? Yes. Robinhood describes it as an AI native Layer 2 purpose built for agents that trade, swap, lend and transact with tokenized real world assets. ERC-4337 accounts with session keys and gas sponsorship make agent wallets practical. Where should an AI trading agent store its memory? Outside the process, in persistent storage the agent can rebuild from. Lighthouse Memory stores each memory as a CID addressed blob on Walrus or Filecoin and exposes it over MCP. What is a decision receipt? A record of an agent's inputs and reasoning stored by CID before it acts, paired with the transaction hash of the action. It lets anyone verify what the agent knew when it traded. Can agent reasoning stay private? Yes. Upload receipts encrypted and share them with named parties. The CID still proves integrity without revealing contents. --- Get Started - Memory introduction - Connect agents via MCP - Upload encrypted data - Robinhood Chain developer docs For the wider stack, read What Is Robinhood Chain and Where Lighthouse Fits In. Building an agent on Robinhood Chain? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Stock Tokens and RWA Documents on Robinhood Chain with Lighthouse Storage
Articlecalendar_todaySep 22, 2026

Stock Tokens and RWA Documents on Robinhood Chain with Lighthouse Storage

A tokenized stock is a promise about something offchain. The promise is only as good as the documents behind it, and those documents usually live on one company's web server. Robinhood Chain launched with Stock Tokens trading 24/7 for eligible users in more than 120 countries. The token moves in 100 millisecond blocks. The paperwork that defines what the token is does not move at all, and in most tokenization stacks nobody can prove which version of that paperwork a holder saw. This post covers the document layer of real world asset (RWA) tokenization on Robinhood Chain: which files matter, why hosting them on ordinary servers undercuts the point of putting the asset onchain, and how to fix it with content addressed, encrypted storage from Lighthouse. --- What Is Actually Offchain in a Tokenized Asset On Robinhood Chain, Stock Tokens are tokenized debt securities issued by Robinhood Assets (Jersey) Limited that track the price of an underlying equity. Any RWA issuer on the chain, whether for equities, treasuries, credit or real estate, carries a similar pile of documents that never touch the ledger: | Document | Who needs it | Public or private | |---|---|---| | Prospectus or offering memorandum | Every holder, regulators | Public | | Terms and risk disclosures | Every holder | Public | | Corporate action notices (splits, dividends, renames) | Holders, integrators, oracles | Public | | Custody and reserve attestations | Holders, auditors | Public or restricted | | NAV or pricing reports | Lending protocols, holders | Public or restricted | | KYC and eligibility packets | Issuer, transfer agent, reviewers | Private | | Legal agreements with counterparties | Named parties only | Private | Every row is a file. None belongs in contract storage. And every row has a question attached that onchain settlement cannot answer: is this the same file it was yesterday? --- The Problem With a URL A typical RWA contract exposes something like documentURI() returning https://issuer.example/docs/terms.pdf. That design has three failures. The file can change silently. The URL stays the same while the PDF behind it is replaced. A holder who bought under version one has no onchain record that version one existed. The link can die. Domains lapse, CMS migrations rename paths, and the token outlives the website. Access is all or nothing. A public URL cannot express "only verified holders can read the attestation" or "this counterparty sees their agreement and nobody else does." A content identifier fixes the first two outright. Encryption with onchain conditions fixes the third. --- The Pattern: Document Registry With CIDs !robinhood-02-diagram.png 1. The issuer uploads each document through Lighthouse and receives a CID. 2. The CID is written to a document registry contract on Robinhood Chain, keyed by asset and document type, with a timestamp from the block. 3. Wallets, explorers, lending protocols and auditors read the CID from the registry and fetch the file from any IPFS gateway. 4. Anyone can hash what they fetched and confirm it matches the CID. No trust in the issuer's server required. A minimal registry looks like this: solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.24; contract AssetDocumentRegistry { struct Doc { string cid; // Lighthouse CID of the document uint64 publishedAt; } address public issuer; // assetId = docType (e.g. keccak256("PROSPECTUS")) = version history mapping(bytes32 = mapping(bytes32 = Doc[])) private docs; event DocumentPublished(bytes32 indexed assetId, bytes32 indexed docType, string cid, uint256 version); constructor() { issuer = msg.sender; } function publish(bytes32 assetId, bytes32 docType, string calldata cid) external { require(msg.sender == issuer, "not issuer"); docs[assetId][docType].push(Doc(cid, uint64(block.timestamp))); emit DocumentPublished(assetId, docType, cid, docs[assetId][docType].length - 1); } function latest(bytes32 assetId, bytes32 docType) external view returns (Doc memory) { Doc[] storage h = docs[assetId][docType]; require(h.length 0, "none"); return h[h.length - 1]; } function history(bytes32 assetId, bytes32 docType) external view returns (Doc[] memory) { return docs[assetId][docType]; } } The history array is the point. Updating a disclosure does not overwrite anything. It appends a new CID, and every previous version remains addressable and verifiable. When someone asks "what were the terms when I bought on August 3rd," the answer is a block number and a CID, not a support ticket. On the upload side: javascript import lighthouse from "@lighthouse-web3/sdk"; const { data } = await lighthouse.upload("./nvda-token-terms-v3.pdf", process.env.LIGHTHOUSEAPIKEY); await walletClient.writeContract({ address: REGISTRY, abi: registryAbi, functionName: "publish", args: [assetId, keccak256(toBytes("TERMS")), data.Hash], chain: robinhoodChain, // chain ID 4663 }); --- Keeping Documents Alive Content addressing proves integrity. It does not by itself guarantee the bytes stay available. That is the job of the storage network underneath. On the Filecoin path, Lighthouse places documents into storage deals where providers submit ongoing cryptographic proofs that they still hold the data. Deals have terms and Lighthouse manages renewal, which is covered in What Happens When a Filecoin Deal Expires?. For regulated documents that must be retained for years, that proof trail is useful in its own right: you can show an auditor not only what the document said, but that it has been continuously stored. On the Walrus path, documents are erasure coded across many nodes for fast reads, which suits documents that wallets and apps fetch constantly, such as token terms displayed at purchase. Pick per document. Frequently displayed disclosures lean toward Walrus. Archival records lean toward Filecoin. Walrus vs Filecoin: Erasure Coding or Replication? has the tradeoffs. --- Private Documents: KYC, Agreements and Attestations Not every RWA document should be public, and "decentralized" does not mean "private." Anything uploaded to IPFS unencrypted is readable by anyone who has the CID. Is IPFS Private? What Content Addressing Hides, and What It Doesn't explains exactly what leaks. Lighthouse encrypts files client side before upload. The key is split with BLS threshold cryptography across independent key nodes, so no single node, including Lighthouse, ever holds the whole key. Then you decide who can decrypt: - Named addresses. Share a KYC packet with the transfer agent's address and the compliance reviewer's address, each independently. - Revocation. When a review relationship ends, revoke that party's access. The file does not move and its CID does not change. - Conditions. Gate a reserve attestation on holding the token, or on the return value of an eligibility contract that returns true only for verified wallets. javascript // Encrypt and share a KYC packet with two named reviewers const { data } = await lighthouse.uploadEncrypted( "./kyc-packet-0x7a2.pdf", process.env.LIGHTHOUSEAPIKEY, issuerAddress, signedMessage ); const cid = data[0].Hash; await lighthouse.shareFile(issuerAddress, [transferAgent, complianceReviewer], cid, signedMessage); // Later, when the engagement ends await lighthouse.revokeFileAccess(issuerAddress, [complianceReviewer], cid, signedMessage); Chain support note. Conditions that read contract state need the chain on Lighthouse's Chains Supported list, and Robinhood Chain is not listed yet. Encryption, named address sharing and revocation work today regardless of chain. To gate on Robinhood Chain contracts directly, ask the team on Discord. --- Why This Matters for Stock Tokens Specifically Stock Tokens can be used as collateral in lending pools. That means a lending protocol, not just a holder, is making decisions based on what the token represents. When a corporate action such as a stock split changes the token's terms, every integrator needs the same answer at the same time, and they need to be able to prove later which notice they acted on. A CID in a registry event gives them that. The oracle reports the price. The registry reports the document. Both are onchain, and both can be verified by someone who was not in the room. --- Frequently Asked Questions What are Robinhood Stock Tokens? Stock Tokens are tokenized debt securities issued by Robinhood Assets (Jersey) Limited that track equities such as NVIDIA, Apple and Google. They trade 24/7 on Robinhood Chain for eligible users outside the US. Where should RWA documents be stored? In content addressed storage such as IPFS with Filecoin or Walrus persistence, with the CID recorded onchain. This makes every document version tamper evident and independently retrievable. Can KYC documents be stored on IPFS? Only encrypted. Lighthouse encrypts client side with threshold key management, so the stored file is unreadable without an authorized key reconstruction. How do I update a document without breaking references? Upload the new version, then append its CID to the registry. Old versions stay addressable. For a single stable pointer, use IPNS, described in IPNS or DNSLink? Choosing a Mutable Pointer. --- Get Started - Create an API key - Upload encrypted data - Share and revoke access - Check Filecoin deal status New to the chain itself? Start with What Is Robinhood Chain and Where Lighthouse Fits In. Issuing RWAs and need a document layer? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn. !cover.png

5 min readarrow_forward
What Is Robinhood Chain and Where Lighthouse Fits In
Articlecalendar_todaySep 22, 2026

What Is Robinhood Chain and Where Lighthouse Fits In

Robinhood Chain moves stocks, stablecoins and agents onchain. Everything those assets need to be trusted, from disclosures to images to agent logs, still has to live somewhere. That is the job Lighthouse does. On July 1, 2026, at its "The World is Flat" event in London, Robinhood launched the public mainnet of Robinhood Chain. It arrived with Stock Tokens trading 24/7, a dedicated Uniswap deployment, perpetuals from Lighter, lending from Morpho, and a stated ambition to be the chain where AI agents trade real world assets. Most coverage stopped at the trading. This post covers what builders need: what the chain actually is, how it differs from the Layer 2s you already know, and which piece of the stack is missing from the launch announcement. --- Robinhood Chain at a Glance | | Robinhood Chain | |---|---| | Type | Ethereum Layer 2, permissionless | | Stack | Arbitrum technology (Arbitrum Dedicated Blockchains, formerly Orbit) | | Mainnet | Live since July 1, 2026 | | Public testnet | February 2026 | | Mainnet chain ID | 4663 | | Testnet chain ID | 46630 | | Gas token | ETH, no native token | | Block time | 100 ms | | Sequencing | First come, first served | | Account abstraction | First class ERC-4337, with gas sponsorship and session keys | | Explorer | robinhoodchain.blockscout.com | | Core partners | Alchemy, LayerZero, Chainlink, Uniswap, Morpho, Lighter, Paxos (USDG) | Three things in that table matter more than they look. ETH for gas, no native token. Robinhood did not launch a token to pay for blockspace. Fees are paid in ETH, the same as Arbitrum One and Base, which means every existing EVM wallet and tool works without special handling. First come, first served sequencing. Transaction order is decided by arrival time at the sequencer, not by who bids the highest priority fee. For a chain built around trading tokenized equities, that is a deliberate choice against the priority auctions that make MEV extraction easy. First class account abstraction. ERC-4337 support with gas sponsorship and session keys is what makes AI agents practical. An agent can hold a session key scoped to specific actions and a spending limit, and never touch the owner's main key. --- What Actually Runs on Robinhood Chain Stock Tokens. Tokenized exposure to equities such as NVIDIA, Apple and Google. They are tokenized debt securities issued by Robinhood Assets (Jersey) Limited, available to eligible users in more than 120 countries through Robinhood Wallet. They are not available in the United States and are restricted in several other jurisdictions. Onchain, they can be traded around the clock, deposited into lending pools, and used as collateral. DeFi primitives. Uniswap deployed a dedicated AMM as the primary public liquidity venue. Morpho handles lending. Lighter and Arcus bring perpetuals. Chainlink supplies oracles and LayerZero carries cross chain messaging. Paxos issues USDG as a native dollar stablecoin. AI agents. Robinhood describes the chain as AI native and "purpose built for AI agents" that trade, swap, lend and transact with tokenized assets. Crypto focused Agentic Accounts are rolling out in the US. For a developer, none of this requires new tooling. Hardhat, Foundry, viem, ethers and Wagmi all work. Add the network and deploy. javascript // viem chain definition for Robinhood Chain mainnet import { defineChain } from "viem"; export const robinhoodChain = defineChain({ id: 4663, name: "Robinhood Chain", nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 }, rpcUrls: { default: { http: ["https://rpc.mainnet.chain.robinhood.com"] }, }, blockExplorers: { default: { name: "Blockscout", url: "https://robinhoodchain.blockscout.com" }, }, }); --- The Piece the Launch Did Not Cover A blockchain is a very good ledger and a very bad hard drive. Writing 1 MB of data into contract storage on any EVM chain costs a large amount of gas, and nobody reads files from a state trie anyway. Yet almost everything that makes an onchain financial asset trustworthy is a file: - The disclosure document behind a Stock Token. - The corporate action notice that changes its terms. - The image and metadata of an NFT. - The frontend a user signs transactions through. - The trade log an AI agent produced before it moved money. - The KYC packet a counterparty reviewed. If those files live on a single company's server, the onchain asset inherits that server's weaknesses. The link can rot, the file can be quietly edited, and nobody can prove what a user saw at the moment they signed. The fix is a pattern every serious EVM team ends up at: store the bytes in content addressed storage, and store only the content identifier onchain. !robinhood-01-diagram.png --- How Lighthouse Plugs Into Robinhood Chain Lighthouse is a storage layer across IPFS, Filecoin and Walrus with client side encryption and programmable access control. For a Robinhood Chain app, it covers four jobs. 1. Content addressed files, anchored onchain Upload a file and you receive a CID, a fingerprint derived from the bytes themselves. Change a single byte and the CID changes. Store that CID in your Robinhood Chain contract and you have an onchain commitment to exactly one version of the file. If you are new to CIDs, What Is a CID? Content Identifiers, v0 vs v1, and How to Read One covers how to read one. javascript import lighthouse from "@lighthouse-web3/sdk"; // 1. Upload the document and get its CID const res = await lighthouse.upload("./disclosure-2026-q3.pdf", process.env.LIGHTHOUSEAPIKEY); const cid = res.data.Hash; // 2. Anchor the CID in your Robinhood Chain contract await walletClient.writeContract({ address: REGISTRYADDRESS, abi: registryAbi, functionName: "publishDocument", args: [assetId, cid], chain: robinhoodChain, }); Note the ordering. Contracts cannot initiate uploads. Your application uploads through Lighthouse, gets the CID, then writes the CID to the chain. 2. Persistence you can verify Files on the Filecoin path are backed by storage deals with onchain proofs, so "is my file still there" is something anyone can check rather than a promise. How to Verify Your File Is Actually Stored on Filecoin walks through it. Files on the Walrus path get erasure coded blob storage with fast reads. 3. Encryption before the file leaves the client Public IPFS is not private. Anyone with a CID can fetch the bytes, which is fine for an NFT image and unacceptable for a KYC document. Lighthouse encrypts client side through Kavach, splits the key with BLS threshold cryptography across independent key nodes, and never holds a complete key. Lighthouse cannot read your files, and neither can storage providers. 4. Access control driven by onchain state Decryption can be gated on ERC-20 balances, NFT ownership, native balances, time windows, or the return value of any custom contract. That is how token gated research, holder only documents and pay to view content get built. Chain support note. Access conditions are evaluated by Lighthouse key nodes against chains they are configured to read. Robinhood Chain is not yet on the published Chains Supported list. Storage, CIDs, encryption and address based sharing work today on any chain. For conditions that read Robinhood Chain contracts directly, reach out on Discord; adding a chain is a configuration request, not a new product. --- What to Build First Stock Token and RWA data rooms. Disclosures, prospectuses and corporate actions stored by CID, with the CID written to a registry contract. Covered in depth in Stock Tokens and RWA Documents on Robinhood Chain with Lighthouse Storage. AI agents with receipts. Agents that record what they read and why they traded, as CIDs, so every action can be audited later. See AI Trading Agents on Robinhood Chain Need Verifiable Memory. NFTs that do not break. Metadata and media on IPFS and Filecoin, referenced by ipfs:// URIs. See NFT Metadata on Robinhood Chain That Never Breaks. DeFi apps with decentralized frontends. Frontends, oracle snapshots and governance documents hosted by CID. See Building DeFi Apps on Robinhood Chain with Decentralized Storage. --- Frequently Asked Questions What is Robinhood Chain? Robinhood Chain is a permissionless Ethereum Layer 2 built by Robinhood on Arbitrum technology. It is designed for financial services, tokenized real world assets such as Stock Tokens, and AI agents. Mainnet launched on July 1, 2026. What is the Robinhood Chain chain ID? Mainnet is 4663. Testnet is 46630. Does Robinhood Chain have its own token? No. Gas is paid in ETH. Can I store files on Robinhood Chain? You can, but storing file bytes in contract storage is extremely expensive. The standard pattern is to store the file with a service such as Lighthouse on IPFS, Filecoin or Walrus, and store the resulting CID onchain. Is Lighthouse storage private? Only if you encrypt. Lighthouse offers client side threshold encryption, so encrypted files stay unreadable to Lighthouse and to storage providers. Unencrypted uploads to IPFS are public. How much does it cost to start? Lighthouse has a free tier of 5 GB on the Filecoin path and 100 MB on the Walrus path, with no card required. --- Get Started - Create a Lighthouse API key - Upload data - Upload encrypted data - Access control conditions - Robinhood Chain developer docs Building on Robinhood Chain and need storage your contracts can point at? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Lighthouse Monthly Update - September 2026
Articlecalendar_todaySep 15, 2026

Lighthouse Monthly Update - September 2026

Lighthouse Monthly Update – September 2026 The month we wrote down everything we know. August was quiet on the timeline and loud everywhere else. We expanded the blog into a proper reference library and shipped the Base integration that lets an agent pay for its own storage. Not every month is a launch. Some months are the documentation you should have written two years ago. Here is the month, and what September looks like from here. --- Main Spotlight: New Writing, Organised Properly !image.png We added a batch of new posts this month and grouped the blog into categories that actually match how people arrive at it. Walrus. What it is, how epochs and renewal work, blob IDs against CIDs, blobs as Move objects on Sui, using Walrus without running Sui infrastructure, and migrating from IPFS without changing your CIDs. IPFS. What a CID is, why yours will not load, whether files disappear, whether IPFS is private, pinning existing CIDs, IPNS against DNSLink, and why NFT token URIs break. Filecoin. Deal mechanics, the two proofs, what happens when a deal expires, verifying a file is genuinely stored rather than merely retrievable, and what storage actually costs in 2026. Comparisons. Walrus against Filecoin. Filecoin against S3. Filecoin against Arweave. The pinning services against each other, ourselves included. The comparisons are the ones worth your time, because each names where we lose. Direct Walrus access beats us on cost per byte. S3 beats us on latency and tooling maturity. Arweave beats us if you want one payment and no renewal process to forget. Pinata has the larger integration ecosystem. A comparison that concludes "use us" for every reader is not a comparison. It is a brochure with a table in it. Read the library: https://lighthouse.storage/blogs --- Lighthouse x Base: Storage That Agents Can Pay For Themselves !image (1).png Base solved how machines settle payments. We solved where their data lives. x402 joins the two. Four moves. A client posts a file. The server returns HTTP 402 with a price sized to the file. The client pays USDC on Base automatically. It retries with proof of payment and receives a CID. What comes back is two independently checkable facts. A CID proving what was stored, and a transaction hash on Base proving what was paid. For anything that has to be defensible later, that pairing is the audit trail. x402 works on both storage paths. IPFS and Filecoin through the pay per use endpoint, and Walrus through a hosted endpoint, so an agent can pay in USDC on Base for storage. Reference: https://x.com/LighthouseWeb3/status/2089344225813143933 --- The Thesis: Three Properties, and the One Everybody Skips !image (2).png In 1956, five megabytes of disk was the size of a fridge. In 2025, the world created, captured and replicated 173 zettabytes. The next stretch of that curve does not get written by people. Agents are already writing memory, receipts and state at machine speed, and most of it has to outlive the process that produced it. That data has to persist, stay verifiable, and stay unreadable to whoever is holding it. The third is where infrastructure quietly breaks, because decentralized and private get used as though they were the same property. They are not related at all. IPFS has no access control in the retrieval path. Filecoin and Walrus store whatever bytes they are handed, plaintext included. Kavach is our answer. Files are encrypted client side before anything leaves. The key is split with BLS threshold cryptography across independent nodes, so no single node holds a complete key. Reconstruction requires a threshold of nodes to each independently check the requester against conditions you defined, on live chain state, before releasing a share. The consequence is structural rather than contractual. We cannot read your files. Storage node operators cannot read your files. There is no plaintext and no complete key sitting there to take. That is a different sentence from "we promise not to look." Reference: https://x.com/LighthouseWeb3/status/2086688216535757099 --- Ecosystem Mentions Kumami World. We announced a partnership on 16 August, positioning Lighthouse as the storage layer for their builders with client side encryption on the IPFS path. !image (3).png Reference: https://x.com/kumamiworld/status/2088929168826540505 Base Daily Recap. The x402 integration ran in the 18 August roundup, framed as agents paying for decentralized storage in USDC. !image (4).png Reference: https://x.com/gumterver100/status/2089618137251492101 --- What Comes Next Deeper Walrus integration. Phase one covered the write path and the SDK. Next comes retrieval performance and availability guarantees, with the same rule holding. Your CIDs do not change and your code does not move. More backends, one interface. Developers should not have to pick a storage network the way they pick a religion. Write once, choose the backend that fits the workload, change your mind later without breaking a reference. x402 everywhere it fits. The path works today. Next step is making it the obvious default for anything autonomous rather than something you go looking for. --- One More Thing An agent that loses state cannot be trusted with anything longer than a session. An agent that cannot prove what it read cannot be audited. And an agent whose memory anyone can read is not carrying memory, it is carrying a liability. We have been building against all three. !image (5).png More soon. --- Wrapping Up August did not look like much from outside. One integration, a quiet timeline. What actually happened is that we wrote down what we know, published the comparisons that make us look worse where we are worse, and shipped the payment layer that lets an agent buy its own storage without asking anyone. Documentation is not a growth tactic. It is what you have instead of one when the thing you sell has to be trusted for years. The stack got clearer underneath without asking builders to change a line.

5 min readarrow_forward
How Walrus Erasure Coding Works, and Why Overhead Is About 5x
Articlecalendar_todayAug 22, 2026

How Walrus Erasure Coding Works, and Why Overhead Is About 5x

Walrus splits each blob into encoded slivers spread across storage nodes, and can reconstruct the original from a subset of them. That gives resilience comparable to keeping many full copies, at roughly 5x the original blob size instead. The number is the point. Replication-based durability multiplies your storage cost by the number of copies. Erasure coding buys similar fault tolerance for a fraction of that, and reads get faster rather than slower as a side effect. --- Replication, and why it is expensive The obvious way to survive node failure is to keep several complete copies. Simple, robust, and the arithmetic is brutal: surviving the loss of many nodes means storing many full copies, and your cost scales linearly with the failure tolerance you want. It also wastes the network's aggregate capacity. Every node holding a complete copy is storing bytes that dozens of other nodes are also storing. Erasure coding, in one paragraph Take the blob. Encode it into fragments — Walrus calls them slivers — such that the original can be rebuilt from some of them rather than all. Distribute the slivers across storage nodes. The redundancy lives in the encoding rather than in duplication. Lose a substantial fraction of the slivers and reconstruction still succeeds, because any sufficient subset carries enough information to recover the whole. Walrus is designed so a blob remains reconstructable even when a large share of slivers are missing. Total storage across the network is roughly 5x the original blob size. That is the redundancy, and it is far below what equivalent replication would cost. Why reads get faster The consequence people miss. With replication, a read goes to a node holding a copy, and you get that node's bandwidth. With erasure coding, a client fetches slivers from many nodes simultaneously and decodes. You get aggregate bandwidth from many machines rather than the throughput of whichever single node you happened to reach. There is also no unsealing step. Filecoin's sealed replicas must be decoded before serving — that cost is what makes its proofs credible, and it is why cold retrieval is slow. Walrus slivers are ready to be fetched and combined. Fast reads are not a bolt-on optimisation; they fall out of the storage design. --- The trade Nothing is free, and the honest ledger: More coordination. Reads and writes touch many nodes rather than one. That requires the network to agree on which nodes hold which slivers for which blob, which is what Sui provides — registration, payment and committee coordination on chain. Encoding and decoding cost CPU. Modest, and paid at both ends. Guarantees are about availability, not continuous proof. Walrus assures reconstructability through encoding and committee structure. Filecoin's PoRep and PoSt produce a continuous public record that a specific provider still holds a specific replica, with collateral at risk. If you need evidence to hand an auditor or regulator, that record is the stronger artifact. See proof of replication and proof of spacetime. Higher price per gigabyte than Filecoin in practice, which reflects being optimised for serving rather than for archival economics. --- Compared | | Full replication | Walrus erasure coding | |---|---|---| | Storage overhead | Multiplies with copies | 5x total | | Failure tolerance | Survives losing all but one copy | Survives losing a large share of slivers | | Read path | One node's bandwidth | Parallel fetch, many nodes | | Decode cost | None | Modest CPU | | Coordination needed | Low | Higher; handled on Sui | --- What it means for your architecture Large binary objects are the sweet spot. The economics and the parallel read path both favour big blobs: media, model weights, datasets, game assets. Very small objects carry proportionally more coordination overhead. Read-heavy workloads win most. If content is written once and read constantly, the parallel read path is a direct product improvement. If it is written once and read almost never, you are paying a premium for retrieval performance nobody experiences — put it on Filecoin instead. Walrus vs Filecoin has the decision framework and the current prices. Retention is still a term. Erasure coding is about how data is stored, not how long. Walrus retention is epoch-based and renewable — see Walrus epochs and renewal. You do not implement any of this. Through Lighthouse, encoding, sliver distribution and reconstruction happen underneath an ordinary upload call that returns a CID. The reason to understand it is to know what you are buying and when it is the right purchase. --- Get Started - Introduction to IPFS and Walrus - Upload data - Quick start - Pricing - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Walrus for AI Agents: Storage Shaped Like Agent Workloads
Articlecalendar_todayAug 22, 2026

Walrus for AI Agents: Storage Shaped Like Agent Workloads

Agents do not use storage the way people do. They read and write continuously, in small operations, at machine pace, with no human waiting to click save. Walrus is built for exactly that access pattern. Most storage is designed around human upload behaviour: occasional writes, occasional reads, long idle periods. Autonomous systems break that assumption immediately, and the mismatch shows up as latency and cost in places nobody planned for. --- What an agent's storage pattern looks like Continuous, not occasional. An agent working a long task reads context, writes intermediate results, reads them back, and writes again — for the duration of the task. There is no idle period. Small and frequent, not large and rare. A person uploads a 2 GB video once a week. An agent writes a few kilobytes of state a hundred times an hour. Latency-sensitive in a compounding way. A human waiting 400ms for a file notices nothing. An agent making a thousand sequential reads inside one task turns 400ms into a stall long enough to change what the system can do at all. Machine-paced and unattended. Nothing pauses for approval. Storage that requires a human to intervene — to fund something, to approve something, to renew something — is a system that halts at 3am. Walrus suits the first three directly: erasure coding means reads pull slivers from many nodes in parallel with no unsealing step, so retrieval is fast and stays fast under continuous load. See how Walrus erasure coding works. --- The three properties agents actually need Verifiable state. An agent that cannot prove what it read cannot be audited. Content addressing gives every artifact a CID derived from its bytes, so any later alteration is detectable. Record the CID in the agent's log and the log stops being an assertion and becomes evidence — a claim about inputs that somebody who was not there can check. This is the difference between "the agent says it read the March figures" and "here is the CID of what it read, verify it yourself." Confidential state, scoped per agent. Multi-agent systems share a store, and rarely should every agent read everything. Client-side encryption with on-chain access conditions lets several agents work over shared state while each reads only what its conditions permit — enforced by contract rather than by convention or by a policy layer you have to write. Memory that outlives the process. The most consequential one, and the subject of the next section. Memory An agent that loses state cannot be trusted with anything longer than a session. Memory gives agents remember, recall and forget primitives, with each memory persisted as a verifiable blob addressed by an IPFS-compatible CID. Because memory lives on the network rather than inside one process, an agent resumes across sessions, machines and runtimes. The entire store rebuilds on a fresh machine from nothing but an API key — which is a meaningfully different operational posture from a local vector database that dies with the container. Semantic recall runs locally with an in-process embedding model. No additional API key, and no embedding data leaves the machine. Queries rank memories by a hybrid of cosine similarity and keyword or tag overlap, across both flushed and pending memories. Writes are batched: pending memories buffer locally and flush as a single batch blob carrying both the new records and a full index snapshot, so every flush doubles as a backup. Recovery rebuilds the local index from the newest batch blob, or by re-reading every memory blob. Memory runs on either backend. ipfs-walrus is the default, served from gateway-walrus.lighthouse.storage, with Walrus blob IDs exposed; ipfs-filecoin is available for workloads where archival economics matter more than read speed. A bundled Model Context Protocol server exposes all of it as tools to Claude Code, Claude Desktop and any MCP-capable runtime, so an agent reads and writes storage as a native capability rather than through bespoke integration code. One limitation to hear from us rather than discover: Memory blobs are currently stored unencrypted, and anyone with the CID can read them. Do not put secrets in Memory. Encrypted memory follows our encrypted upload support. The encryption described elsewhere in this post applies to file uploads today, not to Memory. --- Patterns worth building Memory across sessions and machines, so an agent resumes context instead of restarting. Decision receipts. A CID recorded at the moment of an action proves the record was not altered afterwards. For anything regulated, the question is not only what an agent did but whether the account of it can be trusted. Evaluation datasets under conditions. Share a benchmark with specific parties, revocably, and prove it has not been edited since results were published. Multi-agent shared state, scoped per agent by on-chain conditions. Artifact persistence for long workflows, where intermediate outputs must survive a process restart. --- Choosing the backend Walrus when the agent reads and writes continuously and latency compounds — which is most interactive and long-running agent work. Filecoin when the volume is archival: retained decision logs, historical datasets, records kept for compliance and read almost never. Cheaper per terabyte, and nothing is waiting on the read. Walrus vs Filecoin has the numbers. Because both sit behind the same interface with the same CIDs, that decision is reversible once you have real traffic rather than a guess. --- Get Started - Memory introduction - Connect agents via MCP - Choose a network - Rebuild and recovery - Memory source on GitHub --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Three Ways to Store on Walrus, Compared
Articlecalendar_todayAug 22, 2026

Three Ways to Store on Walrus, Compared

Go direct if you are a Sui-native team that wants protocol-level control. Use a Walrus-native product if Walrus is the whole story and you want the shortest path. Use an aggregator if you want Walrus as one backend among several behind a stable interface. We are the third option, so read accordingly. We have tried to be specific about where the first two win, because a comparison that concludes "use us" for every reader is not a comparison. --- Option 1: Direct Talk to Walrus yourself through its client CLI, JSON or HTTP APIs, with your own Sui wallet and infrastructure. You get: full protocol control, the lowest cost per byte, no intermediary dependency, and direct access to storage objects on Sui for Move contracts. You take on: a funded Sui wallet with production key management, acquiring and holding SUI, blob registration and payment, epoch tracking and renewal per blob, and Walrus blob IDs as your identifier scheme. Choose it when you are Sui-native with wallet infrastructure and Move expertise already in place, storage is core enough to justify owning the operational surface, or you are building Walrus-native tooling where an abstraction layer would be in the way. Do not choose it if your application has nothing to do with Sui, or if nobody on the team wants to own epoch bookkeeping in eighteen months. Option 2: A Walrus-native product Products like Tusky are built specifically around Walrus, with the interface and features shaped entirely by that one network. You get: a focused product that does not compromise its design to accommodate other backends, and typically the fastest path from zero to storing something. You take on: Walrus as your storage strategy. If your requirements later include archival volume at a lower price point, or you need continuous storage proofs for an auditor, that means adopting a second vendor rather than changing a parameter. Choose it when Walrus is definitively the right backend for your workload and you want the most direct route to using it well. Option 3: An aggregator Walrus as one backend behind an interface that also covers IPFS and Filecoin. That is what we do. You get: CIDs rather than only blob IDs, so references stay portable; the ability to move data between Filecoin and Walrus without changing identifiers; one API, one key, one bill across networks; managed epoch renewal; encryption and access control as part of the platform; and stablecoin or card payment with no SUI to hold. You take on: a dependency on us in addition to the network, and a higher cost than raw protocol access. Choose it when you are not certain which backend is right — which is most teams before they have production traffic — or when you need both archival economics and fast reads for different data, or when encryption and on-chain access control matter, or when your application lives outside the Sui ecosystem. --- Side by side | | Direct | Walrus-native product | Aggregator | |---|---|---|---| | Sui infrastructure required | Yes | Usually no | No | | Hold SUI | Yes | Depends | No | | Identifier | Blob ID | Product-defined | CID, blob ID available | | Epoch renewal | Yours | Usually managed | Managed | | Other backends | No | No | IPFS, Filecoin | | Backend migration | N/A | Vendor change | Identifiers preserved | | Cost per byte | Lowest | Middle | Higher | | Move object access | Direct | Varies | Via blob ID | | Encryption | Bring your own | Varies | Built in | --- The question that decides it Not price, and not features. Ask: how confident are you that Walrus is the right backend for this data in two years? If the answer is very — you have measured the workload, reads are frequent, latency matters, you are on Sui — then commit. Direct or a Walrus-native product will both serve you well, and you should choose between them on whether you want to operate the Sui side. If the answer is less certain, the portability of content addressing is worth paying for. Data that starts on Walrus and turns out to be a cold archive can move to Filecoin without invalidating a single reference, because CIDs survive the migration. Reversibility has real option value while you are still learning what your access patterns are. Where we genuinely lose On cost per byte, to direct access. We add a layer and charge for it. On protocol depth, to direct access. If you need to make decisions at the storage-node or committee level, an abstraction is a constraint rather than a convenience. On focus, potentially, to a Walrus-native product. A team building only for Walrus can shape everything around it. We support three networks and make design choices that keep them coherent — CIDs everywhere, for instance — which is exactly right if you want portability and a compromise if you do not. If you are certain about Walrus, want the lowest cost, and have the Sui expertise, going direct is the correct answer and we would rather you got there quickly. --- Get Started - Introduction to IPFS and Walrus - Quick start - Migrate IPFS to Walrus - Pricing - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Programmable Storage: Blobs as Move Objects on Sui
Articlecalendar_todayAug 22, 2026

Programmable Storage: Blobs as Move Objects on Sui

On Walrus, a stored blob and the storage capacity behind it are represented as objects on Sui. That means a Move contract can hold storage, transfer it, and act on it — rather than holding a string that points at a file somewhere. This is the capability that distinguishes Walrus from every other decentralized storage network, and it is routinely underexplained. Most storage is something an application calls. This is storage an application can own. --- The usual arrangement, and its ceiling Everywhere else, on-chain storage references are strings. A contract holds a CID or a URL. It can emit it, store it, compare it — and that is the end of the contract's relationship with the data. The contract cannot know whether the file still exists. It cannot extend its retention. It cannot transfer the storage along with the asset that references it. It cannot make a decision conditional on the state of the storage, because from the chain's point of view the storage has no state. It is a string. Every operation on the actual storage happens off chain, driven by some external process the contract has no visibility into. What changes when storage is an object Sui's object model represents blobs and storage resources as first-class Move objects. Objects are owned, transferred, held by other objects, and passed to functions. So a contract can: Own storage. Hold the object representing a stored blob and its term. Transfer it. Move storage to another address, along with whatever asset it belongs to. Extend it. Renewal becomes a transaction a contract can initiate, driven by on-chain conditions rather than a cron job somewhere. Reason about it. Branch on the storage object's state — whether a term is approaching expiry, how much capacity remains. Storage stops being an external dependency and becomes an asset your application logic manipulates directly. --- Patterns this makes possible Renewal driven by contract logic. Rather than an off-chain service watching expiry, a contract extends storage when a condition holds — a subscription is active, a treasury has funds, a DAO has voted. Retention becomes a property of application state instead of a process that can be forgotten. See Walrus epochs and renewal. Storage that travels with the asset. An NFT whose media storage transfers with the token. Sell the token and the buyer receives the storage capacity keeping the media alive, rather than depending on the original creator continuing to pay. This is a real answer to the collections that go dark when a studio stops paying its bills. Tokenized capacity. Storage as a transferable resource that can be allocated, traded or granted. A DAO holds capacity and allocates it to working groups; a platform grants capacity to creators. Data-centric applications. Where the storage and the logic operating on it live in the same execution environment, rather than a contract on one side and an API call on the other. --- The honest constraints This is Sui-only. It requires the object model. If you are building on an EVM chain, none of it applies — you get a CID, you store it, and that is the relationship. Choose Walrus for read performance in that case, not for programmability. It requires Move. Real capability, real learning curve, and a smaller talent pool than Solidity. It is not a substitute for access control. A contract owning a storage object controls the storage, not who can read the bytes. Content on Walrus is retrievable by anyone with the identifier unless it was encrypted before upload. Confidentiality is a separate layer — on the Walrus path, client-side encryption with Seal-backed policy validation before decryption. Owning the storage object and controlling who can decrypt are two different things, and conflating them is how data ends up readable. --- Using it through Lighthouse Storing through Lighthouse gives you CIDs while keeping the Walrus-native identifiers available. Get blob ID from CID resolves the blob ID you need when interacting with Sui objects directly. The practical split: use the CID as your application's identifier — portable, verifiable, survives a backend change — and reach for the blob ID at the boundary where your Move code touches the storage object. Blob IDs and CIDs covers which belongs where. For teams that want the object model without operating Sui infrastructure for storage, that combination is the useful middle: programmability where you need it, and no epoch bookkeeping or SUI treasury management where you do not. Using Walrus without running Sui infrastructure covers what that involves. --- Why it matters beyond Sui The general idea is worth taking seriously even if you never write Move: storage that a program can reason about is different from storage a program can only reference. Most durability failures are not technical. They are organisational — a renewal nobody owned, a payment that lapsed, a process that depended on a person who left. Storage that an autonomous system can inspect and extend, according to rules encoded where everyone can see them, removes the human step that keeps failing. --- Get Started - Introduction to IPFS and Walrus - Get blob ID from CID - Upload data - Encryption features on the Walrus path - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Walrus Epochs and Renewal: Keeping a Blob Alive
Articlecalendar_todayAug 22, 2026

Walrus Epochs and Renewal: Keeping a Blob Alive

Walrus storage is bought in epochs. When the epochs you paid for run out, the network stops being obliged to keep your blob. Renewal is buying more epochs before that happens. Same shape as a Filecoin deal term, different unit. And the same operational trap: expiry is silent, and the consequences arrive later than the cause. --- What an epoch is A fixed period of network time, used to denominate storage duration and to structure committee transitions. When you store a blob you specify how many epochs it should be retained for, and pay accordingly. Storage is registered on Sui, which is where the term lives as an on-chain record. That has a useful consequence: retention is publicly checkable rather than something you take a vendor's word for. At expiry The obligation ends. Nodes are no longer required to keep your slivers, and reclaiming that capacity for blobs somebody is paying for is the rational thing for them to do. The blob may remain retrievable for some period afterwards — nothing forces immediate deletion, and caches exist. This is the dangerous part. Retrieval continuing to work after expiry is not evidence that anything is still committed to storing it, and the gap between "expired" and "actually gone" is exactly where teams get a false sense of safety. There is no error at the moment of expiry. Nothing alerts unless you built the alert. --- Renewal Buy more epochs before the term ends. Mechanically it is a transaction on Sui extending the storage registration. Doing it yourself means tracking expiry per blob, monitoring what is approaching term, initiating renewals early enough to be safe, and keeping the account funded throughout. Across one blob that is a calendar entry. Across a hundred thousand it is a system, and it is the sort of system that works fine until the person who built it changes jobs. Through Lighthouse, renewal is handled. Epoch tracking and extension happen on our side, so blobs do not lapse because nobody was watching a counter. You upload a file and get a CID; the term underneath keeps rolling. That is a service, not a protocol property, and the distinction matters. Walrus gives you a verifiable bounded term. We give you the assurance that the term keeps being renewed. Both are real, and they are different kinds of promise — worth knowing which one you are relying on. Programmable renewal One thing Walrus offers that Filecoin does not: because blobs and storage resources are represented as Move objects on Sui, renewal can be automated by contract logic rather than by an external process watching a queue. Storage becomes something an application can reason about and act on — extend a term when a condition holds, transfer storage capacity, tie retention to on-chain state. For Sui-native teams that is a genuinely different capability, not just a convenience. See blobs as Move objects. --- Choosing a term Match it to the data's useful life. Not everything deserves indefinite renewal. Intermediate artifacts, superseded datasets and rotated logs have natural end dates, and deciding one is cheaper than defaulting to forever. Longer terms mean fewer renewal events, and therefore fewer chances for the process to fail. If the data clearly matters for years, buying years is operationally safer than buying months repeatedly. Do not confuse a long term with permanence. It is still a term. Anything described as permanent storage on an epoch-based network is being oversold — see do files on IPFS disappear for the same point about pinning. What to actually do Know your renewal policy. Whether you manage it or we do, know what happens if payment lapses. "It is on Walrus" is not a retention policy. Audit periodically. Walk your CID list and confirm blobs are registered with a live term. What you are looking for is content whose term quietly ended. Because it may still be retrievable, this is not something you will notice by using the application. Keep the CID list outside the storage system. It is the record of what you asked to preserve and the thing you audit against. Do not promise users permanence you do not have. If your product tells people their data is stored forever, that is a promise the network does not make and you will not be the one who decides whether it holds. --- Get Started - Introduction to IPFS and Walrus - File info - List files - Pricing - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Walrus Blob IDs and IPFS CIDs: Two Names for One File
Articlecalendar_todayAug 22, 2026

Walrus Blob IDs and IPFS CIDs: Two Names for One File

A CID is an IPFS content identifier derived from your file's bytes. A Walrus blob ID is Walrus's own identifier for a stored blob. The same file stored through Lighthouse on the Walrus path has both, and you can resolve one from the other. Two identifier schemes for one object confuses everyone the first time. The distinction is worth ten minutes because it determines which one belongs in your database, your contract and your logs. --- What each one is for CID — the content's name. Derived from the bytes by hashing. Universal across IPFS tooling, gateways, and anything that already speaks content addressing. It identifies what the file is, independent of where or how it is stored. Two people storing identical bytes on opposite sides of the world produce the same CID. Blob ID — Walrus's handle for the stored object. How the Walrus network and its Sui coordination layer refer to the blob it is storing: registration, storage term, and the on-chain object representing it. The distinction that makes it click: a CID names content, a blob ID names a stored instance of that content within one specific network. Which one to use Use the CID by default. For retrieval, for references in your database, for anything embedded in a contract or a document, for logs and audit records. Reasons: it is portable across storage backends, so migrating between IPFS, Filecoin and Walrus preserves it; it works with the whole IPFS tooling ecosystem and with gateway retrieval; and it is verifiable, since anyone can hash the bytes and confirm they match. Reach for the blob ID when you are interacting with Walrus or Sui directly: inspecting the storage object on chain, working with the blob as a Move object in a contract, or debugging against Walrus tooling. For most applications you can go a long way without ever handling one, which is deliberate. Get blob ID from CID is there for when you need it. --- Side by side | | CID | Walrus blob ID | |---|---|---| | Derived from | File content | Walrus storage registration | | Scope | Universal, content addressing | The Walrus network | | Survives backend migration | Yes | No | | Works with IPFS gateways | Yes | Not directly | | Appears on Sui as an object | No | Yes | | Verifiable by hashing the file | Yes | No | | Best for | References, retrieval, contracts | Sui and Walrus interaction | --- The mental model Think of the CID as the title of a book and the blob ID as the catalogue number in one particular library. The title identifies the work no matter which library holds it. The catalogue number is how that library finds the copy on its shelves — precise, useful inside the building, and meaningless in a different library. You cite the title. You use the catalogue number when you are talking to the librarian. Why Lighthouse gives you both Because dropping CIDs would break the thing that makes content addressing useful. If Walrus-backed content only had blob IDs, then moving data to Walrus would invalidate every existing reference — contracts, metadata, links, documentation. The migration would be a rewrite of everything downstream. By assigning IPFS-style CIDs and keeping content connected to IPFS network indexing, the storage backend becomes swappable. Your references keep working, your gateway URLs keep working, and the network underneath is a decision you can revisit. The blob ID is exposed rather than hidden because Sui-native applications genuinely need it. Storage on Walrus is representable as a Move object, and a contract that wants to hold, transfer or reason about storage needs the identifier the chain uses. See blobs as Move objects. --- Practical guidance Store the CID as your primary key. It is the stable identifier across everything. Record the blob ID if you touch Sui. Store it alongside, do not substitute it. Never put a blob ID in a smart contract on another chain. It is meaningless outside Walrus and Sui, and it ties the reference to one backend. Resolve on demand rather than caching aggressively. The mapping is available through the API when you need it, and keeping a stale copy of a derived identifier is a class of bug you can simply avoid. --- Get Started - Get blob ID from CID - File info - Introduction to IPFS and Walrus - Glossary - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
How to Use Walrus Without Running Sui Infrastructure
Articlecalendar_todayAug 22, 2026

How to Use Walrus Without Running Sui Infrastructure

You do not need a Sui node, SUI tokens, or epoch bookkeeping to store data on Walrus. Use it through an API that handles the Sui side, and you get an ordinary upload call that returns a CID. Walrus is coordinated on Sui, which is excellent engineering and an obstacle if your application lives somewhere else. This post is about removing the obstacle without giving up the network. --- What direct use actually involves Going straight at Walrus means taking on the coordination layer: - A Sui wallet, funded, with key management appropriate to production - Acquiring and holding SUI, plus treasury and accounting for a volatile asset - Registering blobs on chain and paying for storage in epochs - Tracking epoch expiry per blob and renewing before it lapses - Adopting Walrus blob IDs as your identifier scheme - Running or connecting to Sui infrastructure, and keeping it healthy Reasonable if you are a Sui-native team that already has all of it. A significant amount of unrelated work if you are an EVM shop, a Python data team, or anyone whose application has nothing to do with Sui and just wants fast decentralized blob storage. What changes through Lighthouse The Sui-facing work moves to our side of the boundary. What you write is an upload call. No Sui infrastructure. Nothing to run, nothing to monitor. No SUI to hold. Pay on a plan by card, or per-use in stablecoins through x402. There is a 100 MB free tier on the Walrus path to start with, no payment method required. No epoch tracking. Renewal is handled, so blobs do not silently expire because nobody was watching a counter. CIDs, not just blob IDs. Content stored through the Walrus path gets IPFS-style content identifiers and stays connected to IPFS network indexing, so existing gateway patterns and any code that already speaks CIDs keeps working. Blob IDs remain available and are resolvable from a CID when you want to touch Walrus or Sui directly. Sui wallet auth when you want it. Sui wallet authentication is supported, including Slush, so Sui-native teams are not forced away from their existing identity model. It is available, not required. --- Getting started Three steps, and the quick start has the current code. 1. Create an API key. Create an API key for the Walrus path. 2. Upload. Upload data returns a CID. Underneath, the blob is erasure-coded across Walrus storage nodes and registered on Sui — none of which you interact with. 3. Retrieve. Fetch by CID through the gateway, exactly as with any other content. Walrus-backed content is served from gateway-walrus.lighthouse.storage. That is the whole integration. If you have used the Filecoin path, it is the same SDK shape — which is the point. Switching backends should be a configuration decision, not a rewrite. Paying per upload instead of subscribing For variable workloads, or for software that provisions its own storage, x402 lets you pay per upload in stablecoins rather than maintaining a plan. There is a hosted endpoint for the Walrus path, and the client library handles the payment leg, so the call reads like a fetch that happens to cost money. This matters most for autonomous systems, which cannot hold a subscription or ask someone to top up a balance. --- What you give up Worth being straight about, because the honest answer is not "nothing." Direct protocol control. You are not choosing storage node committees or tuning parameters at the protocol level. For almost every application that is a relief; for a team building Walrus-native infrastructure it is a real constraint. A layer of dependency. Your storage now depends on us continuing to operate, in addition to Walrus continuing to operate. That is the standard trade with any managed service, and the mitigation is genuine here: because content is addressed by CID and blob IDs remain resolvable, your data is not locked into our namespace. You can retrieve it and go elsewhere with identifiers intact. Cost. Managed access costs more than raw protocol access. What you buy is the coordination layer, renewal, gateways and support. If you are a Sui-native team with wallet infrastructure, treasury processes and Move expertise already in place, going direct is a legitimate choice, and three ways to store on Walrus compares the options without assuming ours is the answer. --- Where this fits The general pattern is worth naming, because it recurs. A network's native token and chain are how its internal economics and coordination work. It does not follow that consuming the network requires participating in them. Same principle as not needing FIL to store on Filecoin. The protocol needs the token. You need storage. --- Get Started - Quick start - Create an API key - Upload data - x402 pay-per-use - Pricing --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Migrating from IPFS to Walrus Without Changing Your CIDs
Articlecalendar_todayAug 22, 2026

Migrating from IPFS to Walrus Without Changing Your CIDs

Your CIDs survive the move. That is the whole reason this migration is practical: content identifiers are derived from content, not from where it is stored, so changing the storage network leaves every existing reference intact. If your CIDs are sitting in deployed smart contracts, published papers, NFT metadata or customer documentation, that is the difference between a migration and a rewrite. --- Why identifiers usually break, and why these do not Move an object between S3 buckets and its key changes. Move it to another provider and the URL changes. Everything holding a reference has to be updated, and anything you do not control — a contract, a third party's database, a link in a PDF — simply breaks. A CID is a hash of the content. Store the same bytes anywhere and you get the same identifier. The storage network becomes an implementation detail that nothing downstream needs to know about. So the practical consequence is: contracts referencing ipfs://Qm… keep resolving; NFT metadata keeps rendering; gateway URLs keep working; documentation stays accurate. Nobody outside your team needs to be told anything happened. Why migrate at all Not everything should. The case for moving specific data to Walrus: Reads are frequent. Walrus is optimised for serving. If content is loaded constantly — media, application assets, anything user-facing — retrieval performance is what your users experience. The workload is continuous. Agent systems read and write at machine pace rather than in human upload patterns. That shape suits Walrus. You are building on Sui. Blobs as Move objects lets contracts hold and reason about storage directly. The case for leaving data where it is: cold archives are cheaper on Filecoin, by a meaningful margin at volume. Walrus vs Filecoin has the numbers. Migrating a rarely read archive to Walrus increases cost with no benefit anyone will notice. The sensible pattern is selective: move the read-heavy subset, leave the archive. --- Running the migration The migrate IPFS to Walrus guide is the reference. The shape of a careful migration: 1. Decide what moves. Pull your file list and split it by access pattern. If you have retrieval logs, use them — the read-heavy tail is usually a small fraction of total bytes, which is what makes selective migration cheap. 2. Migrate a sample first. Ten files, end to end. Confirm they resolve by CID, confirm blob IDs are assigned, confirm your application serves them correctly. Discovering a systematic problem after twenty thousand files is a bad afternoon. 3. Verify before decommissioning. There is a window where content exists in one place. Keep it short and deliberate: confirm the new copies are live and durable before removing the old arrangement. 4. Keep your CID list. It is the record of what you asked to preserve, and the thing you audit against afterwards. Store it outside the storage system it describes. What changes and what does not | | Before | After | |---|---|---| | CID | Unchanged | Unchanged | | Gateway URLs | Work | Work | | Contract references | Valid | Valid | | SDK calls | Same | Same | | Backing network | IPFS + Filecoin | IPFS + Walrus | | Blob ID | None | Assigned, resolvable from CID | | Retention model | Deal terms | Epochs | | Read performance | Hot layer dependent | Faster | | Cost per GB | Lower | Higher | Two rows deserve attention. Blob IDs are new. Content on Walrus has a native Walrus identifier alongside its CID, and you can resolve one from the other. You do not need it for normal retrieval — CIDs keep working — but it is there when you want to interact with Walrus or Sui directly. See blob IDs and CIDs. Retention moves from deal terms to epochs. Both are renewable terms rather than permanence, and on Lighthouse renewal is handled either way. Worth knowing the model changed, even though the operational experience does not. Encryption changes too If your data is encrypted, note that the Walrus path uses client-side encryption with Seal-backed policy validation before decryption, which aligns with Sui's access-control tooling. That is a different mechanism from the Kavach threshold encryption on the Filecoin path. If you are moving encrypted content, plan that explicitly rather than assuming a transparent migration. Test the decryption path with real conditions and a real wallet before moving anything you cannot afford to lose access to. --- After the move Audit that the durability layer is real. A file that resolves is not necessarily a file that is committed to storage. Check that blobs are registered with a term, the same way you would check deal status on Filecoin. Watch retrieval metrics. The whole point was read performance. Measure it and confirm you got what you paid for — and if the numbers do not move, the data probably belonged on Filecoin. Leave the old references alone. They still work. The temptation to "clean up" by rewriting stored identifiers is how migrations break things that were fine. --- Get Started - Migrate IPFS to Walrus - Get blob ID from CID - List files - Migrations overview - Create an API key --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Walrus vs Filecoin: Erasure Coding or Replication?
Articlecalendar_todayAug 22, 2026

Walrus vs Filecoin: Erasure Coding or Replication?

Filecoin gives you more storage per dollar and continuous on-chain proofs, at the cost of slow cold reads. Walrus gives you fast reads and programmable storage objects, at a higher price per gigabyte. Pick on read frequency first, then on cost. We sell both, which is unusual enough to be worth stating up front — it means we have no reason to talk you out of either, and the comparison below is the one we actually use internally when advising teams. --- The engineering difference Filecoin stores sealed replicas. Each provider runs your data through an expensive encoding bound to their identity, then proves continuously that they still hold it. The sealing cost is what makes the proofs meaningful and what makes retrieval slow — sealed data must be unsealed before it can be served. Walrus erasure-codes each blob into slivers spread across nodes, reconstructable from a subset. There is no sealing step and no unsealing step. A client pulls slivers in parallel and decodes, which is why reads are fast, and total overhead sits around 5x the original size rather than a multiple of full copies. Everything else follows from that one choice. --- Side by side | | Filecoin | Walrus | |---|---|---| | Redundancy | Sealed replicas | Erasure-coded slivers | | Storage overhead | Per full replica | 5x total | | Read performance | Cold; needs a hot layer | Fast, by design | | Retention model | Deal term, renewable | Epochs, renewable | | Coordination chain | Filecoin | Sui | | Storage proofs | PoRep and PoSt, continuous | Availability via encoding | | Programmability | Deal records | Blobs as Move objects | | Cost per GB | Lower | Higher | | Maturity | Longer track record | Newer | Pricing, concretely Through Lighthouse, August 2026: | | Filecoin | Walrus | |---|---|---| | Free tier | 5 GB | 100 MB | | Entry paid | $12/month, 500 GB | $11/month, 250 GB | | Premium | $49/month, 2.5 TB | $79/month, 2.5 TiB | At the entry tier the headline prices look similar, but Filecoin gives twice the capacity for a dollar more. At Premium the gap is stark: the same capacity costs $49 on Filecoin and $79 on Walrus. The free tiers differ by a factor of fifty. If you are evaluating or prototyping, start on Filecoin for that reason alone. --- Choosing on read frequency The question that decides it is not cost. It is: how often will this data be read after it is written? Rarely read → Filecoin. Archives, backups, compliance records, historical datasets, anything written once and consulted occasionally. You are paying for durability and verifiability, not for serving. The cold-read penalty is irrelevant when reads are rare, and the cost advantage compounds across terabytes. Frequently read → Walrus. Application media, user-generated content, game assets, anything an audience actually loads. Here retrieval latency is the product experience, and the premium buys something your users perceive. Continuously read and written → Walrus. Agent workloads are the clearest case. Autonomous systems do not have human upload patterns — they read and write constantly, in small operations, at machine pace. Storage optimised for occasional archival retrieval is the wrong shape for that. Choosing on ecosystem If you are building on Sui, Walrus has a structural advantage beyond performance: blobs are Move objects, so your contracts can hold, transfer and reason about storage directly. That is not a convenience — it is a capability Filecoin does not offer, and it enables patterns like automated renewal driven by contract logic. See blobs as Move objects. If you are on an EVM chain, that advantage does not apply, and the decision reverts to read frequency and cost. Choosing on proof requirements If you need to hand a third party evidence that data was stored and continuously proved — a regulator, an auditor, a counterparty in a dispute — Filecoin's PoRep and PoSt records are the stronger artifact. They are public, continuous, and independently checkable. Proof of replication and proof of spacetime covers what they assert. Walrus's guarantee is availability through encoding and committee coordination, which is a real and well-designed property but a different one, and less useful as evidence in an adversarial setting. --- You do not have to choose permanently Through Lighthouse both backends sit behind the same interface: same CIDs, same SDK calls, same gateways. Migration preserves identifiers, so moving a dataset from IPFS and Filecoin to Walrus does not break references already embedded in contracts or documents. See migrating from IPFS to Walrus. That makes the decision reversible, which should lower the stakes considerably. A sensible default: start data on Filecoin, move the subset that turns out to be read-heavy to Walrus once you have real traffic data rather than a guess. The honest summary If cost per terabyte is the constraint and reads are rare, Filecoin, and it is not close. If retrieval speed is what your users experience, or you are building on Sui, or your workload is an agent rather than a person, Walrus earns its premium. Most teams end up with both, split by access pattern rather than by preference. --- Get Started - Introduction to IPFS and Walrus - Introduction to IPFS and Filecoin - Migrate IPFS to Walrus - Pricing - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
What Is Walrus? Sui's Decentralized Blob Storage, Explained
Articlecalendar_todayAug 22, 2026

What Is Walrus? Sui's Decentralized Blob Storage, Explained

Walrus is a decentralized storage network for large binary files, built by Mysten Labs and coordinated on Sui. It uses erasure coding rather than full replication, which makes storage overhead roughly 5x the original size while keeping reads fast. If you know Filecoin, the quickest way to place Walrus is this: same category, different engineering trade-off. Filecoin optimises for verifiable long-term archival with sealed replicas. Walrus optimises for serving blobs quickly while staying decentralized. --- The core idea Store a large file across a network of independent nodes without giving every node a full copy. Walrus encodes each blob into slivers — smaller encoded fragments — and distributes them across storage nodes. The encoding is redundant enough that the original blob can be reconstructed from a subset of slivers, even when a substantial fraction of them are unavailable. That is erasure coding, and the property that matters is the ratio. Full replication across enough nodes to survive failures multiplies storage cost by the replication factor. Erasure coding achieves comparable resilience at roughly 5x the original blob size, and reconstruction stays fast because a client can pull slivers in parallel from many nodes at once. Reading is a parallel fetch and a decode, not a request to whichever node happens to hold the single authoritative copy. That is why Walrus reads well. Where Sui comes in Sui is the coordination layer, not the storage layer. Blobs live on storage nodes; Sui carries the metadata, the payments, and the governance. Concretely, Sui handles: - Registration. A blob's existence and storage term are recorded on chain. - Payment. Storage is purchased and accounted for on Sui. - Storage as an object. Blobs and storage resources are represented as Move objects, so a smart contract can hold, transfer or reason about storage the way it holds any other asset. - Node coordination and governance. Which nodes are in the committee, and epoch transitions. That third point is the genuinely novel one. Storage that a contract can own and manipulate as a first-class object is different in kind from a URL in a database. It enables automated renewal, transferable storage capacity, and data-centric applications where the storage itself is programmable. We cover this in blobs as Move objects. Epochs and retention Walrus retention is epoch-based. You purchase storage for a number of epochs, and continuing past that means renewing. Same shape as Filecoin's deal terms, and the same honest caveat: this is not permanent storage. It is a term you buy and extend. Walrus epochs and renewal covers the mechanics and what happens if you let a term lapse. --- Walrus compared with what you already know | | IPFS | Filecoin | Walrus | |---|---|---|---| | Role | Addressing and transfer | Durability | Blob storage and DA | | Redundancy | Pinning | Sealed replicas, proved | Erasure-coded slivers | | Read speed | Gateway dependent | Cold, needs hot layer | Fast, by design | | Retention | While pinned | Deal term | Epochs | | Coordination | None | Filecoin chain | Sui | | Overhead | Per full copy | Per full replica | 5x total | For a proper decision guide rather than a summary, see Walrus vs Filecoin. --- Using Walrus through Lighthouse You can use Walrus directly. Doing so means operating against Sui — wallets, gas, epoch tracking, renewal — and adopting Walrus blob IDs as your identifier scheme. Through Lighthouse, three things change: You get CIDs. Files stored on the Walrus path receive IPFS-style content identifiers and remain connected to IPFS network indexing, so the same gateway retrieval patterns apply. If you already reference content by CID, nothing downstream changes. Blob IDs are still available, and resolvable from a CID — see blob IDs and CIDs. Epoch renewal is handled. You do not track epochs or fund renewals per blob. No Sui infrastructure required. Sui wallet authentication is supported, including Slush, but you are not obliged to run anything. How to use Walrus without running Sui infrastructure covers this properly. Existing IPFS data can be migrated to Walrus with CIDs preserved, so switching backends does not invalidate references already sitting in contracts or documents. Encryption on the Walrus path uses client-side encryption with Seal-backed policy validation before decryption, aligning with the Sui ecosystem's access-control tooling. Note that this differs from the Kavach threshold encryption on the Filecoin path — worth knowing if you are choosing between them for sensitive data. Storage can be purchased with stablecoins through x402, and there is a free tier of 100 MB on the Walrus path to try it. Lighthouse operates its Walrus integration under a commercial agreement with Mysten Labs. --- When Walrus is the right choice Choose it when reads are frequent and latency matters — media serving, application assets, agent workloads that read and write continuously rather than occasionally. Also when you are building on Sui and want storage your Move contracts can reference as objects. Choose Filecoin instead for archival volume where cost per terabyte dominates and reads are rare. Filecoin gives more storage per dollar; Walrus gives faster retrieval. That is the trade, and it is worth making deliberately. --- Get Started - Introduction to IPFS and Walrus - Quick start - Create an API key - Upload data - Pricing --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
IPFS vs HTTP: What Content Addressing Actually Changes
Articlecalendar_todayAug 22, 2026

IPFS vs HTTP: What Content Addressing Actually Changes

HTTP addresses a location: fetch whatever is at this server, at this path, right now. IPFS addresses content: fetch the bytes whose hash is this. That one substitution changes what can break, what can be verified, and who you have to trust. Most comparisons of the two turn into an argument about decentralization. The more useful frame is narrower and more concrete: what happens when something goes wrong. --- The substitution An HTTP URL is a set of instructions: talk to this host, ask for this path. What comes back is whatever that host decides to send. Usually that is the file you expected. It does not have to be. A CID is a claim about content: the bytes whose hash is this. Any node that has them can serve them, and you can verify you got the right thing by hashing what you received. The server is irrelevant to correctness. What that changes, concretely Link rot has a different shape. An HTTP link breaks when a server moves, a path changes, a company folds, or a domain lapses. The content might still exist somewhere, but the address no longer finds it. A CID never points at the wrong content — but it can point at content nobody is storing. HTTP fails by serving you something else, or nothing, at a name that still looks valid. IPFS fails by finding nobody who has it. Neither is immune; they fail differently, and the IPFS failure is at least unambiguous. Verification stops requiring trust. Over HTTP, you trust the server and the transport. TLS proves you are talking to the right host, not that the host is honest about the file. With a CID, you check the content yourself. This is why content addressing matters for NFT media, published datasets, and audit records — a third party can confirm the artifact is the one referenced, without your cooperation and without trusting the host. Duplication collapses. The same file uploaded a thousand times has one CID and, in principle, needs storing once. HTTP has no idea two URLs serve identical bytes. Any node can serve. Content can come from whichever node is closest or fastest, without the fallback logic and CDN configuration that HTTP requires. Mutability becomes explicit work. With HTTP, updating a file at a URL is trivial — which is convenient and is also why nobody can prove what was there yesterday. With IPFS, a change means a new CID, and keeping a stable name requires IPNS or DNSLink. The friction is the feature: you cannot silently change history. --- Side by side | | HTTP | IPFS | |---|---|---| | Address refers to | Location | Content | | Same address, different bytes | Possible | Impossible | | Verify without trusting host | No | Yes | | Who can serve it | The host | Any node with the blocks | | Deduplication | None | Inherent | | Updating in place | Trivial | New CID, plus a pointer | | Fails when | Host or path goes away | Nobody is storing the blocks | | Private by default | Yes, with auth | No | | Latency | Predictable, mature CDNs | Varies, gateway-dependent | --- Where HTTP is straightforwardly better Worth saying plainly, because the honest answer to "should I replace HTTP with IPFS" is usually no. Anything private by default. HTTP has decades of authentication and authorization infrastructure. IPFS has no access control at all — content is retrievable by anyone with the CID. Privacy has to be added by encrypting before upload, which is a real solution but an extra layer, not a default. Anything that changes constantly. A CID per version is wrong for a feed that updates every second. Low, predictable latency. Mature CDN infrastructure is very good and very cheap. Gateway retrieval is improving but does not universally match it. Dynamic responses. Personalised, computed or query-dependent content is not a fit for an addressing scheme built on fixed bytes. The realistic architecture for most products is both: HTTP for the application, content addressing for the artifacts that need to be verifiable and outlive the application. --- Where content addressing earns its place Anything referenced from a contract. On-chain byte storage costs gas proportional to size. A CID is a compact pointer that is also a proof of what it points at. Published artifacts. Datasets, research outputs, software releases, model weights. Anyone can confirm they have the exact artifact a result was computed on. Audit and provenance records. A CID recorded at the time of an action proves the record was not altered afterwards. That turns a log into evidence — which is why it matters increasingly for autonomous systems whose action logs need to be defensible. Media you want to outlive your company. Content addressing plus a durability layer means the artifact does not depend on your infrastructure continuing to exist. --- What sits underneath IPFS handles addressing and transfer. It does not, by itself, keep anything. Something has to store the bytes: a pin, and beneath the pin a Filecoin deal or a Walrus blob committing operators to retain them for a term. That layering is the thing to take away. Content addressing gives you a name that cannot lie. Durability is a separate arrangement you make on purpose, and privacy is a third. Get all three deliberately and you have something better than a URL. Get only the first and you have a verifiable name for a file nobody is keeping. Further reading: what is a CID, do files on IPFS disappear, and is IPFS private. --- Get Started - Introduction to Lighthouse - Quick start - Glossary - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
IPNS or DNSLink? Choosing a Mutable Pointer
Articlecalendar_todayAug 22, 2026

IPNS or DNSLink? Choosing a Mutable Pointer

Use IPNS when the pointer must be cryptographically owned and independent of DNS. Use DNSLink when humans need to read the name and you already control the domain. They solve the same problem from opposite ends. Content addressing gives you immutable identifiers, which is exactly what you want for verifiability and exactly what you do not want for anything that changes. Both of these are answers to "how do I keep a stable name pointing at content that updates." --- The problem in one line A CID names a specific version of a file. Publish a new version, get a new CID, and every reference to the old one is now pointing at history. For a website, an evolving dataset, or a contract that needs to reach current content, you need a layer of indirection. --- IPNS A name derived from a keypair. You publish a signed record saying "this name currently points at this CID," and republish whenever the target changes. Whoever holds the private key controls the name, and nobody else can. Strengths - No external dependency. Not DNS, not a registrar, not a certificate authority. The name is yours because you hold the key. - Cryptographically verifiable. A resolver can check the record was signed by the keyholder. - Censorship resistant. There is no registrar to pressure and no domain to seize. - Portable. The name works anywhere IPNS resolves, independent of any web infrastructure you own. Costs - Unreadable. k51qzi5uqu5dk… is not a name anyone will type or remember. - Resolution is slower than DNS, because it is a network lookup rather than a cached hierarchy. - Records expire and must be republished on a schedule. Miss it and the name stops resolving. - Key management is your problem. Lose the key and you lose the name permanently; leak it and someone else controls what your name points at. DNSLink A TXT record on a domain you already own, containing dnslink=/ipfs/<CID. Update the CID by updating the record. Strengths - Human readable. Your actual domain, which people already trust and can type. - Fast. DNS resolution is heavily cached and universally deployed. - Familiar operationally. Your team already knows how to change a TXT record, and your existing DNS tooling and access controls apply. - Delegatable through subdomains without minting new keys. Costs - You depend on DNS. Registrar, nameservers, and everything that can go wrong with them, including seizure and expiry. - Not cryptographic. Whoever controls the DNS zone controls the pointer, and that is often a broader set of people than you think. - Centralised trust, which for some projects defeats the purpose entirely. --- Side by side | | IPNS | DNSLink | |---|---|---| | Name looks like | k51qzi5uqu5dk… | example.com | | Ownership proved by | Private key | DNS control | | Resolution speed | Slower, network lookup | Fast, cached | | External dependency | None | Registrar and DNS | | Human readable | No | Yes | | Needs republishing | Yes, records expire | No | | Survives domain loss | Yes | No | | Censorship resistance | High | Low | --- Which to pick Choose IPNS when independence from DNS is the point: content that must remain reachable if a domain is lost, protocol-level references, anything where "who can take this away from me" has a real answer you dislike. Also when a contract should reference a pointer whose ownership is provable on the same terms as the rest of your system. Choose DNSLink when the audience is human and the domain is not at risk: a documentation site, a marketing site, a dashboard. The readability is worth more than the cryptographic ownership, because nobody is trying to seize your docs. Use both for a public site with an ideological or practical need for a fallback: DNSLink for the everyday path, IPNS as the identifier that survives if the domain does not. Publish both, point them at the same CID, and mention the IPNS name somewhere durable. A third option people forget Sometimes the right answer is neither. If updates are infrequent and the consumer is a smart contract, storing the CID directly on-chain and updating it with a transaction gives you a mutable pointer whose entire history is auditable — every change recorded, timestamped and attributable. That is a stronger property than either IPNS or DNS provides, at the cost of gas and latency. Choose that when the audit trail of what changed when matters as much as the current value. --- Using IPNS on Lighthouse We handle publishing and republishing so records do not silently expire, which removes the most common way IPNS deployments break. The IPNS guide covers creating a name and pointing it at content, and there is a longer walkthrough on updating content with IPNS. One habit worth keeping regardless of which pointer you choose: record the CID of every version you publish. The pointer tells you what is current. Only your own records tell you what was live in March. --- Get Started - IPNS and mutable data - Update content with IPNS - Pushing file metadata on-chain - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Serving Video from IPFS Without Buffering
Articlecalendar_todayAug 22, 2026

Serving Video from IPFS Without Buffering

Video on IPFS buffers for one of two reasons: the player is downloading the whole file before it starts, or the gateway cannot sustain throughput. Both are solvable, and neither requires giving up content addressing. A 2 GB video and a 20 KB JSON file are the same kind of object to IPFS and completely different problems to a viewer. Getting playback right is mostly about not treating them the same way. --- Why the naive approach stalls Point a <video tag at a public gateway URL for a large file and you get some combination of: - A long blank pause before anything plays, because the client is fetching from the start with no seek support - Playback that starts and then stalls as the buffer drains faster than the gateway fills it - Seeking that reloads from the beginning rather than jumping - Complete failure on large files as the request times out The underlying causes are ordinary. Public gateways are shared, heavily loaded and aggressively rate-limited. And without range request support, there is no streaming — only downloading, with playback bolted on afterwards. Fix one: range requests HTTP range requests let the client ask for byte 5,000,000 through 6,000,000 rather than the whole file. That is what makes seeking instant and buffering incremental. Gateways that support ranges over IPFS content turn a download into a stream. This single capability is the difference between a video that plays like the web and one that feels like a file transfer. Check that whatever you are serving from supports it; a lot of public infrastructure does so unreliably under load. Fix two: a gateway you are not sharing with everyone Streaming is a sustained-throughput problem, not a single-request problem. A viewer needs bytes to keep arriving for the whole duration of playback, which is exactly the workload shared public gateways are worst at. Lighthouse gateways are tuned for retrieval and support 4K video streaming and media delivery at scale. The practical difference is not peak speed on a benchmark — it is that throughput does not collapse when someone else's collection drops at the same time as your launch. Fix three: segment, do not monolith For anything longer than a couple of minutes, transcode into HLS or DASH segments and store the segments and the manifest. playlist.m3u8 → segment000.ts segment001.ts segment002.ts … The player fetches the manifest, then pulls segments as it needs them. Advantages that matter: - Startup is one small segment, not a large file - Seeking fetches one segment, not a re-download - Adaptive bitrate becomes possible — ship multiple renditions and let the player pick - Each segment is independently cacheable and retryable, so one slow request degrades playback instead of ending it This is how video works everywhere else on the internet, and there is no reason to abandon it because the storage is content-addressed. --- Gated video If the video is behind a paywall, a membership or token ownership, hiding the URL does not work — anyone who obtains the CID can fetch the file. Encrypt it and gate decryption on-chain instead. The ciphertext can be served from anywhere, by anyone, and remains useless without a wallet that satisfies your conditions. Ownership of an NFT, a token balance threshold, an active subscription in your own contract, or a time window all work as conditions, and access can be revoked afterwards. The pay-to-view tutorial walks through the payment-gated case end to end, and there is a video player tutorial for the playback side. Worth being clear about the trade-off: segment-level encryption and adaptive streaming interact, and the simplest implementations decrypt a whole file before playback, which reintroduces the startup delay for large videos. Design for it — shorter segments, or encrypt the manifest and keys rather than every byte of media, depending on your threat model. --- Thumbnails and posters without a second upload Retrieval-time image resizing means a poster frame can be stored once and served at whatever dimensions each surface needs, rather than pre-generating and storing a set of variants. Fewer files, less to keep in sync, and no re-upload when a design change needs a different size. See resize image. --- A working checklist - Transcode to HLS or DASH; store segments and manifest - Serve from a dedicated gateway, not a public one - Confirm range requests are supported end to end - Use ipfs:// or relative paths in manifests so the gateway is not baked in - Ship at least two renditions if your audience is on mobile - Encrypt and gate on-chain if the content is not free - Generate posters at retrieval rather than storing variants --- Get Started - Video player tutorial - Create pay-to-view media - Resize image - Upload data - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
How to Pin an Existing CID Without Re-uploading
Articlecalendar_todayAug 22, 2026

How to Pin an Existing CID Without Re-uploading

If content is already on IPFS and you want it reliably stored, pin the CID rather than uploading the file again. Same identifier, no duplicate bytes, and every existing reference keeps working. Re-uploading is the instinct, and it is usually wrong. It costs you bandwidth, it costs you time proportional to the file size, and depending on how the original was chunked it can hand you a different CID for identical content — which quietly breaks every contract, link and record that pointed at the original. --- When you want this Taking over content you did not upload. A collection you acquired, an artifact from a contributor, a dataset published by a collaborator. It exists, it has a CID, and you want to stop depending on whoever is currently pinning it. Migrating providers. You are leaving another pinning service and want the same CIDs served by someone else. Pinning is the migration — there is nothing to move, because the identifier is the content. Rescuing something at risk. A CID that still resolves but is thinly pinned. Pin it now, while the bytes are still retrievable from somewhere. Adding durability under an existing pin. The content is pinned but has no Filecoin deal or Walrus blob underneath it. Pinning through a provider that adds that layer upgrades it from an instruction to a commitment. What it does Your provider fetches the blocks for that CID from the network and stores them. From then on, requests resolve from their infrastructure, and the content is included in whatever durability arrangement your plan carries. The CID does not change. That is the whole point, and it is only possible because the identifier is derived from content rather than location. Nothing downstream needs to know the storage moved. --- Doing it on Lighthouse The pin CID endpoint takes the identifier and does the rest. There is no file upload, so the request is small and fast regardless of how large the content is. After pinning, confirm it landed: - File info resolves the CID against your account - Check for Filecoin deals confirms the durability layer, once the deal is made That second check is worth doing rather than assuming. A pin is immediate; a storage deal takes time to be made and sealed. Both matter, and they are not the same event. The one precondition The content has to be retrievable from somewhere at the moment you pin it. Pinning does not conjure bytes — it asks a provider to go and fetch them. If the CID no longer resolves anywhere on the network, there is nothing to pin. The identifier is valid and the data is gone. This is exactly the failure described in do files on IPFS disappear, and it is why pinning something you care about is a thing to do early rather than eventually. If a pin request stalls, the likely causes are the same as any retrieval failure: the content is thinly provided, or the provider records have not propagated. Our gateway timeout diagnostic walks through it. --- Migrating a lot of CIDs at once For a bulk move, the migrations guide covers coming from other storage providers, and it is worth reading before writing a loop over your CID list. A few things that matter at volume: Verify a sample end to end first. Pin ten, confirm they resolve and that deals are made, then run the rest. Discovering a systematic problem after twenty thousand pins is unpleasant. Keep your CID list. Obvious, and people lose it. That list is the only record of what you asked to be preserved, and it is what you audit against afterwards. Confirm before you cancel. Do not close the old provider account until the new pins are verified and durable. There is a window where the content exists in exactly one place, and you want it to be short and deliberate. --- Where this fits with Walrus The same principle underpins moving between backends. Migrating IPFS data to Walrus preserves CIDs too, so a change of storage network is invisible to anything holding a reference. Content addressing makes storage an implementation detail. Pinning an existing CID is the smallest, most useful demonstration of that. --- Get Started - Pin CID - Migrations - File info - Check for Filecoin deals - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
IPFS for NFT Metadata: How Token URIs Break
Articlecalendar_todayAug 22, 2026

IPFS for NFT Metadata: How Token URIs Break

Broken NFT images are almost never a contract bug. They are a storage bug: the token URI points at a CID that nothing is pinning any more, or at an HTTP gateway that has gone away. The collection mints fine. The images render fine for months. Then holders start reporting grey placeholders, and the contract is immutable so there is nothing to patch. This post is about why that happens and how to make it not happen. --- The three ways a token URI dies 1. The gateway hostname is baked into the contract. This is the worst version, because it is unfixable after deployment. A tokenURI returning https://somegateway.example/ipfs/Qm… has hardcoded a company's DNS into an immutable contract. When that gateway rate-limits, changes its URL structure, or shuts down, every token in the collection breaks at once. The fix is to store ipfs://Qm… and let the client resolve it through a gateway of its choosing. Marketplaces and wallets all understand the ipfs:// scheme. You keep the identifier and give up nothing. 2. Nothing is pinning the content. Covered at length in our post on whether IPFS files disappear, and it is the most common root cause. Files added to a local node during minting, never pinned with anything durable, gradually stop resolving as caches expire. The CID stays valid forever and points at nothing. 3. The metadata resolves but the image inside it does not. Two layers, two chances to fail. The metadata JSON is pinned, the contract points at it correctly, and the image field inside it points at a CID that was never pinned — or at an HTTP URL on a server that has since been decommissioned. Marketplaces show the name and traits, and a blank square. --- The layout that survives Contract → tokenURI: ipfs://<metadata CID ↓ Metadata JSON → "image": "ipfs://<media CID" ↓ Media file Three rules make this durable: Use ipfs:// at every level. No gateway hostnames anywhere in stored data. The client decides how to resolve. Pin both layers with the same provider. Metadata and media are separate CIDs with separate lifetimes. Pinning one and forgetting the other is a common and silent failure. Put a durability layer underneath the pin. A pin is an instruction to one provider. A Filecoin deal or Walrus blob underneath is a commitment by a network of operators, with proofs, for a term you renew. For a collection meant to outlive your company's runway, that difference is the whole point. Freeze the metadata, or plan for mutability deliberately Two valid strategies, and the mistake is drifting between them by accident. Frozen. Upload metadata, get a CID, put it in the contract, never change it. Holders can verify that the traits are the ones minted, because a different file would have a different CID. This is what most collections want and what buyers assume. Deliberately mutable, for a game or an evolving collection. Then use IPNS: the contract stores a stable IPNS name, and you republish it to point at new content. You keep the ability to update without lying about immutability, because anyone can see the pointer is an IPNS name rather than a CID. Our guide on choosing between IPNS and DNSLink covers the trade-offs. What you should not do is claim frozen metadata and then re-upload to a gateway path you control. --- Unlockable content, done properly "Unlockable content for holders" is usually implemented as a URL that is hidden in the UI. That is not access control — the file is public, and the link leaks the first time anyone shares it. The version that actually holds: encrypt the file client-side, then gate decryption on ownership of the token. With Lighthouse, decryption conditions can check ERC-721 or ERC-1155 ownership directly, so the key shares are only released to a wallet that holds the NFT at the time of the request. Sell the token and the new owner can decrypt; you cannot. javascript const conditions = [ { id: 1, chain: "Ethereum", method: "balanceOf", standardContractType: "ERC721", contractAddress: "0xYourCollection", returnValueTest: { comparator: "=", value: "1" }, parameters: [":userAddress"], }, ]; That is the whole gate. No server, no session, no allowlist to maintain as tokens trade. Serving the media well Collections are image-heavy, and retrieval quality is what holders actually experience. Two things worth knowing: retrieval-time image resizing means you can serve thumbnails without storing a second set of files, and gateways tuned for media handle large assets and video without the timeouts that plague public endpoints. --- A pre-mint checklist - Metadata and media both pinned, with a durability layer underneath - tokenURI returns ipfs://, never a gateway hostname - The image field inside the metadata is also ipfs:// - Deal or blob status verified, not assumed - Renewal handled by someone, and you know who - Unlockables encrypted and gated on ownership, not hidden behind a secret URL - CIDv1 throughout, so nothing gets case-mangled in transit --- Get Started - Minting NFTs on EVM chains - Minting NFTs on Solana - Token gating NFTs - Pushing file metadata on-chain - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
IPFS Pinning Services Compared: Pinata, Filebase, Infura and Lighthouse
Articlecalendar_todayAug 22, 2026

IPFS Pinning Services Compared: Pinata, Filebase, Infura and Lighthouse

Short version: pick Pinata for the largest ecosystem of integrations, Filebase if you want S3 semantics over multiple decentralized backends, Infura if you are already deep in their stack, and Lighthouse if the data needs to be encrypted and access-controlled on-chain. Every one of these will pin a file and give you a gateway URL. They differ on what happens around that — durability underneath, privacy, access control, and how much of your architecture you have to change. We build one of them, so read the comparison with that in mind. We have tried to be specific enough about where we lose that you can check. --- At a glance | | Pinata | Filebase | Infura | Lighthouse | |---|---|---|---|---| | IPFS pinning | Yes | Yes | Yes | Yes | | Dedicated gateways | Yes | Yes | Yes | Yes | | S3-compatible API | No | Yes | No | Yes, via L3 | | Durability layer | Pinning | Multiple backends | Pinning | Filecoin deals or Walrus | | Client-side encryption | No | No | No | Yes, threshold | | On-chain access conditions | No | No | No | Yes | | Multi-network routing | IPFS | IPFS, Sia, others | IPFS | IPFS, Filecoin, Walrus | | Agent-oriented tooling | No | No | No | Memory, MCP | | Free tier | Yes | Yes | Yes | 5 GB | --- Pinata The most widely integrated IPFS service, and for a lot of teams the default. Mature dashboard, good docs, submarining for private-ish files, extensive NFT tooling, and an enormous number of tutorials that assume it. Choose it when you want the path of least resistance for IPFS pinning, particularly around NFT workflows, and you do not need cryptographic privacy. Where it does not fit is confidentiality. Private files are private by policy — the service holds your plaintext and agrees not to serve it to others. That is a reasonable product decision, and it is a different guarantee from data the operator structurally cannot read. Filebase S3-compatible object storage over decentralized backends, with IPFS among them. If your codebase already speaks S3, Filebase is the smallest possible diff: change the endpoint, keep the bucket-and-key mental model. Choose it when you want to move existing S3 workloads onto decentralized storage with minimal code change and no interest in the underlying network specifics. Where we overlap directly is L3, our own S3-compatible endpoint. Honest read: if S3 compatibility over IPFS is the only requirement, these are close, and Filebase has been at it longer. Our differentiation is what sits alongside it — encryption, on-chain conditions, and the agent surface — not the S3 layer in isolation. Infura IPFS as one component of a broader Web3 developer platform, alongside RPC endpoints for several chains. Consolidation is the value: one vendor, one bill, one dashboard. Choose it when you are already using Infura for node access and want storage in the same place with the same credentials. Where it does not fit is teams for whom storage is the primary concern rather than an accessory. A storage module inside a larger platform tends to get platform-level attention, not storage-level attention. Lighthouse We are storage-first, and the thing we build that the others do not is client-side threshold encryption with on-chain access control. Files are encrypted in the browser or runtime before upload. The key is split with BLS threshold cryptography across independent nodes, so no single node holds a complete key. Reconstruction requires a threshold of nodes to each independently verify that the requester satisfies conditions you defined — token balances, NFT ownership, custom contract return values, time windows, passkeys, zkTLS proofs — before releasing their share. The consequence is structural rather than contractual: we cannot read your files, and neither can storage node operators on IPFS, Filecoin or Walrus. Compromising our infrastructure does not expose contents, because there is no plaintext and no complete key to take. Underneath the pin you choose a durability layer: Filecoin deals for archival volume, or Walrus for erasure-coded blob storage with faster reads. Same CIDs, same SDK calls, and migration between them preserves identifiers. Choose it when the data is sensitive, gated, regulated, or shared per-recipient — or when you are building for agents and want memory and MCP tooling alongside storage. Where you should not choose us: if you want the cheapest possible raw pinning with no encryption and no access control, a commodity pinning service will be cheaper and simpler. We do not compete on cost per gigabyte, and pretending otherwise would waste your time. --- The question that actually decides it Not "which is fastest" or "which is cheapest per GB" — at these volumes those differences are small and change quarterly. Ask instead: does anyone other than the intended reader ever hold this file in plaintext? If the honest answer is "it does not matter, this is public content," then any of these will do, and you should optimise for integration effort and price. Most NFT media, static assets and published datasets are in this category. If the answer is "that would be a problem," then encryption is not a feature to add later. It has to happen before the bytes leave the client, which makes it an architectural choice rather than a vendor preference. --- Get Started - Upload encrypted data - Encryption features - L3, the S3-compatible API - Migrate from another provider - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Do Files on IPFS Disappear?
Articlecalendar_todayAug 22, 2026

Do Files on IPFS Disappear?

Yes, they can. IPFS does not store anything by itself. A file stays available for exactly as long as at least one node chooses to keep serving it, and nothing in the protocol obliges anyone to. This surprises people who have been told that IPFS is where files live forever. IPFS is an addressing and transfer protocol, not a storage guarantee. Understanding the difference is what separates a file that is still there in three years from one that quietly vanished last Tuesday. --- What actually keeps a file alive Three mechanisms, in descending order of reliability. Pinning. Telling a node "keep this, do not delete it." A pinned file survives garbage collection on that node. It does not survive the node being switched off, running out of disk, or its operator losing interest. Caching. When a node fetches your file to serve it to someone, it holds a copy for a while. That copy makes retrieval faster for the next requester and disappears whenever the node cleans up. Useful, entirely incidental, and never something to rely on. A storage deal underneath. A Filecoin deal or a Walrus blob commits a network of independent operators, with economic incentives and cryptographic proofs, to hold the bytes for a defined term. This is the only one of the three that constitutes an actual commitment. If your file is only cached, it will go. If it is pinned on one node, it lasts as long as that node. If there is a deal underneath, it lasts for the deal term and can be renewed. Garbage collection, concretely An IPFS node has finite disk. When it fills, it runs garbage collection and deletes blocks that are not pinned. Cached copies of your file are prime candidates. Nothing about this is a malfunction. It is the correct behaviour of a node that would otherwise fill its disk with other people's data. But it means the answer to "is my file safe because lots of nodes have seen it" is no. Popularity is not persistence. The failure that catches teams out The common version goes like this. During development, files are added to a local node and everything works. The app ships. Months later, images start 404ing — not all at once, gradually, as different caches expire at different times. By the time anyone notices, the original machine has been reimaged and the content is gone. The CID is still valid. It resolves to nothing, because nothing is holding the bytes any more. A content identifier does not decay; the content behind it does. --- How long does a file last, really? It depends entirely on what you arranged, and it is worth being precise rather than reassuring. | Arrangement | Realistic lifespan | |---|---| | Added to a local node, never pinned elsewhere | Until that node garbage collects | | Pinned on your own single node | Until that node dies or fills | | Pinned with a provider | As long as the account is active | | Provider pin plus Filecoin deal | The deal term, renewable | | Provider pin plus Walrus blob | The epochs paid for, renewable | Notice that none of those rows says "forever." This is where a lot of marketing in this category, including some of our own older posts, was sloppy. Retention is a term you buy and renew, not a physical property of decentralized networks. Anyone promising permanence is either describing a different economic model — Arweave's endowment is a genuine attempt at one — or overselling. The honest version: Lighthouse manages deal creation, renewal and storage provider selection on your behalf, so the term keeps rolling without you tracking epochs. That is a good deal and a real service. It is not the same claim as forever, and we would rather say so. What about deletion? The mirror image question, and the answer is uncomfortable in the opposite direction. You can delete a file from your account and unpin it. What you cannot do is retract copies that other nodes fetched and cached while it was public. Those nodes are not yours, they have no obligation to you, and the CID still resolves for anyone they serve. So: content you published to the public network cannot be reliably unpublished. If a file must be permanently retractable, it should never have been stored unencrypted in the first place. Encrypt it, gate decryption on a condition, and revoke the condition — the ciphertext may persist, but nobody can open it. --- Making a file actually stick Pin with something that has an incentive to keep running. Your laptop is not that. Put a durability layer underneath the pin. IPFS gives you fast retrieval and addressing. Filecoin or Walrus gives you a network of operators being paid and proved against to retain the bytes. The pairing is the point — see why Filecoin needs a hot layer. Verify rather than assume. Check the deal status for content you care about. A file you believe is stored and a file that is stored are different things until you have checked. Know your renewal terms. Whatever your provider does about renewal, know what it is. "It is on IPFS" is not a retention policy. --- Get Started - Pin an existing CID - Check for Filecoin deals - Upload data - Delete a file - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Why Your CID Won't Load: IPFS Gateway Timeouts, Diagnosed
Articlecalendar_todayAug 22, 2026

Why Your CID Won't Load: IPFS Gateway Timeouts, Diagnosed

A CID that will not resolve almost always means one of three things: nothing is pinning the content, the provider record has not propagated, or the gateway is rate-limiting you. Work through them in that order. If you are reading this with a broken production app, start here: fetch the CID from your own pinning provider's dedicated gateway rather than a public one. If it loads there and not elsewhere, your problem is propagation or gateway load, not storage. If it fails there too, the content is not pinned anywhere you control. Now the full diagnostic. --- Step 1: Is anything actually pinning it? The most common cause, by a wide margin. Adding a file to a local IPFS node makes it addressable, not durable. The moment that node goes offline, gets garbage collected, or is a browser tab that the user closed, the bytes stop being served. The CID remains perfectly valid and resolves to nothing. Check whether your pinning provider actually has it. On Lighthouse, file info tells you directly. If the CID is not there, nothing else in this list will help — you need to pin it or re-upload. Signature symptom: it worked in development on your machine and fails everywhere else. Step 2: Has the provider record propagated? IPFS has to answer "who has this?" before it can fetch anything. That lookup runs against a distributed hash table, and DHT propagation is not instant. A file uploaded seconds ago may not be findable by an unrelated gateway yet. Signature symptom: a brand new CID 404s or hangs, then starts working minutes later without you changing anything. What to do: if you are uploading and immediately rendering, do not round-trip through a public gateway. Serve from the gateway of the provider that holds the content — it does not need the DHT to find its own data. This one change eliminates most "new upload does not load" reports. Step 3: Are you being rate-limited? Public gateways are shared infrastructure under permanent heavy load. They rate-limit aggressively, and they are not obliged to tell you politely. Signature symptoms: - HTTP 429, or a 504 after a long hang - Works from your laptop, fails from your server, or vice versa - Works intermittently, with no pattern related to the file - Fine for small files, times out for large ones What to do: stop using public gateways for anything in a product. They are for testing and for casual sharing. Production traffic belongs on a dedicated gateway where you are not competing with the entire ecosystem for throughput. Step 4: Is it the file, not the network? If the first three come back clean, look at the content itself. Size and streaming. A large file over a congested gateway will time out before it completes. If you are serving video, the fix is not a bigger timeout — it is range requests and a gateway built for streaming. Directory versus file. A CID pointing at a directory needs a path to a file inside it. <cid may return a listing while <cid/index.html returns the page. Check which you actually stored. Wrong CID. Case matters for Qm… v0 CIDs. If your identifier has been through a system that lowercases strings — a DNS record, an email client, a database column with a case-insensitive collation — it is silently corrupted. This is a strong argument for base32 CIDv1, which is case-insensitive by construction. Encrypted content. If the file was uploaded encrypted, fetching the CID returns ciphertext. That is not a failure; it is the system working. You need the decryption path, and the wallet that satisfies the access conditions. --- A quick decision table | Symptom | Most likely cause | Fix | |---|---|---| | Worked locally, fails in production | Not pinned anywhere | Pin it with a provider | | New upload 404s, works later | DHT propagation | Serve from your provider's gateway | | HTTP 429 or intermittent 504 | Public gateway rate limit | Move to a dedicated gateway | | Small files fine, large files hang | Gateway throughput | Streaming-capable gateway, range requests | | Returns a directory listing | Missing path | Append the file path to the CID | | Returns unreadable bytes | File is encrypted | Use the decrypt path | | CID rejected as malformed | Case-mangled v0 CID | Re-fetch the original, move to CIDv1 | --- Preventing it rather than debugging it Three habits remove most of this class of bug permanently. Pin at upload time, with a provider. Do not rely on a node you do not operate, and do not rely on a node you do operate but cannot guarantee is online. If the content matters, something durable has to be holding it — which is what a Filecoin deal or a Walrus blob underneath your pin is for. Serve from a dedicated gateway. Your users' first paint should not depend on shared public infrastructure. Lighthouse gateways are tuned for retrieval, including large media and 4K video, and are not competing with everyone else's traffic. Use CIDv1. Case-insensitive identifiers survive the trip through systems you do not control. If you want the durability layer underneath explained, our post on why Filecoin needs a hot layer covers how hot retrieval and cold durability fit together. --- Get Started - Pin an existing CID - File info - Retrieve a file - Contact support - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
What Is a CID? Content Identifiers, v0 vs v1, and How to Read One
Articlecalendar_todayAug 22, 2026

What Is a CID? Content Identifiers, v0 vs v1, and How to Read One

A CID is a content identifier: a fingerprint derived from a file's bytes, used as its address. Same file, same CID, on any machine, forever. Change one byte and the CID changes completely. That single property is what separates content addressing from the URLs you are used to. A URL says where something is. A CID says what something is. Everything else about IPFS follows from that swap. --- The mechanism, in one paragraph Hash the file. Take that hash, wrap it with a few pieces of metadata describing how it was produced and what kind of data it points at, and encode the result as a string. That string is the CID. Anyone who receives the file can hash it themselves and confirm it matches. No trust in the sender required. Anatomy of a CID A CIDv1 has four parts, and every one of them is self-describing. That is the design goal: a CID tells you how to interpret it without an external lookup table. | Part | What it says | Example value | |---|---|---| | Multibase prefix | How the string itself is encoded | b for base32 | | Version | Which CID format | 0x01 for v1 | | Multicodec | What the data is | dag-pb, raw | | Multihash | Which hash function, its length, and the digest | SHA-256, 32 bytes | The multihash is the interesting one. It does not just carry the digest — it carries which algorithm produced it. That is why IPFS can migrate to a new hash function without invalidating every identifier ever issued. v0 vs v1 You will see both. The difference is worth understanding because it causes real bugs. | | CIDv0 | CIDv1 | |---|---|---| | Looks like | QmXoypiz… | bafybeigdyrzt… | | Always starts with | Qm | usually b (base32) | | Encoding | base58btc, fixed | any multibase, usually base32 | | Hash function | SHA-256 only | any multihash | | Codec | dag-pb only | explicit, any codec | | Case sensitive | Yes | No, when base32 | | Subdomain gateway safe | No | Yes | The practical reasons to prefer v1: Case insensitivity. Base32 CIDv1 is all lowercase, which means it survives being lowercased by a DNS resolver, a mail client, or a database column. Qm… identifiers are case-sensitive base58 and get silently corrupted by anything that normalises case. Subdomain gateways. https://<cid.ipfs.gateway.example gives each CID its own origin, which matters for browser security boundaries. This only works with case-insensitive CIDv1. Explicit codecs. v1 tells you whether you are pointing at a raw block or a DAG node. v0 leaves you to infer it. Every v0 CID can be converted to v1 without touching the file, because the underlying digest is the same. The reverse only works if the v1 CID happens to use SHA-256 and dag-pb. --- Why the same file sometimes gives different CIDs This is the question that generates the most confusion, and the answer is not "the hash is unstable." Hashing a file is deterministic, but IPFS does not hash the file as one blob. It chunks the file, builds a DAG of those chunks, and hashes the DAG. So the CID depends on: - Chunk size. Default is 256 KiB. A different chunker produces a different tree and a different root CID. - DAG layout. Balanced versus trickle produces different structures. - CID version and codec used for the blocks. - Whether the file is wrapped in a directory. Two tools with different defaults will give you two different CIDs for byte-identical input. Neither is wrong. If you need reproducible CIDs across tools — and for anything contract-referenced you do — pin down the chunker and layout settings, and record them. What a CID does not give you Worth stating plainly, because assumptions here cause security incidents: - It is not access control. Anyone with the CID can fetch the content. See our post on whether IPFS is private. - It is not persistence. A CID is an address, not a promise that anyone is storing the bytes. Something has to pin it. - It is not encryption. The hash of a plaintext file is the address of a plaintext file. --- Working with CIDs on Lighthouse Every upload returns a CID, and every retrieval path is addressed by it. A few operations that come up constantly: Get a CID by uploading. The SDK returns it directly from the upload call. Bring a CID you already have. If content exists on IPFS and you want it pinned reliably, pin the existing CID rather than re-uploading. Same identifier, no duplication. Check what is behind it. File info resolves a CID to its metadata. Keep the CID across a backend change. Migrating from IPFS to Walrus preserves CIDs, so contracts and links that reference them keep resolving. That is only possible because a CID is derived from content, not from location. That last point is the whole argument for content addressing in one sentence: because the name comes from the data rather than the server, you can change everything about where and how it is stored without breaking a single reference. --- Get Started - Upload data and get a CID - Pin an existing CID - File info - Glossary - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Is IPFS Private? What Content Addressing Hides, and What It Doesn't
Articlecalendar_todayAug 22, 2026

Is IPFS Private? What Content Addressing Hides, and What It Doesn't

No. IPFS is not private. Anyone holding a CID can retrieve the file, and nothing about content addressing changes that. Privacy on IPFS requires encrypting before upload. This is the single most expensive misconception in decentralized storage, and the category has not been careful about correcting it. "Decentralized" and "private" get used as though they were the same property. They are not related at all. Here is what is actually true, what follows from it, and what you have to do if the data you are storing is sensitive. --- What a CID actually protects A CID is a hash derived from the content of a file. Change one byte and you get a different CID. That gives you two genuine and valuable properties: Integrity. If you retrieve a file and it hashes to the CID you asked for, it is byte-for-byte the file that was stored. Nobody has altered it in transit or at rest. You do not have to trust the node that served it. Verifiability. Anyone can perform that check independently. A CID published in a smart contract, a paper, or an audit log is a claim that anybody can verify without your cooperation. Neither of those is confidentiality. A CID is a name, not a lock. Knowing the name is enough to fetch the bytes. What it does not protect If your file is unencrypted and its CID is known, it is readable. That is the whole mechanism. There is no access check anywhere in the retrieval path, because IPFS was not designed to have one. Three consequences that surprise teams in production: Public gateways make it trivial. A CID pasted into any public gateway URL returns the file to anyone with a browser. No wallet, no node, no client software. "Unguessable" is not a security model. A CID is long, so people assume nobody will find it. But CIDs leak constantly — in transaction data, in API responses, in browser history, in logs, in the metadata of the NFT you just minted. Security that depends on a URL not being shared is not security, it is luck. Deletion does not un-publish. You can unpin a file from your own storage, but any node that fetched and cached it still has the bytes, and the CID still resolves for them. Content that reached the public network cannot be recalled. This is a property of the network, not a shortcoming of any particular provider. The part vendors gloss over Filecoin and Walrus do not change this either. They store the bytes they are handed. Hand them plaintext and they store plaintext, durably and verifiably, exactly as instructed. So "we store your data on Filecoin" tells you nothing about whether anyone can read it. Neither does "your data is decentralized." The question that matters is: at what point in the pipeline does the plaintext exist, and who can see it? For most pinning services and gateway providers, the honest answer is that plaintext exists on their infrastructure. They receive your file, they hold it, they serve it. Whether they read it is a policy promise, not a structural guarantee. --- What actual privacy requires Encrypt before the data leaves your client. Everything else is a detail of how you do that well. The naive version — encrypt with a key, store the ciphertext on IPFS — works, and immediately creates the real problem: where does the key live? If you keep it on a server, that server is now the thing that must never be breached, and you have rebuilt centralised trust on top of decentralised storage. If you give it to the user, you have built a system where losing a key means losing data, and where sharing a file means sharing a key you can never un-share. Lighthouse solves this with threshold encryption. Files are encrypted client-side, in the browser or runtime, before upload. The key is then split using BLS threshold cryptography and distributed across independent key nodes. No single node ever holds a complete key. To decrypt, a threshold of those nodes must each agree to release their share. Each one independently evaluates the access conditions the file owner set, against live chain state, before it does. There is no complete key sitting anywhere to steal, and no central authority that can be persuaded to hand one over. What that produces: - Lighthouse cannot read your files. We never hold plaintext and never hold a whole key. - Storage node operators cannot read them. Operators on IPFS, Filecoin and Walrus receive ciphertext. - A breach of Lighthouse infrastructure does not expose file contents. There is nothing there to take. That is a structural property rather than a promise, which is the difference that matters when someone asks you to justify a storage choice. Access control is the other half Encryption answers "can this be read." Access control answers "by whom," and on-chain conditions let you answer it without running an auth server. Decryption can be gated on: - ERC-20 balance thresholds - ERC-721 and ERC-1155 ownership - Native token balances - Return values from any custom contract you deploy, with comparators - Block heights and time windows - Passkeys and zkTLS proofs Conditions combine with boolean aggregators, files can be shared with named addresses under independent conditions, and access can be revoked after it is granted. The practical shape: a file is public by CID in the sense that anyone can fetch the ciphertext, and useless to everyone whose wallet does not satisfy the conditions. Verifiability and confidentiality at the same time, which are usually presented as a trade-off. --- So when is unencrypted IPFS fine? Often, and it is worth saying so. Store plaintext on IPFS when the content is genuinely public and you want it verifiable: NFT media that is meant to be seen, published datasets, static site assets, open research artifacts, software releases. In those cases content addressing is doing exactly the job it was designed for, and encryption would only get in the way. Encrypt when the file is personal data, commercially sensitive, subject to regulation, or gated behind a payment or membership. If you would not put it at a public URL, do not put it unencrypted on IPFS — because that is what you are doing. --- Get Started - Upload encrypted data - Encryption features: share, revoke, and condition access - Token gating with custom contracts - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Storing AI Training Data on Filecoin: Provenance You Can Prove
Articlecalendar_todayAug 22, 2026

Storing AI Training Data on Filecoin: Provenance You Can Prove

A CID turns "this model was trained on this dataset" from a claim into something checkable. Filecoin deals turn "the dataset still exists" into something a third party can verify without trusting you. Reproducibility, dataset licensing disputes, and regulatory questions about training data all reduce to the same problem: proving what data was used, and that it has not changed since. Content addressing solves the identity half. Storage deals solve the persistence half. --- The problem with "we trained on the public corpus" Almost every claim about training data is currently unfalsifiable. A dataset is described in a paper or a model card by name, size and source. Six months later the source has changed, the download link redirects somewhere else, and nobody can determine whether the artifact in hand is the artifact used. That matters in more places every quarter: Reproducibility. A result you cannot reproduce because the inputs drifted is not a result. Licensing and provenance. "Was this image in the training set?" is now a question with legal weight, and answering it requires knowing exactly what the training set contained. Regulatory disclosure. Emerging rules ask for records of training data. Records that cannot be verified are weak evidence. Model evaluation. Comparing two models fairly requires knowing they were evaluated on identical data, byte for byte. What a CID fixes A CID is derived from content. Publish the CID of your dataset alongside the model and anyone can confirm the artifact they have is the artifact you used. Not a file with the same name — the same bytes. Change one record and the CID changes. There is no way to quietly revise a dataset after publication while continuing to reference the original identifier. That property is the whole value: it makes the claim checkable by people who have no reason to trust you. Pair it with the deal record and you get the second half: proof that the data was genuinely committed to storage for a term, not merely hashed once and forgotten. --- A practical layout Store the dataset, get a CID. For large corpora, store shards individually and publish a manifest listing every shard CID. The manifest itself has a CID, which becomes the single identifier for the whole dataset. Record the CID wherever the model is described. Model card, paper, release notes, registry entry. Optionally anchor it on-chain, which adds a timestamp nobody can backdate. Verify the deals. Check deal status so you know the durability layer is real, and audit periodically so an expiry does not pass unnoticed. Version by publishing new CIDs. Never overwrite. Dataset v2 is a new CID and a new manifest; v1 remains verifiable forever. This is what makes a training-data history auditable rather than a moving target. Datasets that should not be public Much of the interesting data is proprietary, licensed under terms that forbid redistribution, or contains personal information. Content addressing alone publishes it to anyone holding the CID, which is the wrong outcome. Encrypt client-side and gate decryption on conditions instead. The dataset remains content-addressed and verifiable — the CID still proves which artifact it is — while the bytes are readable only by parties who satisfy your access rules. That combination is unusual and useful: verifiable without being public. A licensing counterparty, an auditor or a regulator can confirm the artifact is the one referenced, while access remains restricted to whoever you granted it to. Conditions can require holding a specific token, being a named address, falling within a time window, or satisfying a contract you deployed — and access can be revoked when a licence ends. The multi-party case follows naturally. Share one dataset with several research partners under independent conditions, each revocable separately, without maintaining an auth server or shipping copies. --- For agent and evaluation workloads The same argument extends past training data to everything an autonomous system produces. An agent that cannot prove what it read cannot be audited. Store the artifacts an agent acted on, record their CIDs in its logs, and the log becomes evidence rather than assertion — a claim that the input was not altered after the fact, checkable by someone who was not there. For evaluation sets specifically, the property that matters is that a benchmark cannot be quietly edited after results are published. A CID enforces that without anyone having to police it. Read why Filecoin needs a hot layer if you are serving datasets to training jobs at speed, and Walrus vs Filecoin if reads are continuous rather than occasional — for actively read data, Walrus is often the better backend. --- What this does not solve Worth stating so nobody over-claims. A CID proves the artifact is unchanged. It does not prove the data was collected lawfully, that consent was obtained, or that the contents are accurate or unbiased. It is a strong evidentiary primitive for one specific question — is this the same data — and silent on every other question about a dataset. That is still considerably more than the current baseline, which is a filename and a promise. --- Get Started - Upload data - Upload encrypted data - Check for Filecoin deals - Memory for agents - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
What Filecoin Storage Actually Costs in 2026
Articlecalendar_todayAug 22, 2026

What Filecoin Storage Actually Costs in 2026

Raw Filecoin storage is among the cheapest durable storage available, often a fraction of cloud object storage per terabyte. What you actually pay depends on whether you buy it raw or as a managed service, and the gap between those two is the honest part of the conversation. Prices in this post reflect August 2026. Storage pricing moves; check the pricing page for current figures. --- Three ways to pay Direct market access. Negotiate with storage providers, pay in FIL, run the pipeline. Cheapest per terabyte, and you take on deal-making, provider selection, monitoring, renewal and failure handling. Rational at petabyte scale with engineers assigned to it. A managed plan. A monthly or annual subscription covering storage plus the layers around it — hot retrieval, deal management, renewal, encryption, access control. Higher per terabyte than raw; the difference buys an operational function you would otherwise staff. Pay-per-use. Metered, no subscription. Suits variable or occasional usage, and it is the only model that works for autonomous systems, since an agent can settle in stablecoins per request rather than holding a plan. What Lighthouse charges | Plan | Storage | Price | |---|---|---| | Free | 5 GB | $0 | | Lite | 500 GB | $12/month | | Premium | 2.5 TB | $49/month | Annual billing is available at a discount — $120 and $499 respectively. Beyond Premium, volume and enterprise agreements are priced individually. The Walrus-backed plans are separate, starting at 100 MB free and $11/month for 250 GB. Walrus costs more per gigabyte and reads faster; Walrus vs Filecoin covers the trade. At Premium, 2.5 TB for $49/month works out around $0.02 per GB per month, with hot retrieval, deal management and renewal included, and no egress metering. --- What is actually in the price Comparing raw Filecoin rates against a managed plan is comparing different products. The plan includes: Hot retrieval. Sealed Filecoin data is slow to retrieve. A serving layer in front is not optional for real applications, and running your own gateways is a real cost. Deal lifecycle. Creation, provider selection, monitoring, and renewal before terms lapse. What happens when a deal expires explains why this is the part most self-managed setups get wrong. No token handling. No FIL to acquire, custody, or account for. See do you need FIL. No egress metering. Worth noting explicitly, because egress is where cloud bills surprise people. Encryption and access control, on the plans that include them. Whether that bundle is worth the premium over raw rates is a genuine question with a real answer either way. At small and medium scale it plainly is, because the alternative is a part-time job. At very large scale, with a team, direct access can win — and if you are at that scale you already know it. Versus cloud object storage Cloud storage looks competitive on the headline rate and diverges on the details. Egress is metered and expensive. Retrieval from archival tiers carries its own fees and delays. And you are buying a different product: an SLA rather than continuous on-chain proofs, with no third-party verifiability. Filecoin vs AWS S3 works through the comparison properly. If cost per gigabyte with no requirement for verifiability is the only criterion, commodity object storage is cheap and mature, and we would rather say so than pretend otherwise. --- Reducing what you spend Match the backend to the workload. Filecoin for archival volume, Walrus where read speed is the constraint. Paying Walrus rates for cold archives is waste. Do not store what you can derive. Retrieval-time image resizing means one stored original rather than a set of variants. Deduplicate by content. Content addressing does this for free — identical files share a CID. Right-size the term. Data with a knowable useful life does not need indefinite renewal. Deciding a retention period is cheaper than defaulting to forever. Start on the free tier. 5 GB, no card. Build the integration, measure real volume, then choose a plan against evidence rather than a guess. --- Get Started - Pricing - Pay per use - Get balance - Contact sales for volume pricing - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Why Filecoin Needs a Hot Layer
Articlecalendar_todayAug 22, 2026

Why Filecoin Needs a Hot Layer

Filecoin data is sealed, and sealed data is slow to retrieve. That is not a defect — it is the direct cost of the proofs that make the storage guarantee credible. The fix is not to make Filecoin fast; it is to put a hot layer in front of it. "Is Filecoin slow?" is the most common objection to the network, and the answer is yes for direct retrieval and largely irrelevant in practice, for reasons worth understanding rather than hand-waving. --- Why sealed data is slow Storage providers do not keep your file sitting on disk as an ordinary file. They keep a sealed replica: your data run through a slow, expensive encoding bound to their identity. Sealing is what makes Proof of Replication meaningful. Because producing a replica is costly, a provider cannot cheaply delete your data and regenerate it when challenged — so the rational strategy is to actually keep it. The economics of the whole system rest on that cost. The consequence is symmetrical: getting the original bytes back means unsealing, and unsealing is also work. A retrieval that has to start from sealed storage is measured in a timeframe that has nothing in common with a web request. You cannot have it both ways. Expensive sealing is what makes the storage guarantee credible, and it is what makes cold retrieval slow. A version of Filecoin with instant retrieval from sealed storage would be a version with weaker proofs. What the hot layer does Keep a copy of the content on IPFS, served from gateways tuned for retrieval, and put Filecoin deals underneath for durability. Request → IPFS hot layer → served in milliseconds │ └── Filecoin deals underneath sealed, proved, renewable Reads come from the hot layer. The Filecoin layer is doing something different: providing a verifiable, economically enforced commitment that the bytes persist, independent of whether any particular cache still holds them. Two systems, two jobs. The hot layer answers "give me this now." The cold layer answers "will this still exist, and can I prove it." --- Why not just use the hot layer? Because a pin is an instruction to a provider, not a commitment by a network. If the pinning provider goes away, so does the content — nothing is proving it exists anywhere else. Conversely, why not just use Filecoin? Because your users will not wait, and because a deal record does not serve a web page. The pairing is not a workaround. It is two components with different properties composed into something neither provides alone: fast reads with a durability guarantee that a third party can verify. What this looks like on Lighthouse You upload once. Content lands on the hot IPFS layer and is immediately retrievable; deals are made underneath and the durability layer builds up behind it. Practical consequences worth internalising: A new upload is retrievable immediately but will not have an active deal for a while. Both are normal — sealing takes time. See verifying your file is actually stored. Retrieval performance is a property of the hot layer, so gateway quality is what your users experience. This is why dedicated gateways matter more than the storage network for perceived speed. Durability is a property of the cold layer, so deal status is what you audit. Two different things to check, for two different concerns. --- The alternative: a faster cold layer Walrus takes a different approach to the same trade-off. Rather than sealed replicas with expensive encoding, it uses erasure coding, splitting blobs into slivers distributed across nodes and reconstructable from a subset. That yields fast reads directly from the storage layer, with roughly 5x overhead rather than the cost of full replication. Different point on the curve: Walrus is optimised for serving, Filecoin for long-term archival economics with continuous proofs. Neither is universally better, which is why we route to both. Our comparison, Walrus vs Filecoin, covers when to pick which. Even with Walrus, an IPFS layer for addressing and gateway retrieval remains useful — it is why Walrus-backed content on Lighthouse still gets CIDs and still resolves through the same gateways. --- The short version If someone tells you Filecoin is too slow to use, they are describing direct cold retrieval and treating it as the whole story. Nobody builds that way. The architecture everyone actually uses is hot serving with cold durability underneath, and in that arrangement the slowness of sealed retrieval is a property of a layer your users never touch. --- Get Started - Introduction to IPFS and Filecoin - Retrieve a file - Check for Filecoin deals - IPFS and Walrus - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Proof of Replication and Proof of Spacetime, Without the Math
Articlecalendar_todayAug 22, 2026

Proof of Replication and Proof of Spacetime, Without the Math

Proof of Replication proves a storage provider physically stored your data. Proof of Spacetime proves they still have it, repeatedly, for the whole term. One is a snapshot, the other is a movie. Together they answer the question every storage arrangement dodges: not "do you promise" but "can you demonstrate, right now, without me trusting you." --- The problem they solve Pay someone to store a file and there are three ways they can cheat. Store nothing and lie. Take the money, keep no data, hope nobody asks. Store one copy and sell it many times. Accept payment from a thousand clients for the same popular file, keep one copy, claim a thousand. Store it, then quietly delete it. Pass the initial check, free the disk afterwards, hope the term ends before anyone notices. Naive challenge-response defeats none of these reliably. Asking "send me byte 4,000" can be answered by fetching from someone else, or from a single shared copy. The proofs exist because the obvious approaches do not work. --- Proof of Replication PoRep proves that a provider created and stored a unique physical encoding of your specific data. Sealing is the mechanism. Before storage, the provider runs your data through a slow, deliberately expensive encoding process tied to both the data and their own identity. The output is a replica that only they could have produced. The design does two things at once: Uniqueness. Because the encoding is bound to that provider, they cannot pass off someone else's copy as theirs, and cannot dedupe a thousand clients' identical files into one stored copy while claiming a thousand replicas. Each replica costs real disk. Deliberate slowness. Sealing is expensive on purpose. If it were fast, a cheating provider could delete the data and re-seal on demand whenever challenged. Making it slow means the only economical strategy is to actually keep the sealed replica on disk — which is exactly the behaviour the protocol wants. That slowness is also why a file you uploaded a moment ago does not have an active deal yet. Sealing takes time, by design. Proof of Spacetime PoRep establishes storage at one moment. PoSt establishes that it continued. Throughout the deal term, providers are challenged at intervals and must produce proofs derived from the sealed replica. Answering requires having it — you cannot compute the response from a hash you wrote down, and you cannot regenerate the replica quickly because sealing is slow. Two flavours exist in practice: frequent lightweight challenges that catch sudden loss quickly, and periodic heavier ones that verify more thoroughly. The distinction matters to providers and rarely to clients. Miss the proofs and the provider is penalised economically against posted collateral. Storing your data is the profitable strategy; not storing it is the expensive one. The proof system does not make cheating impossible — it makes it irrational. --- Why this is different from an SLA A cloud provider's durability figure is a statistical claim about their internal infrastructure. It is credible because of the company's track record and its incentive to protect its reputation. You accept it because of who is saying it. Filecoin's proofs are public, continuous and checkable by anyone, including parties who trust neither you nor the provider. The deal record and the proofs are on chain. Verification does not require anyone's cooperation. Both are reasonable ways to gain confidence. Only one produces evidence you can hand to a third party. | | Cloud SLA | Filecoin proofs | |---|---|---| | Form | Contractual promise | Cryptographic proof | | Verified by | The vendor | Anyone | | Frequency | Audited periodically | Continuous | | Failure consequence | Service credits | Collateral penalty | | Usable as evidence | Weakly | Yes | --- What the proofs do not tell you Three limits worth being explicit about, because the proofs are sometimes described as covering more than they do. Not confidentiality. A proof that data is stored says nothing about who can read it. Providers store whatever bytes they are handed, plaintext included. Privacy is a separate layer, applied client-side before upload — see is IPFS private. Not retrieval speed. Proving you have sealed data is unrelated to serving it quickly. Sealed data must be unsealed, which is slow, which is why a hot layer sits in front — see why Filecoin needs a hot layer. Not permanence. Proofs run for the deal term. When it expires, so does the proving. What happens when a deal expires covers the consequences. --- Where this shows up in practice You will not implement any of this. What you get from understanding it is knowing what the deal record actually asserts, and therefore what it is worth as evidence. When you check deal status and see an active deal, you are seeing a provider who sealed a unique replica of your content and has been answering challenges about it ever since, with money at stake. That is a materially stronger claim than a green tick in a dashboard, and it is why decentralized storage is useful for audit trails, provenance and regulated records rather than merely cheaper. --- Get Started - Check for Filecoin deals - How Filecoin storage deals work - Glossary - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
What Happens When a Filecoin Deal Expires?
Articlecalendar_todayAug 22, 2026

What Happens When a Filecoin Deal Expires?

The provider's obligation ends. They stop being required to store your data, stop submitting proofs, and get their collateral back. Whether the bytes survive after that is no longer guaranteed by anything. Deals are terms, not perpetuities. Everything about managing storage on Filecoin follows from that, and almost nothing written about the network says it clearly. --- At the moment of expiry Three things happen, none of them dramatic: Proving stops. The provider is no longer challenged and no longer submits Proof of Spacetime for that piece. The continuous verification that made the arrangement credible simply ceases. Collateral is released. The economic stake that made failure costly is returned. There is nothing left at risk, and therefore nothing left compelling the provider to care. The data may or may not remain. A provider might keep it — disk is not always urgently needed, unsealing is work, and deleting is also work. But nothing obliges them, and you have no claim. Notably, nothing errors. No alert fires unless you built one. Retrieval may keep working for a while from the hot layer or from caches, which is exactly what makes this failure mode dangerous: the moment of expiry is invisible, and the consequences arrive later. --- The failure pattern It goes like this. Storage is set up carefully. Deals are made for a term that feels comfortably long. The people who set it up move on to other work, or other jobs. Eighteen months later the term lapses on an unremarkable Tuesday. Retrieval still works, because a hot layer is caching the content. Six months after that, cache pressure evicts it. Now a CID that has been in a contract, a paper, or a compliance record for two years resolves to nothing, and the deal that would have restored it ended long ago. Nobody did anything wrong at any single step. The system did precisely what it promised for precisely as long as it promised. Why the protocol works this way It is a consequence of the economics, not an oversight. A storage provider commits real hardware and real collateral. To do that rationally, they need a bounded, priced obligation. An unbounded one cannot be priced, because nobody knows what storage costs in 2050, and a provider agreeing to it is either mispricing risk or planning not to honour it. Bounded, renewable terms are what make the commitment credible in the first place. The alternative — indefinite obligation — is what Arweave attempts with a different economic structure, funded by an endowment rather than by a provider's willingness to be bound forever. We compare the two approaches in Filecoin vs Arweave. --- Renewal Renewal means making a new deal before the old one lapses. Mechanically it is the same process as the original: propose, accept, seal, prove. Doing that yourself means tracking expiry per piece of content, monitoring which deals are approaching term, initiating new ones early enough that sealing completes before the old deal ends, handling providers who decline, and keeping enough FIL on hand throughout. Across thousands of CIDs, it is a system, not a task. This is a large part of what Lighthouse actually does. Deal creation, provider selection, monitoring and renewal are handled on your behalf, so the term keeps rolling without anyone maintaining a spreadsheet of epochs. You upload a file and get a CID; the deal lifecycle underneath is our operational problem. That is a service rather than a protocol guarantee, and the distinction is worth keeping straight. The protocol gives you a verifiable bounded commitment. We give you the assurance that the commitment keeps being renewed. Both are real; they are different kinds of promise. What you should still do Check deal status for content that matters. Check for Filecoin deals shows current state and term. Verifying periodically is the difference between believing your data is stored and knowing it. Keep your CID list outside the storage system. It is what you audit against. Ask about renewal explicitly. Whoever manages your storage, know what the policy is and what happens if payment lapses. "It is on Filecoin" is not a retention policy. Do not describe it as permanent. If you are building on this and telling users their data is stored forever, you are making a promise the protocol does not make, and you will not be the one who gets to decide whether it holds. --- Get Started - Check for Filecoin deals - How Filecoin storage deals work - Upload data - Pricing - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
How Filecoin Storage Deals Work: Terms, Epochs and Renewal
Articlecalendar_todayAug 22, 2026

How Filecoin Storage Deals Work: Terms, Epochs and Renewal

A Filecoin storage deal is a contract between a client and a storage provider: hold this data for this many epochs, prove it continuously, get paid. When the term ends, the obligation ends. Renewal is a new deal. That last sentence is the one most explanations skip, and it is the one that determines whether your data is still there in three years. --- The lifecycle Proposal. A client offers a deal: this piece of data, this size, for this duration, at this price. Data is identified by a piece CID, derived from the content in a form suited to the proving process. Acceptance and sealing. A provider accepts and seals the data — an expensive, deliberately slow cryptographic process that produces a unique encoding of your data tied to that specific provider. Sealing is what makes it impossible to claim to store one copy while actually storing none, or to dedupe your copy against another client's. Activation. The deal goes on chain. From here it is publicly verifiable: anyone can see that this provider committed to hold this piece for this term. Proving. For the whole term, the provider submits proofs on a schedule. Miss them and they are penalised economically. This is the part that makes the commitment credible rather than promissory. Expiry. The term ends. The obligation ends with it. The provider may keep the data or may not. Epochs Filecoin measures time in epochs of 30 seconds. Deal durations, proving deadlines and penalties are all denominated in them. A one-year deal is roughly 1,051,200 epochs. You rarely need to think in these units directly, but it explains why Filecoin durations look like arbitrary large numbers rather than dates, and why renewal is a scheduled operation rather than a subscription that silently rolls. The two proofs Proof of Replication (PoRep) establishes that a provider has physically stored a unique encoding of your data. Not a pointer to someone else's copy, not a deduplicated reference — their own sealed replica. Proof of Spacetime (PoSt) establishes that they still have it, repeatedly, for the duration. Providers are challenged at intervals and must respond with proofs derived from the sealed data. Together they answer "do you have it" and "do you still have it," continuously, on chain, with money at stake. That is a materially different guarantee from a service telling you your file is safe. We cover both in more depth in proof of replication and proof of spacetime, without the math. --- What a deal does not give you Fast retrieval. Sealed data is not sitting in a hot cache ready to serve. Getting it back means an unsealing process, which is slow. This is why Filecoin is paired with a hot layer rather than used directly for serving — see why Filecoin needs a hot layer. Indefinite retention. The commitment is bounded by the term. Anyone describing Filecoin as permanent storage is describing something the protocol does not provide. What it provides is a verifiable commitment for a defined period, renewable. Automatic renewal. Nothing in the protocol renews a deal for you. Someone or something has to make a new one before the old one lapses. That last point is where self-managed Filecoin storage most often goes wrong. The deal was made, the proofs were submitted faithfully for the full term, and then it expired on a Tuesday eighteen months later while nobody was watching. --- What Lighthouse does with all this The reason most teams do not interact with deals directly is that doing it properly means running infrastructure, selecting providers, monitoring proofs and tracking expiry across every piece of content you have ever stored. We handle deal creation and management on your behalf: provider selection, deal making, monitoring and renewal. You upload a file and get a CID. Underneath, the data goes into deals, and the term keeps rolling. Two things you can still check yourself, and should: Deal status. Check for Filecoin deals resolves a CID to its deals and their state. Verify rather than assume, particularly for content that matters. Timing. Sealing takes time. A file uploaded a minute ago is retrievable from the hot layer immediately and will not have an active deal yet. Both things are normal and they are not the same milestone. The honest summary Filecoin gives you something unusual: a storage commitment that a third party can verify without trusting either you or the provider. The deal is on chain, the proofs are on chain, and the economics punish failure. What it does not give you is permanence, and the ecosystem — us included, in older posts — has been loose about that. Retention is a term you buy and renew. Managed well, that is durable storage with better guarantees than a contract with a cloud provider. Described as forever, it is a promise the protocol was never designed to make. --- Get Started - Check for Filecoin deals - Upload data - Introduction to IPFS and Filecoin - Glossary - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
How to Verify Your File Is Actually Stored on Filecoin
Articlecalendar_todayAug 22, 2026

How to Verify Your File Is Actually Stored on Filecoin

Check the deal. A CID that resolves proves someone is serving the bytes right now; it does not prove a storage deal exists. Those are different claims, and only one of them is a durability guarantee. This distinction is the most useful thing to understand about verifying decentralized storage, and it is where most people's mental model is fuzzy. --- Two different questions "Can I fetch it?" answered by requesting the CID. A successful fetch means some node has the blocks and is willing to serve them. That could be a durable storage deal, or it could be a cache that expires next Tuesday. "Is it committed to storage?" answered by looking at the deal. A deal is an on-chain record: this provider agreed to hold this piece for this term, and is submitting proofs. Content you can retrieve is not necessarily content that is stored. The gap between those two is where data quietly disappears — see do files on IPFS disappear. --- Checking on Lighthouse Use check for Filecoin deals with your CID. It returns the deals associated with that content and their state. What to look for: - A deal exists at all. No deal means the content is pinned on the hot layer only. - Deal state. Proposed, active or expired are meaningfully different. Only active is a live commitment. - The provider. Which storage provider holds it. - The term. When it ends, which is the input to renewal. Because the record is on chain, you can corroborate independently with a Filecoin block explorer using the deal ID or piece CID. You do not have to trust our API's answer about our own service, and for anything you would need to defend later, you should not. Timing: why a new upload has no deal The most common false alarm. You upload a file, check immediately, and find no deal. That is expected. Uploading puts content on the hot IPFS layer, where it is immediately retrievable. Making a Filecoin deal is a separate, slower process — the data has to be aggregated, proposed, accepted and sealed, and sealing is deliberately computationally expensive. So there is a window where your file is retrievable and does not yet have a deal. Both states are normal. Check again later rather than concluding something failed. --- Building verification into your process For content that matters, a one-off manual check is not enough. Two habits worth adopting: Verify at ingestion, on a delay. Queue a deal-status check for some hours after upload, and alert if no active deal appears. This catches systematic problems — a misconfigured integration silently storing nothing durable — while they are still cheap to fix. Audit periodically. Walk your CID list against deal status on a schedule. What you are looking for is content whose deals expired without renewal, and content that never got a deal in the first place. Both are silent failures: nothing errors, retrieval may still work from cache, and the durability you believe you have is not there. That second one is exactly the audit that turns up unpleasant surprises in storage set up years earlier by people who have since left. Keep your own CID list Worth stating separately because it gets overlooked. Your list of CIDs is the only record of what you asked to have preserved. Without it, you cannot audit, because you have nothing to audit against — you can only inspect what your provider says it has, which is the wrong direction. Store it somewhere outside the storage system it describes. --- What verification gives you that a dashboard does not Any storage vendor can show you a green tick. What is unusual about Filecoin is that the commitment is a public record, checkable by anyone, including people who do not trust you. That is what makes it useful for evidence rather than reassurance. If you are storing compliance documents, audit trails, research artifacts or agent decision records, the deal record plus the CID lets a third party confirm both that the content is unaltered and that storage was genuinely arranged. Neither claim requires them to take your word, or ours. Our post on how Filecoin storage deals work covers the proof mechanics that make the record meaningful. --- Get Started - Check for Filecoin deals - File info - List files - Contact support - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Do You Need FIL to Store Files on Filecoin
Articlecalendar_todayAug 22, 2026

Do You Need FIL to Store Files on Filecoin

No. You can store data on Filecoin without ever holding FIL, using a service that handles the token side for you. Pay by card or in stablecoins, and never touch an exchange. Interacting with the protocol directly does require FIL — deals are paid in it, and collateral is denominated in it. But for the overwhelming majority of developers, that is an implementation detail of a layer you never have to operate. --- Why the question comes up The direct path looks like this: acquire FIL on an exchange, move it to a wallet compatible with Filecoin, run or connect to a node, negotiate deals with storage providers, manage the FIL balance as deals are made and renewed, and monitor proofs. That is a reasonable amount of work before a single file is stored, and it introduces problems that have nothing to do with storage: exchange accounts, KYC, custody of a volatile asset, treasury policy, and accounting for a token balance that fluctuates. For most teams, none of that is work they wanted. What a storage provider service changes Lighthouse sits above the protocol. You upload a file and receive a CID. Underneath, deals are created and managed on your behalf, provider selection is handled, and renewal keeps the term rolling. You pay us in ordinary ways: - Card, on a monthly or annual plan - Stablecoins, including USDC on Base through x402 for pay-per-use - On-chain token payment, if you prefer - Metered pay-per-use, for volumes that do not fit a plan No FIL anywhere in that list. You are buying storage, and the token mechanics stay on our side of the boundary. There is also a free tier — 5 GB on the Filecoin path — which requires no payment method at all. Enough to build the integration before deciding what it costs. --- But is it still really Filecoin? Fair question, and the answer is yes in the way that matters: your data goes into actual storage deals with actual providers, sealed and proved on chain. You can verify this rather than take our word for it. Check for Filecoin deals resolves a CID to its deals and their state. The deal record is public — that is the entire point of putting it on chain. If we claimed to store something on Filecoin and had not, the absence would be visible to anyone who looked. That verifiability is worth more than the token-handling convenience, and it is a good habit to actually exercise for content you care about. Our post on verifying your file is actually stored walks through it. --- When you do want to hold FIL Not never, and it is worth being straight about the cases: You are running a storage provider. Providers post collateral in FIL and are penalised in FIL. The token is unavoidable on that side. You are building protocol-level infrastructure — deal-making tooling, market analytics, provider software. You want direct market access at very large scale. If you are storing petabytes and have the engineering capacity to run the pipeline, negotiating directly with providers can beat a managed service on unit cost. The trade is that provider selection, deal monitoring, renewal and failure handling all become yours. You are participating in network governance or economics for reasons unrelated to storing your own files. For everyone else — application developers, teams archiving data, anyone who wants verifiable storage without a new treasury line item — the token is a detail of a layer somebody else operates. --- The equivalent question elsewhere The same confusion recurs across storage networks, and the answer is the same shape each time. Walrus storage is coordinated and paid for on Sui, and you can use it through Lighthouse without holding SUI, running a Sui node, or managing epochs. Stablecoin payment through x402 works there too. The general principle: a network's native token is how the network's internal economics work. It does not follow that consuming the network requires you to participate in them. --- Get Started - Create an API key and start on the free tier - Upload data - Check for Filecoin deals - Pay per use - Pricing --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Filecoin vs AWS S3: An Honest Comparison
Articlecalendar_todayAug 22, 2026

Filecoin vs AWS S3: An Honest Comparison

S3 wins on latency, tooling and operational maturity. Filecoin wins on verifiability, provider independence and censorship resistance. If you need the second set of properties, you can now have them without giving up the first set of ergonomics. Most comparisons on this topic are written by people selling one of the two. We sell access to the second, so here is the version with the concessions left in. --- Where S3 is simply better Latency. Single-digit millisecond first-byte times from a nearby region, consistently, at any scale. Filecoin data is sealed and cold; retrieval requires unsealing or a hot cache in front. Even with a well-run hot layer, you are not beating a warm S3 object in the same region. Operational maturity. Two decades of tooling, monitoring, lifecycle policies, IAM, and every consultant on earth knowing how it works. This is worth more than teams admit until they are debugging at 3am. Ecosystem integration. Every framework, every CI system, every analytics tool speaks S3 natively. Regional control. Need data in Frankfurt and only Frankfurt, for a regulator who wants it in writing? S3 gives you that with a checkbox. Filecoin's provider set is global by design. Predictable cost at low volume. Small workloads on S3 are cheap and the pricing is well understood, even if egress fees are notoriously unpleasant at scale. If none of the properties in the next section matter to you, use S3. That is a real recommendation, not a rhetorical concession. --- Where Filecoin gives you something S3 cannot Verifiability by a third party. An S3 object is whatever AWS returns. There is no way for an outside party to confirm the file you served is the file you originally stored, and no way to prove it was not altered. A CID plus an on-chain deal record lets anyone check both, without your cooperation. For audit trails, published datasets, regulatory evidence and provenance claims, this is not a nice-to-have; it is the entire requirement. Continuous proof of storage. Providers submit PoRep and PoSt proofs on a schedule with collateral at risk. AWS's durability figure is a statistical claim about their infrastructure that you accept because it is AWS. Both are credible. Only one is checkable. Provider independence. Content addressed by CID can be served by anyone holding the bytes. Moving between providers does not change identifiers, so nothing downstream breaks. S3 keys are bound to a bucket in an account with a vendor; migration is a project. Censorship resistance. A single company can decide to stop serving your data. A market of independent providers is much harder to lean on. No egress cliff. Data transfer costs are a well-known reason S3 bills surprise people at scale. --- Side by side | | AWS S3 | Filecoin, via Lighthouse | |---|---|---| | First-byte latency | Milliseconds | Hot layer dependent | | Durability claim | Vendor SLA | On-chain proofs | | Third-party verification | No | Yes, via CID and deal | | Provider lock-in | High | None; CIDs are portable | | Regional pinning | Precise | Not by design | | Egress cost | Significant at scale | Not metered the same way | | Encryption | At rest, vendor holds keys | Client-side, threshold, vendor holds nothing | | S3 API compatibility | Native | Yes, via L3 | | Ecosystem tooling | Enormous | Growing | --- The row that surprises people Encryption. S3 encrypts at rest, and by default AWS manages the keys. That protects against a stolen disk. It does not mean the operator cannot read your data — with SSE-S3 or SSE-KMS, they hold the keys. You can bring your own with SSE-C, at which point key management is your problem and the ergonomics get worse. With Lighthouse, files are encrypted client-side before upload, and the key is split with BLS threshold cryptography across independent nodes so that no single node ever holds a complete key. We cannot read your files. Storage providers cannot read your files. Breaching our infrastructure does not expose contents, because there is no plaintext and no whole key to take. Access control then runs on-chain conditions rather than IAM policies: token balances, NFT ownership, custom contract return values, time windows, passkeys, zkTLS proofs, combined with boolean logic, with revocation. For multi-party scenarios — each counterparty decrypting only their portion of a document set — that is considerably more expressive than a bucket policy. You do not have to rewrite anything The usual objection is migration cost. That is what L3 is for: an S3-compatible endpoint with AWS Signature V4 auth, path-style addressing, buckets, keys, multipart uploads and presigned URLs. Point the AWS CLI, boto3, aws-sdk-js or rclone at it and files land on Lighthouse, content-addressed and backed by Filecoin deals. Every object response carries its CID in the x-amz-meta-cid header, so you get content addressing without touching client code. S3 credentials are self-served by exchanging a Lighthouse API key. Read the S3 and IPFS semantics reference before storing anything sensitive, because mutable S3 operations map onto immutable content addressing in ways that matter for overwrite and delete behaviour. That is a genuine sharp edge, not a formality. Amazon S3 is a trademark of Amazon.com, Inc. Lighthouse is not affiliated with or endorsed by Amazon; S3 is referenced here to describe protocol compatibility. --- How to decide Ask what happens if someone challenges your data six years from now — a regulator, a counterparty, a court, an auditor. If "our cloud provider says so" is a sufficient answer, S3 is fine and cheaper to operate. If you need to prove the artifact is unaltered and the storage was real, that is what content addressing and on-chain proofs are for. And if the answer is "both, for different data," that is the normal case: transactional and latency-sensitive data on S3, verifiable artifacts and archives on Filecoin, S3 ergonomics on both sides through L3. --- Get Started - L3, the S3-compatible API - Create S3 keys - S3 and IPFS semantics - Limits and differences - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Filecoin vs Arweave: Renewable Deals or Pay-Once Endowment?
Articlecalendar_todayAug 22, 2026

Filecoin vs Arweave: Renewable Deals or Pay-Once Endowment?

Filecoin sells storage as a renewable term with continuous cryptographic proofs. Arweave sells a one-time payment into an endowment intended to fund storage indefinitely. Neither is strictly better; they are bets on different things. The choice comes down to a question about your own organisation: would you rather have a commitment you must actively maintain, or one that depends on an economic model holding up for decades without you? --- The two models Filecoin. You make a deal for a duration. A provider seals your data and submits proofs on a schedule for the whole term, with collateral at risk if they fail. When the term ends, the obligation ends, and continuing means a new deal. Storage is an ongoing relationship with ongoing cost. Arweave. You pay once, up front. A portion funds immediate storage; the rest goes into an endowment. The model assumes the real cost of storage keeps falling — as it historically has — so the endowment's yield outpaces the declining cost of keeping your data, indefinitely. Storage is a purchase rather than a subscription. The difference is not decentralization, proofs, or ideology. It is who carries the long-run risk, and in what form. --- Side by side | | Filecoin | Arweave | |---|---|---| | Payment | Recurring, per term | One-time, up front | | Retention | Deal duration, renewable | Intended indefinite | | Storage proofs | PoRep and PoSt, continuous | Proof of Access | | Long-run risk | You must renew | Endowment economics must hold | | Cost visibility | Known per term | Paid once, no future line item | | Provider market | Competitive, you can move | Network-wide | | Retrieval | Cold; needs a hot layer | Gateway-served | | Best for | Large volumes, active management | Set-and-forget artifacts | --- The case for Filecoin The commitment is continuously verified. Proofs are submitted on a schedule for the life of the deal, with economic penalties for failure. You are not trusting a projection; you are watching an obligation being met, on chain, in the present tense. Cost scales with what you actually need. Storing a large dataset for two years costs two years, not forever. For anything with a natural lifespan — logs, intermediate artifacts, datasets superseded by better ones — paying indefinitely for something you will stop caring about is waste. A competitive provider market. Providers compete on price, and you can move between them. Prices have generally fallen. Better economics at volume. For terabyte-scale archival, renewable deals are typically cheaper than an up-front endowment payment covering the same data. The case for Arweave No renewal to forget. This is a real operational advantage, and the honest version of the Filecoin critique. Renewal is a process, and processes fail. A team that stops existing stops renewing. If the artifact must outlive the organisation that stored it, a model that requires nobody to do anything has a genuine structural edge. Well matched to permanent public records. Provenance records, published research, historical archives, anything intended to be citable in fifty years. The design goal and the use case line up. One line item, then done. Some finance functions strongly prefer a capital cost to a recurring one. The honest caveat is symmetrical. The endowment model depends on storage costs continuing to fall at rates that outpace the endowment's drawdown, across decades. That has held historically. It is a bet on economics rather than a cryptographic guarantee, and it should be evaluated as one. --- Choosing Choose Filecoin when you are storing at volume, the data has a knowable useful life, cost per terabyte matters, or you want retention that is continuously proved rather than projected. Also when you want the option to move providers. Choose Arweave when the artifact is small, public, and meant to be permanent, and when the risk you most want to eliminate is your own organisation forgetting to act. A pattern worth considering: they are not exclusive. Anchor the small permanent record — the manifest, the hash list, the provenance document — on Arweave, and keep the bulk data on Filecoin under renewable deals. You get a durable pointer that survives you, and sane economics on the terabytes. Where Lighthouse sits We are not a storage network and we do not compete with either. We route to Filecoin and Walrus, and add the layers those networks deliberately do not provide: client-side threshold encryption, on-chain access control, and deal management. That last one is directly relevant here. The main practical objection to Filecoin's model — renewal is a process and processes fail — is a service problem, and it is the service we run. Deal creation, provider selection, monitoring and renewal happen on your behalf. Which does not make the objection disappear, it relocates it. With Arweave you bet on endowment economics. With managed Filecoin you bet on a provider continuing to manage. Be clear-eyed about which risk you prefer, because there is not an option with neither. Also worth stating plainly: our older posts used pay-once and permanent-storage framing for a product that no longer works that way. Retention on Lighthouse is a renewable term. If you specifically want the pay-once model, Arweave is the honest answer, and it is not us. --- Get Started - How Filecoin storage deals work - Check for Filecoin deals - Introduction to IPFS and Filecoin - Create an API key and start on the free tier --- Stay in Touch To learn more about Lighthouse, visit the official website, read the documentation, or jump in on GitHub. You can also join the community on Discord, X, Telegram, or LinkedIn.

5 min readarrow_forward
Lighthouse x Base: Storage That Agents Can Pay For Themselves
Articlecalendar_todayAug 17, 2026

Lighthouse x Base: Storage That Agents Can Pay For Themselves

Base solved how machines pay. Lighthouse solved where their data lives. x402 joins them. For most of the last decade, teams solved storage and payment separately. You provisioned capacity ahead of time, put a credit card on file, and hoped your forecast was close. That model assumes a human is somewhere in the loop, watching a dashboard, approving an invoice. Autonomous software breaks that assumption. An agent that needs to persist an artifact at 3am does not have a procurement process. It has a wallet. This is why the Lighthouse and Base combination matters, beyond a simple chain integration. Base gives machines a settlement layer with stablecoins and sub-cent fees. Lighthouse gives them storage that is content addressed, encrypted before it leaves the client, and gated by conditions those same chains can evaluate. Together, an agent can buy storage, store data, prove what it stored, and control who reads it, without a human touching any step. Here is how it works and what you can build with it. --- x402: Pay Per Upload, in USDC, on Base x402 takes the HTTP 402 Payment Required status code, which has been a placeholder in the spec since the 1990s, and makes it a real protocol step. Instead of returning 402 as a dead end, the server returns it as a quote. The flow is four moves: !Four-step vertical flow diagram.png 1. Your client POSTs a file to the upload endpoint. 2. The server responds 402 with a price and a payTo address. Pricing is dynamic, based on file size. 3. The client pays USDC on Base mainnet, automatically. 4. The client retries with payment proof, and the server responds 200 with the CID. No API key. No pre-funded balance. No subscription. The client library handles the payment leg, so from your code it reads like an ordinary fetch that happens to cost money. javascript import { x402Client, wrapFetchWithPayment } from "@x402/fetch"; import { registerExactEvmScheme } from "@x402/evm/exact/client"; import { privateKeyToAccount } from "viem/accounts"; import { statSync, openAsBlob } from "fs"; const SERVERURL = process.env.SERVERURL || "http://localhost:12000"; const signer = privateKeyToAccount(process.env.PRIVATEKEY); const client = new x402Client(); registerExactEvmScheme(client, { signer }); const fetchWithPayment = wrapFetchWithPayment(fetch, client); const filePath = "./myfile.pdf"; const fileBlob = await openAsBlob(filePath); const response = await fetchWithPayment(${SERVERURL}/api/upload, { method: "POST", headers: { "Content-Type": "application/octet-stream", "Content-Length": String(statSync(filePath).size), "x-file-name": "myfile.pdf", }, body: fileBlob, }); const { cid, ipfsUrl } = await response.json(); That is the entire integration. openAsBlob streams from disk rather than buffering the file in memory, which matters when the thing calling this is a long-running process handling files it did not choose the size of. Two things worth knowing that the code does not show. You get a settlement receipt. The response carries a PAYMENT-RESPONSE header containing base64-encoded JSON with the transaction hash and the payer address. Decode it and you have an onchain reference on Base mainnet, chain ID 8453, verifiable on BaseScan by anyone. The upload produced two independently checkable facts: a CID that proves what was stored, and a transaction that proves what was paid. For agent workloads, that pairing is the audit trail. Storage has a term, and renewal is also an x402 call. Files stored through the x402 path on IPFS and Filecoin carry a one-year storage period. Renewing is the same pattern against /api/renew with an x-file-id header, payment handled automatically. Retention is a deal term that Lighthouse manages, not a promise of forever, and the renewal endpoint is how you extend it. An agent can be given a budget and a renewal schedule and left alone. x402 works on both storage paths. For IPFS and Filecoin, follow the pay-per-use upload tutorial. For Walrus-backed blob storage, the Walrus x402 guide points at a hosted endpoint at x402-walrus.lighthouse.storage, so you can pay in USDC on Base for storage that settles on Sui without touching Sui infrastructure. One wallet, one payment rail, two storage networks underneath. --- Encryption and Access Control, Evaluated Against Base Pay-per-use solves who pays. It does not solve who reads. That's the second half of the integration, and often the more important one for Base builders. Public IPFS is not private. Anyone holding a CID can retrieve the bytes. Filecoin and Walrus store whatever they are given, plaintext included. "Decentralized" and "private" get used interchangeably across this category, including by vendors who know better. They are not the same property, and conflating them is how sensitive data ends up publicly addressable. Lighthouse encrypts client-side through Kavach before anything leaves the browser or runtime. The encryption key is split with BLS threshold cryptography and distributed across independent key nodes, so no single node ever holds a complete key. Reconstruction requires a threshold of nodes to participate, and each node independently evaluates your access conditions before releasing its share. The practical consequence: Lighthouse cannot read your files. Neither can storage node operators on IPFS, Filecoin, or Walrus. Compromising Lighthouse infrastructure does not expose file contents, because there is no plaintext and no complete key to take. Because Base is an EVM chain, the full condition set applies to your Base contracts and tokens: !Minimalist tree showing access control.png - ERC-20 balance thresholds. Hold 100 of a token to decrypt. - ERC-721 and ERC-1155 ownership. Gate on holding a specific NFT or collection. - Native balance conditions. Gate on ETH held on Base. - Custom contract return values. Point at any contract on Base, call a method, compare the result with equality or greater-than or less-than. This is the general case: if your logic can be expressed in a Base contract, it can gate decryption. - Block number and time windows. Release a document at a block height, or inside a date range. - Passkeys and zkTLS proofs. Identity conditions that do not require a token at all. You compose conditions with boolean aggregators. Require all of a set, or any one of them. Grant access directly to named addresses. Share a single file with multiple parties under independent conditions. Revoke access after granting it. Here's the pattern for Base contracts, and teams still get it backwards: contracts cannot initiate uploads. Your application uploads through Lighthouse, receives a CID, and stores it in the contract. Onchain byte storage costs gas proportional to size, which makes storing file bytes onchain impractical. A CID is a compact, verifiable pointer to bytes that live where bytes should live, with encryption and access rules attached. --- What Base Builders Can Actually Ship Base's app surface maps cleanly onto the categories already building on Lighthouse. Working across our ecosystem, the same handful of shapes keep recurring. !use case.png Consumer social and creator apps. User-generated content at scale, served through gateways tuned for retrieval, including 4K video streaming and image resizing applied at retrieval time rather than by storing variants. Token-gated media where a Base contract decides who decrypts. Base offers a low-cost path to consumer scale in the EVM world, and consumer apps generate substantial storage per user. Onchain media and NFTs. Metadata and media addressed by CID and referenced from your Base contracts. Unlockable content behind ownership conditions. Pay-to-view media where a payment contract gates decryption, which composes neatly with x402: the buyer pays onchain, the contract state changes, the key nodes see the new state and release shares. Agent and AI applications. Covered in the next section, and a growing category across our platform. DePIN and device networks. Sensor and telemetry data persisted with verifiable addressing, encrypted so the network operator cannot read payloads, with proof-of-contribution records where tamper evidence is the point. RWAs, documents, and compliance. This is where per-recipient conditions earn their keep. A KYC packet can be shared with each reviewing party under independent conditions, and revoked when the relationship ends. An audit trail where the CID proves a filing was not altered after submission. Multi-party agreements where each counterparty decrypts only what their role permits. Data availability and modular infrastructure. Content-addressed blobs with verifiable references, payload offchain, CID anchored onchain. --- The Agentic Case, Stated Directly The reason this integration exists is that autonomous systems have a data problem that nobody solved on their behalf. An agent that cannot prove what it read cannot be audited. An agent that loses state cannot be trusted with any task longer than a session. An agent operating on data nobody can verify produces outputs nobody can defend. As models converge and get cheaper, differentiation moves down the stack, to what the agent remembers and whether that memory holds up under scrutiny. Five layers, and Base supplies one of them: 1. Persistence. Files and blobs on IPFS, Filecoin, or Walrus. 2. Addressing. CIDs derived from content, so later alteration is detectable. 3. Confidentiality. Kavach threshold encryption with per-party conditions. 4. Memory. Semantic recall over stored context, exposed through MCP. 5. Payment. x402 on Base for autonomous settlement. Layer 5 is the one that removes the human. Everything else can be built with an API key that somebody has to fund. x402 on Base means the agent funds itself. On layer 4, Memory gives agents remember, recall, and forget primitives, with every memory persisted as a verifiable blob addressed by an IPFS-compatible CID. Since memory lives on the network rather than inside one app or session, an agent resumes across sessions, machines, and runtimes. Rebuild the entire store on a fresh machine from nothing but an API key. Semantic recall runs locally with an in-process embedding model, so no embedding data leaves the machine and no second API key is required. A bundled MCP server exposes all of it as tools to Claude Code, Claude Desktop, and any MCP-capable runtime. !Machine memory persists between ….png One honest caveat: Memory blobs are currently stored unencrypted. Anyone with the CID can read them. Do not put secrets in Memory yet. Encrypted memory follows our encrypted upload support. Everything in the encryption section above applies to file uploads today, not to Memory. The patterns worth building on this stack: agent memory across sessions and machines; decision receipts, where a CID turns an action log into evidence rather than assertion; training and evaluation datasets shared under conditions and revocable later; multi-agent coordination over shared encrypted state with per-agent scoping; artifact persistence for workflows that must survive a process restart; and provenance trails for regulated environments, where the question is not only what the agent did but whether the record of it can be trusted. --- The Rest of the Toolbox A few things that come along with the integration and tend to surprise people: An S3-compatible API. L3 speaks AWS Signature V4, so tools like the AWS CLI, boto3, rclone, and AWS SDKs work unchanged. Every object response includes its CID in the x-amz-meta-cid header, so you get content addressing without changing client code. If your Base app already has S3 integration, this is a config change, not a migration. IPNS for mutable references. A stable name over changing content, so onchain references do not break when the content updates. Migration with CID preservation. Move existing IPFS data to Walrus without changing CIDs. Your contracts keep pointing at the same identifiers. Account delegation. One account authorizes another to act on its behalf, which is how you build team and service-account patterns, including giving an agent scoped authority over a parent account. A free tier to start on. 5 GB on the Filecoin path, no card required. Enough to build the thing before deciding what it costs. For scale context: 31K+ developers and teams, 9.3M+ file objects, and 15.6TB stored. The Lighthouse explorer is public, so those are verified figures. --- Get Started Pick the path for what you're building: - x402 pay-per-use upload on IPFS and Filecoin - x402 on the Walrus path - Token gating with custom contracts - Encryption features: share, revoke, condition - Memory for agents, over MCP - Create an API key and start on the free tier Building something on Base that needs storage it can pay for itself? Talk to our team. --- Stay in Touch Learn more at the website, docs, or GitHub. Join the community on Discord, X, Telegram, and LinkedIn.

5 min readarrow_forward
Lighthouse Monthly Update - August 2026
Articlecalendar_todayAug 4, 2026

Lighthouse Monthly Update - August 2026

Lighthouse Monthly Update – August 2026 The month the data layer stopped being backend and became the moat. August is where the storage conversation changed shape. Walrus support landed in the SDK, which means the upgrade path we announced in June is now something you can actually call. Around that, the AI agent thesis got sharper, the supply crunch nobody is pricing in became a founder conversation worth having in public, and the ecosystem carried the Walrus story further than we could have on our own. Here is the month. --- Main Spotlight: Lighthouse SDK v0.4.7, Walrus Support in the SDK !image9bd932887c-Picsart-AiImageEnhancer (1).jpg In June we announced that Lighthouse supports Walrus. This month it shipped into the SDK. Walrus support is now available directly in v0.4.7. Same CIDs. Same workflow. Same developer experience. If you are already building on IPFS through Lighthouse, this is a version bump, not a migration. That is the entire design goal. Decentralized infrastructure usually asks you to rewire your integration before you can benefit from it. This does not. You keep your CID based workflow, your gateways, and your SDK calls, and Walrus handles blob storage and erasure coding underneath. What you get on the other side: high performance retrieval, verifiable data availability, and a storage path suited to workloads where reads and writes are continuous rather than occasional. That last part matters more than it sounds. Agent workloads do not look like human upload patterns. Reference: https://x.com/LighthouseWeb3/status/2077423468812075301 --- By the Numbers !MinimalistdarkUIanalyticsdas202608031649-clean (1).webp The Lighthouse explorer is public, so these are not marketing figures. - 31,650 developers and teams building on Lighthouse - 9,276,889 file objects stored - 15.60 TB of total data stored The shape of the curve is the part worth looking at. Growth was close to flat through 2022 and most of 2023. It inflected in late 2024 and has not slowed since. That timing is not a coincidence. It maps almost exactly to when teams started putting agents into production and discovered that ephemeral storage and session-scoped memory do not survive contact with autonomous systems. Infrastructure adoption curves are slow until the problem they solve becomes urgent. Ours became urgent. --- Ecosystem Growth: The Thesis, Stated Plainly Storage is the new moat We put out a thread this month arguing something that has been sitting under most of our product decisions for two years. The hidden infrastructure layer powering AI agents in 2026 is not the model. It is the data layer underneath. Verifiable memory. Reliable backups. High data availability for autonomous systems. Every one of those is a storage problem wearing a different name. An agent that cannot prove what it read cannot be audited. An agent that loses state cannot be trusted with anything running longer than a session. An agent operating on data nobody can verify produces outputs nobody can defend. As models converge and get cheaper, the differentiation moves down the stack to what the agent remembers and whether that memory holds up under scrutiny. Storage stopped being a cost line. It became the thing the rest of the stack depends on to be true. Reference: https://x.com/LighthouseWeb3/status/2082317249856348668 --- Community Engagements: Voice of the Builders Founder's Cut with Cluster Protocol !image (1).webp Nandit sat down with Chief from Cluster Protocol for Founder's Cut on who actually owns the oil of AI. Everyone talks about models. Fewer people ask where the data lives, who controls access to it, and whether it survives long enough to matter. That third question is the one most teams answer too late. The line that traveled furthest from the conversation was about supply. The hardware they will build in 2030 is already sold out. Big tech is buying GPUs, memory and drives like there is no next cycle, and the storage names have moved a thousand percent plus on the back of it. That is not a market narrative. It is a supply signal, and it changes what a three year data strategy has to look like if you are a startup competing for the same physical capacity as hyperscalers. Reference: https://x.com/ClusterProtocol/status/2074194660822786113 Reference: https://x.com/ClusterProtocol/status/2083199041379475542 How to Survive the Bear, with Growthy !image (2).webp We joined VS1 Finance, Cottonia AI and others for a Growthy session on what builders do when attention disappears. Positioning, founder visibility, community, partnerships, and which strategies still work when the market goes quiet. Every bull market has heroes. Every bear market has survivors. Reference: https://x.com/GrowthyWeb3/status/2083154180487749793 --- Ecosystem Mentions: Spotlight from the Community Walrus Blog !image (3).webp The full technical write up on bringing Walrus to the IPFS ecosystem through Lighthouse is live on the Walrus blog. Reference: https://blog.walrus.xyz/bringing-walrus-to-the-ipfs-ecosystem-through-lighthouse/ Sui Community on the Walrus Upgrade The Sui community carried the Walrus upgrade to their own audience: 2,000+ teams already building on IPFS through Lighthouse can now upgrade to Walrus for high performance retrieval and verifiable data availability, without changing how they build. Same CIDs, same gateways, same SDK. Nothing to migrate, nothing to rewrite. Reference: https://x.com/CommunitySui/status/2072422491000291359 Sui Indonesia The Indonesian Sui community picked it up as well, framing it for builders shipping dApps on Solana and Ethereum who want faster retrieval and on chain availability proofs without touching their existing IPFS workflow. Reference: https://x.com/SuiCommunityID/status/2072052809726570596 --- Builder Focus: Trend Activity <div style="display: flex; justify-content: space-between;" <img src="/uploads/image45459b21a4d.webp" width="49%" / <img src="/uploads/image533c4229275.webp" width="49%" / </div Turby kept the timeline warm this month. World Emoji Day got a nod, because every upload tells a story, and Decoy Font made the rounds, a typeface humans read one way and machines read another. Not every post has to be infrastructure. Some of them are just fun. Reference: https://x.com/LighthouseWeb3/status/2078095298463936750 Reference: https://x.com/LighthouseWeb3/status/2078969951503950145 --- What Comes Next August closes with the direction clearer than it has been in a while. Deeper Walrus integration. Phase one covered the write path and the SDK. The next phases push further into retrieval performance and availability guarantees, with the same rule holding: your CIDs do not change and your code does not move. Encrypted storage for agent workloads. Kavach handles client side encryption with key custody that stays with you. As more usage shifts toward autonomous systems, that becomes the difference between an agent that can access the data it needs and an agent that can access everything. More backends, one interface. We keep adding storage networks behind a single SDK. Developers should not have to pick a storage network the way they pick a religion. Write once, choose the backend that fits the workload. Payments built for machines. x402 is live. Agents that need to pay for storage without a human in the loop have a working path today. --- Wrapping Up August was a compounding month. The Walrus upgrade moved from announcement to SDK. The ecosystem carried it further than our own channels could. The AI conversation started acknowledging that the constraint has moved from models to the data layer underneath them, which is the argument we have been making since before it was convenient. And the supply crunch discussion gave the whole thing a deadline, because capacity being bought years ahead of delivery is not a problem you solve at the last minute. The stack got stronger underneath without asking builders to change a line. Second month in a row. That is how a moat gets built.

5 min readarrow_forward
Lighthouse Monthly Update – June 2026
Articlecalendar_todayJul 2, 2026

Lighthouse Monthly Update – June 2026

The month IPFS and Walrus became the same upload. June came down to one shipment that changes the base layer for every team already building with us. Lighthouse now supports Walrus. Around that, the RWA storage conversation got sharper, CodeXero shipped on Base, the roundtables kept us in the right rooms, and Turby made his World Cup debut. Main Spotlight: Lighthouse Now Supports Walrus !image.png This is the most important thing we announced this month. Walrus, built by Mysten Labs, brings blob storage and erasure coding to the stack. That means faster retrieval and stronger data availability for the data you already store with us. What makes this launch matter is not the addition itself, but how little you have to do to use it. You build on IPFS the way you already do. The same CIDs, gateways, and SDK now access Walrus underneath. No migration. No code changes. The division of labour is clean. Lighthouse continues to handle uploads, CIDs, gateways, and developer tooling, which is the part builders actually touch. Walrus handles blob storage and erasure coding underneath. You get advanced decentralized infrastructure without rewiring your integration for it. This storage layer is built for AI memory, Web3 applications, large datasets, media, backups, and data-intensive workloads. If your product touches any of these, the upgrade is available to you now. Reference: https://x.com/LighthouseWeb3/status/2072003059245543867 Ecosystem Growth: Integrations That Prove the Thesis RWA: Where Are Your Off-Chain Documents Stored? !image.png We ran a thread this month on the one question most RWA teams have not answered. The tokenised asset lives on-chain. The deed, the audit, the legal document behind it usually lives on S3, or nowhere decided yet. The numbers make the case. The RWA market grew 263% year over year, with a $16 trillion projection for 2030. A bug that takes down $31B of asset proofs today takes down $16T of them by 2030. As capital flows in, the attack surface on centralised document storage grows with it. Decentralised storage changes the model. Store a document on IPFS and the file's own fingerprint becomes its address. Change one word and the address changes, so any tampering is mathematically visible and anyone can verify it. For documents that cannot be public, you encrypt client-side before upload and gate decryption on-chain, so only token holders or allowlisted addresses can ever read the file. The token is decentralised. The proof behind it should be too. Reference: https://x.com/LighthouseWeb3/status/2064940617348870401 Community Engagements: Voice of the Builders The month was full of rooms worth being in. Nandit joined the Cluster Protocol roundtable on 5th June to argue the question nobody in AI wants to answer straight: who actually owns the data that trained the model you are using, and who profits from it. !image (1).png Reference: https://x.com/ClusterProtocol/status/2062232031178973506 Shivang, joined Cluster Protocol's sixth roundtable on 19th June on what breaks when AI agents start spending money on their own. Agents with wallets are already buying compute and data and settling transactions with no human in the loop, which is exactly the world our backups thesis is built for. !image (2).png Reference: https://x.com/ClusterProtocol/status/2067318244109951136 We also joined the VS1 Space on 18th June on what will define the next cycle of Web3, and the Growthy session on founder-led marketing and why the projects that win this cycle have founders who can actually communicate. !banner2.png Reference: https://x.com/vs1finance/status/2067330145560731978 Reference: https://x.com/GrowthyWeb3/status/2065374911959281868 Ecosystem Mentions: Spotlight from the Community Sui Community on the Walrus Upgrade The Sui community amplified the Walrus launch to their own audience: 2,000+ teams building on IPFS through Lighthouse can now upgrade to Walrus for high-performance retrieval and verifiable data availability, without changing how they build. Same CIDs, same gateways, same SDK. Nothing to migrate, nothing to rewrite. !play.png Reference: https://x.com/CommunitySui/status/2072422491000291359 Builder Focus: Turby's World Cup FIFA World Cup 2026 fever had the whole world hooked, and Turby caught it too. He is out there playing every storage provider that has ever gone down. 1-0 at the whistle. !image (5).png Reference: https://x.com/LighthouseWeb3/status/2067107299001499931 Wrapping Up June was a base-layer month. Walrus is live, and every IPFS team on Lighthouse can upgrade with no migration and no rewrite. The RWA conversation moved from why decentralise documents to where are yours stored right now. CodeXero showed what builders do when storage stops being a problem to solve. The Sui community carried the upgrade to a wider audience. And the roundtables kept putting us in the rooms where the next cycle is being argued out. The stack got stronger underneath without asking builders to change a line. That is the kind of month that compounds.

5 min readarrow_forward
Lighthouse Monthly Update – May 2026
Articlecalendar_todayJun 2, 2026

Lighthouse Monthly Update – May 2026

The month the industry finally caught up to the threat we've been building against for two years. While 25,000 people debated the future of AI at Consensus in Miami, Lighthouse quietly shipped the infrastructure answer to the question nobody wanted to ask out loud: what happens when your AI agent deletes everything? May wasn't about hype. It was about proof - in numbers, in production deployments, and in the architecture that makes the next nine-second disaster survivable. Main Spotlight: The AI Agent Security Crisis Is Here 88%. 60%. 33%. Those aren't projections. They're this year's numbers. !image2.png - 88% of organizations have already experienced an AI agent security incident in 2026 - 60% cannot terminate a misbehaving agent once it starts - 33% have zero audit trail of what their agents did And yet most teams are still running AI agents against the same backup infrastructure built for human error - systems that assume someone will click a confirmation prompt before anything catastrophic happens. Agents don't click confirm. They execute. April showed us exactly what that looks like. An AI coding agent deleted a startup's entire production database in nine seconds. Not the database alone - the backups too. Same credentials. Same blast radius. Three months of customer data, gone. The agent wasn't compromised. It was trying to help. That incident validated everything Lighthouse AI Backups was built for. Reference: https://x.com/LighthouseWeb3/status/2057737361392349287 Why Legacy Backup Architecture Breaks Against Agents !image1.png The architectural flaw is simple: most teams store backups inside the same infrastructure their agents can reach. Same cloud account. Same API surface. Same blast radius. Centralized backup = one API surface = one deletion endpoint = one nine-second window. Decentralized storage (IPFS) flips this entirely: - Data is split into content-addressed chunks across distributed nodes globally - There is no central "delete all backups" endpoint - No single infrastructure provider holds everything - Content-addressed architecture means a CID is immutable - you can't overwrite history Lighthouse AI Backups is built on this foundation. One SDK call. One cron job. Backups your agents literally cannot reach. "Your agent has production access. Your backups shouldn't assume it doesn't." Reference: https://x.com/LighthouseWeb3/status/2056745361340015102 The Stack !maystack.png Data encrypted before it leaves your infrastructure. Keys never touch storage nodes. Even IPFS nodes cannot read your backups. Your data, your keys - not "your data, their cloud, their keys." Early access available → lighthouse.storage By the Numbers: SDK Dominance !image6.png This month, Nandit shared a number that says more than any feature announcement: 2,500+ weekly SDK installs - more than any other IPFS and Filecoin SDK in the ecosystem, including Synapse, Storacha, and Akave. Not a spike. Not a campaign. Organic and stable, week over week. When developers choose an infrastructure layer, they don't switch easily. This is a compounding moat - and Lighthouse is building it consistently. Reference: https://x.com/nanditmehra/status/2059930134095057393 Ecosystem Growth: Integrations That Prove the Thesis Cardano × Filecoin, Powered by Lighthouse !image3.png The Filecoin–Cardano integration went live this month, built on Lighthouse infrastructure. Smart contracts and dApps on Cardano can now store data that persists beyond typical cloud lifecycles - with end-to-end encryption, perpetual retention, and multi-chain smart contract compatibility via a single unified framework. Charles Hoskinson and the Filecoin team have been collaborating for years. Lighthouse makes that collaboration real in production. Reference: https://x.com/Filecoin/status/2055420296211898409 x402: Storage That Agents Can Use Without Asking Permission !image5.png Filecoin highlighted a pattern that matters enormously for the agent era: AI agents need storage that pays for itself - no credit cards, no human in the loop. x402 on Lighthouse via Filecoin does exactly that. Upload triggers payment. USDC settles on-chain via Base. CID returned on confirmation. The agent never needs to ask permission. The agent never needs a human to top up a billing account. This is what autonomous infrastructure actually looks like. Reference: https://x.com/Filecoin/status/2052502255358648825 CodeXero: AnonWall - Permanent by Default CodeXero launched AnonWall this month - an open, anonymous notebook built entirely in a single AI chat session, deployed live on Base, pinned permanently on Lighthouse. Anyone can write. Nobody knows who wrote it. Nothing can be edited or deleted. Whatever is written today will still be there in 2050. This is the thesis made tangible: when storage is abstracted correctly, builders stop thinking about it and start shipping things that weren't possible before. Reference: https://x.com/CodeXeroxyz/status/2060713527556604208 RelayStream: 4K Hollywood Content, NFT-Gated, Verified on Lighthouse 229 verified chunks. Sub-500ms delivery. NFT auth layer. 4K Hollywood content. RelayStream demonstrated what the decentralized media stack actually looks like when it's built properly - not as a proof of concept, but as a production system. Lighthouse provided the verified storage layer that makes the content provable and permanent. Good engineering doesn't need hype. It ships. Reference: https://x.com/LighthouseWeb3/status/2054448411248918737 Builder Focus: The Teams That Don't Wait !vice.png May reinforced a pattern we keep seeing. The builders who matter aren't the loudest voices at conferences. They're the ones who: - Ship while others debate - Choose infrastructure that won't become a liability in six months - Understand that storage isn't a commodity - permanence, verifiability, and encryption are features that compound Turby was in Miami for Consensus. Not for the panels. Not for the rooftop parties. He went to store everything. Permanently. Decentralized. Encrypted. While 25,000 people debated the future, builders were quietly creating it. Reference: https://x.com/LighthouseWeb3/status/2051995676633145531 The signals we're tracking: - AI agents requiring storage that survives their own mistakes - Teams moving away from same-credential backup architecture - Developers choosing Lighthouse not because of marketing, but because of install counts that don't lie Wrapping Up May was a month of convergence. The threat we predicted two years ago became a headline. The infrastructure we built to answer it is live. The ecosystem is deploying it in production. - AI Backups: architecturally isolated, content-addressed, agent-proof - SDK installs: 2,500+ per week, leading the ecosystem - Cardano integration: permanent storage hits a new chain - x402: autonomous agent payments, no human required - CodeXero and RelayStream: builders showing what permanence enables The narrative isn't shifting toward infrastructure that lasts. It already shifted. Lighthouse was ready.

5 min readarrow_forward
Lighthouse Monthly Update – April 2026
Articlecalendar_todayMay 13, 2026

Lighthouse Monthly Update – April 2026

April was about building for what's already here. While the industry debated which AI model would win, we focused on the infrastructure layer that every model will eventually need: backups that survive the agents themselves. This month marked a shift. Not just in product, but in how we position Lighthouse for the era we're entering. The kind of work that doesn't make headlines until it saves someone's company. Main Spotlight: Lighthouse AI Backups !image1.png The bet we made two years ago just paid off. Two years ago, we predicted the next big outage wouldn't come from a hacker. It would come from an AI agent your team gave production access to. Last month, that prediction became reality. An AI agent deleted an entire startup's production database and its backups in nine seconds. Not a breach. Not a misconfiguration. Just an agent doing what it was told, too well. This is the new threat model. Autonomous systems with write access. Agents optimizing for speed over safety. Teams shipping so fast they skip the safety rails. That's why we built Lighthouse AI Backups. This is the most important thing we've ever shipped. Purpose-built for the exact teams who need it most: AI startups, SaaS companies, and vibe coders shipping at warp speed. What makes it different Backup-as-a-Service designed for the AI agent era: - Incremental backups for SQL and NoSQL databases - Object storage support plus any source you need - Go SDK with snapshot management (create, list, inspect, prune) - Content-addressed architecture with fast chunking and deduplication - Full restore capabilities with integrity verification built in - Optional client-side encryption for sensitive data The core idea is simple: backups your agents can't touch. One SDK call. One cron job. That's it. Because the next nine seconds don't have to end your company. Live now. Early access available for teams that need it. Reference: https://x.com/LighthouseWeb3/status/2049473299063914501 Lighthouse Reimagined: New Website Experience !image2.png April also brought a complete refresh of the Lighthouse website. This wasn't just a design update. It was a reframing of what Lighthouse is and who it's for. What changed: - Cleaner interface with sharper navigation - Stronger messaging around permanence, privacy, and composability - Better onboarding flow for developers exploring Lighthouse for the first time - Clearer product positioning for a world where data is permanent and verifiable The update reflects where the product is today and where it's headed. Built for builders who need infrastructure that lasts, not just storage that expires. Explore the new experience: lighthouse.storage Reference: https://x.com/LighthouseWeb3/status/2044463766180663637 Custom Gateways: Free and Paid Tiers Infrastructure that scales needs clear boundaries. This month, we rolled out an important update to how custom gateways work on Lighthouse. What's new: - Free Plan: You get a custom gateway URL for your projects. Fast retrieval, personal control, no cost. - Paid Plan:Custom gateways plus access to Lighthouse's main gateway at gateway.lighthouse.storage. Higher throughput, better redundancy, priority support. Why this matters: To avoid malicious users exploiting shared resources, the main gateway is now limited to paid plans. This ensures reliability for teams that depend on it while keeping the free tier accessible for developers getting started. If you're building on Lighthouse and need the main gateway, upgrading is the move. Update live now. Check your dashboard for details. Reference: https://x.com/LighthouseWeb3/status/2045141600981188816 Ecosystem Growth: Integrations That Matter April proved something important. The teams building the next wave of infrastructure are choosing Lighthouse. Not because of hype. Because it works. Cardano x Filecoin Integration The Cardano and Filecoin collaboration is now live, powered by Lighthouse. This integration brings permanent, verifiable storage to Cardano's ecosystem, enabling smart contracts and dApps to store data that persists beyond typical cloud lifecycles. Charles Hoskinson and the Filecoin team have been collaborating for years. Lighthouse makes that collaboration tangible. Reference: https://x.com/nanditmehra/status/2049670557348843559 CodeXero: Vibe Coders x Permanent Storage With Lighthouse integrated into CodeXero, developers can now build members-only content platforms, DAO document libraries, NFT unlockables, and archives built to last. All from a single prompt. Decentralized storage is no longer something you have to wire up separately. It's just part of the build. CodeXero proves the thesis: when infrastructure is abstracted correctly, builders stop thinking about it and start shipping. Reference: https://x.com/CodeXeroxyz/status/2046167412509216806 Cluster Protocol: On-Chain Apps Need Permanent Storage Cluster Protocol integrated Lighthouse because it fits how on-chain apps actually work. Files can be encrypted, access can be gated by what you hold on-chain, and you get both fast retrieval and long-term backup in the same flow. This is the pattern we're seeing across the board. Teams building real applications need storage that's programmable, permanent, and verifiable. Lighthouse delivers that. Reference: https://x.com/ClusterProtocol/status/2045187156558348418 Filecoin's Validation Filecoin called out Lighthouse multiple times this month, reinforcing what we've been saying for years: pay once, store permanently. Provider selection, deal aggregation, and renewals handled automatically. For AI datasets, archives, and critical records, that's a fundamentally different cost structure than monthly billing that expires. The narrative is shifting. Infrastructure that lasts is no longer optional. Reference: https://x.com/Filecoin/status/2041827415702282558 Reference: https://x.com/Filecoin/status/2044410160651891086 Builder Focus: The Teams That Ship April reinforced a clear pattern. The next wave isn't being built by the loudest voices. It's being built by teams that ship consistently, think long term, and choose infrastructure that won't become a bottleneck. We're seeing early signals everywhere: AI agents requiring persistent state and verifiable memory Data pipelines needing deterministic, reproducible storage Builders moving away from temporary cloud solutions toward permanent infrastructure Lighthouse is positioning itself clearly: As the storage layer for AI startups and SaaS companies As the default infrastructure for projects that need long-term data permanence As the backbone for verifiable, composable data in Web3 and AI No hype. Just infrastructure that works. Wrapping Up April wasn't about chasing trends. It was about shipping the infrastructure that matters when the trend is already here. AI Backups live for the exact teams that need it most. Website redesigned to tell the story more clearly. Custom gateways structured to scale sustainably. Ecosystem integrations proving the value proposition in production. Because infrastructure isn't about what's next. It's about what's already happening and who's ready for it. Lighthouse is ready.

5 min readarrow_forward
Lighthouse Monthly Update – March 2026
Articlecalendar_todayApr 23, 2026

Lighthouse Monthly Update – March 2026

March wasn’t loud. It was focused. While the space chased hype cycles, Lighthouse doubled down on what actually matters: builders, infrastructure, and reliability. This month was about strengthening the foundation. The kind of work that does not trend but defines who survives long term. Main Spotlight: The Next AI Race Is Memory !image3.png It is no longer about who has the biggest model. It is about who has the strongest memory moat. Models are becoming commoditized. APIs are getting cheaper. Compute is getting abstracted. Every team will have access to similar intelligence. But memory is different. Persistent, verifiable, owned memory is where the real advantage will live. AI agents today can reason, generate, and act. But they forget everything once the session ends. They lack continuity. They lack long-term context. They lack ownership over what they learn. That is the gap Lighthouse is preparing for. March was about building toward that future: - Systems that store context beyond sessions - Infrastructure that enables long-term agent memory - Pipelines that ensure data is verifiable and reproducible - Storage that is not rented, but owned and permanent Because the winners in the next AI cycle will not just generate better outputs. They will remember better than everyone else. Defending the Network: 1M+ Requests per Hour Attack Mitigated !image2.png This month, Lighthouse successfully identified and mitigated a sustained inorganic bot attack targeting our data retrieval gateway, peaking at over 1 million requests per hour. The attack had been running for weeks before being detected. Once identified, it was quickly contained and neutralized without causing major disruption to users. This is what real infrastructure looks like. It is not just about uptime dashboards or performance benchmarks. It is about resilience under pressure, the ability to detect abnormal patterns, and the capacity to defend systems in adversarial environments. As AI systems become more autonomous and data becomes more valuable, infrastructure will be tested more aggressively. Reliability will not be optional. Security is not a feature. It is a requirement. Reference: https://x.com/nanditmehra/status/2029214096030351734 New updated website design. !image4.png This month, Lighthouse rolled out an updated website design. The update focuses on improved clarity, cleaner navigation, and a more refined user experience across the platform. A more structured interface, clearer messaging, and better accessibility for builders exploring Lighthouse for the first time. A step forward in making the product easier to understand and use. Check out here: https://lighthouse.storage/ Supporting Builders at Simplicity Accelerator !image1.png Lighthouse continues to support builders as part of the ecosystem curated by Simplicity Group. This accelerator brings together a strong set of infrastructure and tooling partners including AWS, Notion, Azure, ChainGPT, QuickNode, CoinMarketCap, and others. All provide credits, services, and support to early-stage teams. The goal is simple: give builders everything they need to ship. Lighthouse plays a key role in this stack by providing permanent, verifiable storage. Projects building in this ecosystem are not just launching products. They are creating data that needs to persist, remain accessible, and be trusted over time. This is especially critical for AI-native applications where: Data needs to be reproducible Outputs need to be verifiable Memory needs to persist across time Lighthouse ensures that the data layer for these builders is not a bottleneck but a long-term advantage. Reference: https://x.com/SimplicityWeb3/status/2027008962562855296 Builder Focus March reinforced a simple truth. The next wave of AI and Web3 will not be built by noise. It will be built by teams that ship consistently and think long term. We are already seeing early signals of this shift: - AI agents requiring persistent state and memory - Data pipelines needing deterministic and reproducible storage - Builders moving away from temporary storage toward permanent infrastructure Lighthouse is positioning itself clearly in this landscape: - As the storage layer for accelerators and early-stage ecosystems - As the default infrastructure for AI projects that need long-term memory - As the backbone for verifiable, permanent data No hype. Just foundations. Wrapping Up March was not about headlines. It was about holding the line and preparing for what comes next. - Infrastructure tested under real attack conditions - Builders supported through strong ecosystem partnerships - Foundations strengthened for the AI memory era Because as the narrative shifts from models to memory, the strongest moat will not be intelligence alone. It will be persistence. Lighthouse is building for that future. - Read our latest blog post - Follow @LighthouseWeb3 on X , Telegram & Discord for behind-the-scenes updates

5 min readarrow_forward
Lighthouse Monthly Update – Febuary 2026
Articlecalendar_todayApr 6, 2026

Lighthouse Monthly Update – Febuary 2026

Lighthouse February 2026 Update – AI Memory, Permanent Data, and Infrastructure That Doesn’t Forget February sharpened the thesis. AI is evolving fast. But most agents still forget everything. Temporary storage. Centralized backends. Reset memory. We’re building the opposite. We shipped SDK v0.4.4 with CAR file support. You can now upload .car files representing full content-addressed DAGs.No unpacking. No reprocessing. Built for faster, verifiable ingestion of large AI datasets in IPFS/IPLD-native workflows. Progress tracking included. Annual and lifetime storage supported. 👉 Check the update Then we addressed the bigger issue. !69a74c793c85c2826d94f07a.png AI agents forget. Lighthouse doesn’t. We broke down how most AI systems rely on ephemeral memory layers.If agents are going autonomous, their storage must be encrypted, persistent, and verifiable. That is where Lighthouse fits. 👉 Read the article The OpenClaw conversation reinforced it. Developers want real agent memory. Not just vectors. Not just temporary context. Durable, ownership-driven storage. Agents generate data. Lighthouse ensures it stays. !69a74cdc56edfd2edb77401e.png Programmable Storage in Action Filecoin amplified our x402 pay-per-use uploads. Each request returns a 402 response. Client pays in USDC on Base. Retries with the transaction hash. Receives the CID. Clean. Programmable. Machine-ready. This is what autonomous infrastructure looks like. 👉 See the mention !69a74d8f3bc2c6dde7d600c1.png Turby: A Signal for Permanence Turby mint opened on Base. Not just an NFT. A Genesis Pass to encrypted perpetual storage. IPFS and Filecoin powered. Built for durability. Turby represents what Lighthouse stands for. Storage should not expire. Infrastructure should not reset. Builders should not rebuild every cycle. Speed fades. Durability wins. 👉 See the mint !69a751783c85c2826d94f13f.png 🚀 Wrapping Up: Memory Is the Moat AI without permanent memory is a demo.AI with durable storage becomes infrastructure. February was about strengthening that layer. Faster ingestion. Programmable payments. Persistent agent memory. We are not building for the next hype cycle. We are building the memory layer for autonomous systems. Build agents that remember. Build storage that lasts.

5 min readarrow_forward
Lighthouse Monthly Update – November 2025
Articlecalendar_todayApr 6, 2026

Lighthouse Monthly Update – November 2025

Lighthouse November 2025 Update: Agent Storage, Argentina Energy, Migration Upgrades November moved fast. Buenos Aires was buzzing, AI agents started storing their own data, and thousands of files moved into Lighthouse through our new migration layer. Infra is heating up globally and Turby is right in the middle of it. Lighthouse MCP Server is live AI agents can now store, fetch and manage data natively. Encrypted uploads, CID retrieval, dataset creation and fully programmable workflows. A clean, native storage layer for autonomous agents. 👉 https://x.com/LighthouseWeb3/status/1991433596779848027 !692a0a17b0f27916dc8e61a2.png Google Drive and IPFS Provider Migrations You can migrate up to 10,000 CIDs in a single request. Imports are auto verified and files appear instantly in your dashboard. Drive users get folder-level browsing and full or selective migrations. 👉 https://x.com/LighthouseWeb3/status/1991125760153985198 !692a0b272e82d359707928d4.png Go SDK Launch Developers building in Go can upload permanent files, retrieve via CIDs and track deal status. Streaming from buffers or readers is supported along with pagination and metadata 👉 https://x.com/LighthouseWeb3/status/1985951419254673597 !692a1cd7a2ce4a12a1468804.png ZKForge and Lighthouse for Private AI ZKForge brings zkSTARK identity, FHE and anonymous payments. Combined with Lighthouse encrypted storage, this creates real private AI rather than marketing claims. 👉 https://x.com/LighthouseWeb3/status/1990915201714004189 !692a2087b0f27916dc8e63bf.png Loops Hacker House in Buenos Aires Argentina had strong builder momentum this month. Germina Labs gathered teams who actually ship. Our founder Nandit judged the finals and the ideas came in fast. Sharp thinking and real execution throughout. If your product touches data in 2025, Lighthouse is the place to build. 👉 https://x.com/LighthouseWeb3/status/1993813084046283261 !692a212be65337e02f95230d.png ETHGlobal Online 2025 Congratulations to Alpha Foundry and IntelliTrade for winning the Lighthouse and 1MB bounty. The event had 1,670 hackers, 634 projects and dozens built directly on our storage rails. 👉 https://x.com/LighthouseWeb3/status/1986074287728693337 !692a2639b0f27916dc8e6422.png Aethir and Lighthouse Highlighted Aethir Cloud’s GPU network combined with Lighthouse permanent storage was highlighted globally. Compute outputs gain permanent and verifiable records. 👉 https://x.com/Filecoin/status/1991617548224516489 !692a26b4af87ad9fd89ac0ed.png Buenos Aires with Turby Encrypted. Permanent. Verifiable. Turby kept the energy high while the builder crowd showed up strong in the city. 👉 https://x.com/LighthouseWeb3/status/1986843594347655227 !692a2975af87ad9fd89ac129.png Trend Activity Lighthouse stayed aligned with community trends and conversations throughout the month. 👉 https://x.com/LighthouseWeb3/status/1989400885299220598 !692a2a11af87ad9fd89ac132.png 🚀 Wrapping Up From Argentina’s hacker energy to new SDKs and migration tooling, November was packed with progress. Lighthouse is rapidly becoming the storage backbone for agents, applications and AI workflows that require privacy, reliability and permanence. Turby is already preparing for December with more integrations, more tooling and stronger builder momentum. If you are building anything that touches data, Lighthouse is your storage layer.

5 min readarrow_forward
Lighthouse Monthly Update – October 2025
Articlecalendar_todayOct 31, 2025

Lighthouse Monthly Update – October 2025

Lighthouse October 2025 Update – The Dawn of the Data Economy This October, Lighthouse sparked a new era. From powering the launch of 1MB on Base to expanding verifiable storage with Filecoin PDP, the foundation for a true data economy is here. Builders, dreamers, and developers everywhere are asking the same thing: how do we make data valuable again? Main Spotlight: 1MB Launch – Data Becomes Liquid Lighthouse lit the path. 1MB carries the flame. Our new ecosystem sibling, 1MB.io, officially went live, a platform to launch, reward, and trade Data Coins and Agents, built on Base and powered by Lighthouse’s permanent storage. “Every single day, the world creates 400 million TB of data. AI trains on it. Corporations monetize it. You create it. But you earn nothing.” — @1MBdata Developers have already tokenized data from GitHub, Zomato, Uber, Lyft, and more using 1MB’s smart contracts. The data economy has officially begun. Read the launch post: 1MB on X Follow and Join the Movement - Follow 1MB on X: x.com/1MBdata - Join the 1MB Telegram community: https://t.me/+L9BsZ5H3QHMzMmZl Tech Updates 1. Filecoin PDP + Lighthouse Integration The Filecoin Proof of Data Possession (PDP) is now live and fully integrated with Lighthouse. Developers can build with verifiable hot storage, data that is instantly retrievable and cryptographically provable. Read the full thread: Lighthouse on X !image4.png 2. Permanent Storage × Tokenized Data The Filecoin Foundation spotlighted how Lighthouse powers permanent storage and tokenized data economies, bridging decentralized infrastructure with the future of AI and data liquidity. Watch the DWeb Decoded segment: Filecoin Foundation Ecosystem Moments 1. EternalAI x Lighthouse x Filecoin EternalAI integrated Qwen-Edit-2509, a leading open-source image editor, with Filecoin. Lighthouse preserves every edit and model output permanently, ensuring accessibility and reproducibility across time. Read more: Filecoin on X !image1.png 2. Cluster Protocol x Lighthouse Roundtable Lighthouse’s Protocol Engineer, Parva Jain, joined the Cluster Protocol roundtable to discuss “Vibe Coding in Web3,” exploring developer productivity, data infrastructure, and the future of collaborative AI. Event link: Cluster Protocol Community & Events 1. ETHOnline 2025 After our successful ETHGlobal Delhi run, Lighthouse returned for ETHOnline 2025, driving projects focused on Data Coins and Data Agents built directly on Lighthouse. Announcement thread: Lighthouse on X !image3.png 2. TOKEN2049 Singapore Infra, ideas, and endless conversations made TOKEN2049 buzz with energy. Builders discussed making data valuable again, and Turby made a few surprise cameos along the way. See the recap: Lighthouse on X Deep Dive Threads Every revolution needs a foundation. From Filecoin’s decentralized backbone to Lighthouse’s permanence layer, we are shaping how data lives onchain: encrypted, verifiable, and accessible forever. Read the full thread: Lighthouse on X !image2.png Wrapping Up This month marked the start of something bigger, a true, user-owned data economy. Lighthouse continues to light the way for permanence, provenance, and participation. As Turby says, “Keep your data close, your rewards closer.” Follow 1MB and become part of the movement: X: @1MBdata Telegram: https://t.me/+L9BsZ5H3QHMzMmZl Website: 1MB.io

5 min readarrow_forward
Lighthouse Monthly Update – August 2025
Articlecalendar_todaySep 3, 2025

Lighthouse Monthly Update – August 2025

This August, Lighthouse pushed the boundaries of what truly permanent storage means. We have now crossed 11 TiB stored across projects. From Base ecosystem integrations to privacy-first AI models, we doubled down on encryption, private data handling, and seamless cross-chain storage — and even made a stop in Japan to say こんにちは (Konnichiwa) to the future of decentralized storage! 🔧 Tech Updates 11 TiB Stored and Growing Lighthouse has officially crossed 11 TiB of total storage, powering a growing ecosystem of dApps, AI models, and Web3 infrastructure. One-time payments with permanent storage continue to define our mission. Lighthouse is now BASED !image4.png Projects on Base can now pay for decentralized storage using USDC or USDT directly via smart contracts. We also added encryption, token-gating, IPNS, and cross-chain access, making Base a true privacy-preserving infrastructure hub. [ 👉 Read announcement ](https://x.com/LighthouseWeb3/status/1960567426216608202) AI and Privacy: Hermes 4 Weights Secured !image5.png In collaboration with Eternal AI, Hermes 4, an uncensored 70B open-source reasoning model built on Llama 3.1, now stores its weights on Lighthouse. This enables local AI privacy and peer-to-peer connections. [ 👉 Explore details ](https://x.com/Filecoin/status/1960751918881317255) 🎙️ Community Engagements WebX Japan 2025 – Sushi, Sake, and Storage !image2.png Our co-founder Nandit Mehra represented Lighthouse in Tokyo, sharing our vision of 永久保管 (permanent storage), 暗号化 (encryption), and 分散化 (decentralization). Turby also tried sushi… verdict: “Tastes like permanent freshness!” 🍣 [ 👉 See highlights ](https://x.com/nanditmehra/status/1959863054424047943) AI x DePIN Roundtable !image1.png Hosted by WOW EARN, this roundtable featured NivanaSoul, Sentientio, Timesoul, and Lighthouse among others. The discussion explored how AI and decentralized infrastructure are shaping the future. [ 👉 Listen here ](https://x.com/WOWEARNENG/status/1953679138319216771) Golden Hour Ignited: AI and DeFAI Panel !image3.png Hosted by ChainSight and moderated by @defigirleth, the panel featured Sinthive, Replicats AI, Kinic, SingularityNET, and Lighthouse discussing how privacy-first storage is enabling the next wave of AI innovation. [ 👉 Catch the replay ](https://x.com/ChainSight/status/1952368963234750648) 🌐 Ecosystem Mentions Filecoin x Lighthouse: AI Meets Storage Filecoin highlighted our role in powering Hermes 4, reinforcing Lighthouse as a backbone for AI agents that need secure, verifiable, and long-term storage. Base Ecosystem Builders With encryption and token-gating live, more Base projects are choosing Lighthouse as their permanent layer for metadata, files, and onchain assets. Wrapping Up August focused on building trust through permanence with encrypted storage, Base ecosystem expansion, and AI collaborations — all while sharing our story in Japan with a side of sushi.

5 min readarrow_forward
Lighthouse July 2025 Update – Real Infra, Real Recognition, Real Builders
Articlecalendar_todaySep 3, 2025

Lighthouse July 2025 Update – Real Infra, Real Recognition, Real Builders

This July, Lighthouse sharpened its stack and strengthened its reputation. From Python SDK upgrades and Protocol Labs praise to panels on real infrastructure and a splash of Pudgy culture, we kept showing up for devs, for privacy, and for the long game. 🔧 Tech That Speaks Python: Smarter SDKs for Smarter Builders !unnamed.png Lighthouse Python SDK v0.1.5 is Live Python runs the world — from AI training to DeFi analytics. Now it integrates seamlessly with Lighthouse. This release brings: • Enhanced storage and retrieval functions • getFileInfo() for full metadata • getBalance() and getApiKey() to manage credits and keys via code • IPNS support for permanent, versioned links Whether you’re building dApps or training models, this SDK removes friction and adds flexibility. 👉 Check it on PyPi Protocol Labs Recognizes SDK Upgrade Protocol Labs featured our SDK v0.4.0 in their July roundup. With large file support, batch uploads, and CLI improvements, this upgrade strengthens decentralized storage for real-world apps. 👉 See the mention 🎙️ Infra Recognized: Privacy, Protocols, and a Trendy Timeline !unnamed (1).png Safe Highlights Lighthouse as a Privacy Backbone Safe recognized Lighthouse as a leading player in Web3 privacy and encryption infrastructure. Our threshold encryption and persistent access across IPFS and Filecoin earned spotlight coverage. 👉 See the post Pudgy PFP, But Make It Storage !unnamed (2).png Everyone went Pudgy in July , so did we. Because sometimes serious infra builders need a bit of timeline fun. 👉 See our PFP move 🏟️ Infra in the Arena: Panels, Platforms, and Protocol Talks Bitcoin 2025: Digital Gold or Speculative Dust !unnamed (3).png On July 16, Lighthouse joined a roundtable hosted by ChangeNOW, featuring Dash, TON, Coreum, and others. The discussion tackled Bitcoin’s changing role and the infrastructure that supports its next phase. 👉 Watch the panel Infra Builders at the Table !unnamed (4).png We joined speakers from CoinMarketCap, Enflux, and WOWEARN to kick off August with a reflection on what it means to ship real infrastructure in 2025. 👉 Set a reminder 🚀 Wrapping Up: Infra That’s Quiet Until It Works From protocol praise and a new Python SDK to ecosystem panels and privacy shoutouts, July proved that Lighthouse isn’t just shipping features it’s earning trust. We’re here for real builders, building real infrastructure. That’s the mission.

5 min readarrow_forward
Lighthouse Monthly Update – June 2025 🚀
Articlecalendar_todaySep 3, 2025

Lighthouse Monthly Update – June 2025 🚀

Lighthouse June 2025 Update – Infra Power Plays, IRL Dinners, and Turby Tips This June, Lighthouse wasn’t just shipping code. From major SDK upgrades and AI compute collabs to spicy naan and storage memes, we showed up everywhere. Infra is heating up, and Turby’s just getting started. 🔧 Tech Updates: Scaling Real Infra for Real Builders Lighthouse SDK v0.4.0 is Live !image1.png We dropped our biggest upgrade yet. The new SDK makes decentralized storage smoother for developers and scalable for real-world usage. Think huge batch uploads, parallel sessions, and CLI magic. - Cleaner CLI experience - Fixed encrypted text uploads - Support for giant files - Multi-user batch uploads - Infra upgrades across the stack 👉 Check the full update Compute Meets Storage with Marlin !image7.png We’ve teamed up with Marlin Protocol to go beyond just storage. This integration brings off-chain compute with on-chain guarantees, powered by Filecoin and locked in by Lighthouse. Trustless compute meets permanent data. [👉 Read the announcement ](https://x.com/LighthouseWeb3/status/1935298951697068375) Lighthouse x Itheum – Decentralized Storage, Finally Usable !image2.png Creators, builders, and data dreamers — this one’s for you. We’ve partnered with Itheum to make decentralized storage smooth and accessible. No more complex flows. Just clean uploads, dynamic Data NFTs, and unstoppable access via IPFS and Filecoin, powered by Lighthouse. 👉 See the collab 🎙️ Community Engagements: From Spaces to NYC Plates The 10th Naan Fungible Dinner in NYC !image3.png Yes, we did it again. Delicious naan, deeper convos. Lighthouse co-hosted another edition of the Naan Fungible Dinner during Permissionless NYC. Friends from Vaneck, Blockchain APAC, and Finternet joined us to chat about AI, RWA, and onboarding beyond crypto Twitter. [👉 Catch the vibes ](https://x.com/nanditmehra/status/1940703457952038920) Golden Hour: RWA x Data with ChainSight !image4.png Nandit joined voices from Lumia, Brickken, Clearpool, and others to talk about how decentralized storage powers real-world asset protocols. Storage isn’t just backend — it’s foundation. [👉 Join the convo ](https://x.com/ChainSight/status/1934625637781922278) Web3 Global Talks: Infra Panel !image5.png We joined devs from Syscoin, Reef, SeraphAgent, and others to dive deep into decentralized infrastructure. Storage is the backbone — and we’re setting the standard. [ 👉Replay here ](https://x.com/web3globalmedia/status/1937907883477540904) CTO Ravish on Cluster AMA Our CTO, Ravish, went live with Cluster Protocol to unpack the "forever" promise of Lighthouse. He dropped dev tips, explained storage logic, and gave a glimpse into what’s next. [👉 Replay here ](https://x.com/LighthouseWeb3/status/1940776285867069450) AI x Blockchain with Accumulate We jumped into a high-signal roundtable hosted by Accumulate Protocol on June 12. The topic? Real use cases of AI on blockchain — from transparency to automation and beyond. [👉 Listen in ](https://x.com/i/spaces/1ynJOlOokjlxR) 🌐 Ecosystem Mentions: Spotlight & Shell Wisdom !image6.png Turby Tips Are Live Turby’s back, and he’s dropping knowledge. Our encrypted turtle is now handing out quick tips on decentralized storage, file encryption, and upload tricks across socials. Follow along if you’re building or just vibing. [👉 Follow Turby on X ](https://x.com/LighthouseWeb3) 🚀 Wrapping Up: We Build Infra That Lasts June was full of momentum. We leveled up the SDK, teamed up with compute protocols, partnered with Itheum to make storage usable, got love from Filecoin, joined top-tier conversations on RWA and AI, and made IRL noise in NYC. Whether it’s dev tooling or ecosystem energy, Lighthouse continues to show up for builders.

5 min readarrow_forward
Getting Started with Threshold Cryptography
Articlecalendar_todayAug 29, 2025

Getting Started with Threshold Cryptography

Imagine having a vault that requires three out of five keys to open, but here's the twist – no single keyholder can access the contents alone, and even if two keyholders collude, they still can't break in. This is essentially how threshold cryptography works, except instead of physical keys, we're dealing with digital secrets that protect everything from cryptocurrency wallets to enterprise data. In today's interconnected world, single points of failure are security's greatest enemy. When one person holds the master key, one compromised device can spell disaster for an entire organization. Threshold cryptography solves this fundamental problem by distributing trust across multiple parties, ensuring that security actually increases when it's shared rather than concentrated. Whether you're a developer building secure applications or a business leader concerned about data protection, understanding threshold cryptography is becoming essential. Let's explore how this powerful technique is reshaping digital security. The Evolution of Threshold Cryptography While some credit Alfredo De Santis, Yvo Desmedt, Yair Frankel and Moti Yung with the first complete threshold system in 1994, others point to Adi Shamir's foundational work "How to Share a Secret" published by MIT in 1979. Regardless of attribution debates, the core innovation was clear: mathematical techniques could eliminate single points of failure in cryptographic systems. Early adopters were limited to military and governmental organizations until 2012, when RSA Security released software making threshold cryptography available to the public. This democratization coincided with growing concerns about password breaches and the need for more robust security models. The explosion of blockchain technology and decentralized finance (DeFi) has created unprecedented demand for threshold cryptography applications. Threshold cryptosystems align with the original philosophical motivation behind cryptocurrencies - removing trusted intermediaries, centralized entities, and actors who are "too-big-to-fail". Today's applications extend far beyond cryptocurrency, encompassing everything from multi-party computation to privacy-preserving protocols and distributed key management systems. What is Threshold Cryptography? Threshold cryptography is a security method that splits sensitive information, like encryption keys or digital secrets, across multiple participants. The magic happens in the numbers: you can set it up so that any t out of n participants can access the secret, but t-1 or fewer cannot. This is called a "t-of-n threshold scheme." The beauty of threshold cryptography lies in its flexibility. You might choose: - 2-of-3 for a small team where any two members can authorize actions - 5-of-9 for a larger organization requiring majority consensus - 7-of-10 for maximum security where strong consensus is needed Unlike traditional security where you either have the key or you don't, threshold schemes create a middle ground where partial access is meaningless, but sufficient cooperation unlocks full functionality. !nano-banana-no-bg-2025-08-29T07-12-17.jpg How Threshold Cryptography Works The process might sound complex, but the concept is surprisingly intuitive when broken down into simple steps. Step 1: Secret Splitting Think of your digital secret (like a private key) as a treasure map. Instead of keeping the complete map in one place, threshold cryptography tears it into pieces and distributes these pieces to different trusted parties. However, unlike a simple puzzle, these aren't just random pieces; they're mathematically related in a special way. Step 2: Smart Distribution Each participant receives their unique "share" of the secret. Here's what makes it secure: looking at any individual share reveals absolutely nothing about the original secret. It's like having a piece of a jigsaw puzzle without knowing what the complete picture looks like or even how many pieces exist. Step 3: Threshold Magic When it's time to use the secret, the required number of participants combine their shares. Through mathematical processes that happen behind the scenes, these shares reconstruct the original secret perfectly. The key insight is that you need exactly the threshold number; any fewer shares and reconstruction is impossible, but with enough shares, you get the complete secret back. Step 4: Collaborative Operations The reconstructed secret can then be used for its intended purpose—signing transactions, decrypting data, or authorizing actions—without any single participant ever holding the complete secret on their own. Benefits of Threshold Cryptography Threshold cryptography addresses several critical security challenges that plague traditional approaches: Eliminating Single Points of Failure Traditional security often depends on one person, one device, or one location. If that single point is compromised, everything falls apart. Threshold schemes distribute this risk, so even if some participants are compromised or unavailable, the system continues functioning. Democratic Decision Making Threshold cryptography naturally enforces consensus. For important operations to proceed, multiple parties must agree and participate in the process. This prevents rogue actors from making unauthorized decisions while ensuring legitimate operations can proceed smoothly. Enhanced Privacy Participants can work together without revealing their individual secrets to each other. Each person knows only their own piece, creating a collaborative system that maintains privacy even among trusted partners. Business Continuity If team members leave, devices break, or locations become inaccessible, threshold systems remain operational as long as enough participants are available. This resilience is crucial for business operations that cannot afford downtime. Real-World Applications Threshold cryptography isn't just theoretical – it's solving real problems across various industries: Cryptocurrency and Digital Assets Multi-signature wallets are evolving to use threshold signatures, which provide better privacy and lower transaction costs. Instead of revealing that multiple parties are involved (as traditional multi-sig does), threshold signatures look like regular transactions while providing superior security. Enterprise Security Companies use threshold schemes for securing critical systems where multiple executives must approve major changes. This prevents insider threats while ensuring business operations don't depend on any single individual. Decentralized Applications Threshold cryptography enables truly decentralized applications where no central authority can unilaterally control user funds or data. This aligns with the core principles of Web3 and blockchain technology. Secure Communications Organizations handling sensitive communications use threshold encryption to ensure that intercepting any single communication channel doesn't compromise the entire conversation. Securing Files on Public Networks with Threshold Cryptography IPFS is a public network, meaning files uploaded to the IPFS network can be viewed by anyone around the world. To secure files over this public network, users need to encrypt their data before uploading. This is where threshold cryptography becomes essential for maintaining privacy while leveraging the benefits of decentralized storage. Lighthouse's Threshold Encryption Solution Lighthouse addresses this challenge through Kavach, an advanced Encryption SDK that uses threshold cryptography to secure files on IPFS. Instead of relying on traditional encryption, where a single key compromise means total data exposure, Kavach distributes encryption keys across multiple secure nodes. Key Features: - Randomized key shard generation across distributed nodes - TypeScript support for seamless developer integration - Key reconstruction only when authorized access is needed - 5-node encryption storage for maximum redundancy When you upload encrypted data through Lighthouse, Kavach automatically handles the threshold cryptography implementation behind the scenes. Your files remain completely private on the public IPFS network, but you never have to worry about losing access due to a single point of failure. Ready to implement secure, encrypted uploads? Check out Lighthouse's comprehensive guide on how to upload encrypted data programmatically using the SDK with built-in threshold cryptography. Conclusion Threshold cryptography transforms security from a weakness into a strength by distributing trust across multiple parties. Instead of hoping that one central point never fails, threshold schemes assume that some participants will be compromised or unavailable and plan accordingly. For developers and organizations building secure applications, threshold cryptography offers a proven path to eliminate single points of failure while maintaining operational flexibility. Platforms like Lighthouse's Kavach are making this powerful technology accessible, enabling the next generation of secure, decentralized applications. The future of digital security isn't about building higher walls around single points of failure – it's about distributing trust intelligently so that security increases rather than decreases when it's shared. Threshold cryptography provides the mathematical foundation for this future, ensuring that collaborative security is not just possible, but practical.

5 min readarrow_forward
Permanent Storage Powered by Lighthouse
Articlecalendar_todayAug 29, 2025

Permanent Storage Powered by Lighthouse

Every month, you pay for cloud storage. Every year, the bill gets higher. After a decade, you've spent thousands of dollars and still don't own anything – stop paying, and your files disappear. This subscription-based model has trapped millions of users in endless payment cycles while making tech giants billions. What if there was a better way? What if you could pay once and store your files forever? Permanent storage is revolutionizing how we think about file storage, moving from expensive rental models to true ownership. With Lighthouse's innovative approach to perpetual storage, you can finally break free from recurring fees and achieve true data ownership on the decentralized web. The Problem with Traditional Storage Traditional cloud storage operates on a rental model that becomes increasingly expensive over time. Here's the hidden reality: Endless Subscription Costs: A modest 100GB storage plan at $ 5 per month costs $600 over 10 years and $1,200 over 20 years. For businesses storing terabytes of data, these costs become astronomical. Data Hostage Situation: Your files are held hostage by monthly payments. Miss a payment or decide to cancel? Your data vanishes. There's no grace period for years of memories or critical business documents. Price Inflation: Storage providers regularly increase prices. What starts as affordable quickly becomes a significant expense as your storage needs grow and prices rise. No True Ownership: Despite paying for years, you never actually own your storage. You're perpetually renting space that can be taken away at any moment. Platform Risk: When services shut down or change terms, users scramble to migrate terabytes of data, often losing files in the process. Permanent Storage is the Solution Permanent storage flips the traditional model on its head. Instead of renting storage space indefinitely, you make a one-time payment and own that storage allocation forever. It's like buying a house instead of renting – an investment that pays dividends over time. Key Benefits of Permanent Storage: True Ownership: Once you pay, that storage space belongs to you: no monthly fees, no renewal reminders, no risk of losing access due to payment issues. Predictable Costs: One upfront payment eliminates budget uncertainty. You know exactly what you'll spend on storage for the lifetime of your files. Long-term Savings: The math is compelling. Traditional storage costing $50/month equals $6,000 over 10 years. Permanent storage might cost $500 once, a 92% savings. Data Security: Your files remain accessible regardless of payment status. This is crucial for NFT collections, business archives, or any data requiring long-term preservation. No Vendor Lock-in: Permanent storage protocols are typically decentralized, reducing dependency on any single company's survival or policy changes. How Lighthouse Enables Permanent Storage Lighthouse has pioneered permanent storage through an innovative endowment pool mechanism that makes perpetual file storage economically sustainable and technically sound. When you upload files to Lighthouse, your payment is split strategically: Immediate Storage Payment: A portion goes directly to Filecoin storage providers who store your files with cryptographic proofs and economic incentives to maintain them. Endowment Pool Contribution: The remaining amount feeds into a shared endowment pool – a smart contract-managed fund designed to pay for storage maintenance in perpetuity. The endowment pool grows through multiple mechanisms. Every Lighthouse user contributes to the same pool, creating a large, diversified fund that benefits from economies of scale. Moreover, the pool employs DeFi strategies like staking and yield farming to generate returns that exceed storage costs over time. As more users join and the pool grows, the per-user cost of perpetual storage decreases while reliability increases. Lighthouse's permanent storage protocol operates across multiple blockchain networks, including Base, Polygon, and Filecoin, ensuring broad compatibility and reduced transaction costs. The system integrates Filecoin's storage provider network with IPFS's content addressing, giving you the best of both worlds: fast access through IPFS and long-term persistence through Filecoin's economically incentivized storage deals. All operations are transparent and verifiable on-chain. You can track your storage deals, monitor the endowment pool's health, and verify that your files are being properly maintained – something impossible with traditional cloud storage. Ready to Explore Lighthouse Permanent Storage? The future of file storage is here, and it's permanent. Instead of paying monthly fees forever, make the switch to true ownership with Lighthouse's permanent storage solution. 🔍 View the Endowment Pool: Check the real-time health and transparency of Lighthouse's endowment pool mechanism at Lighthouse Explorer 💾 Start Storing Files: Upload your first files with an intuitive interface at Lighthouse Dashboard 👨‍💻 Integrate with Code: Build permanent storage into your applications using our comprehensive Developer Documentation Stop renting your storage. Start owning it. With permanent storage, you pay once and store forever – finally putting you in control of your digital assets for life.

5 min readarrow_forward
What is IPFS Pinning & A Complete Guide with Lighthouse
Articlecalendar_todayAug 29, 2025

What is IPFS Pinning & A Complete Guide with Lighthouse

Storing files online shouldn't mean sacrificing control, paying endless subscription fees, or worrying about whether your content will disappear tomorrow. Yet that's exactly what happens with traditional cloud storage services. As Web3 continues to reshape how we think about data ownership and digital infrastructure, IPFS pinning has emerged as a game-changing solution for developers, creators, and businesses who want truly decentralized, reliable file storage. Whether you're building NFT collections, developing decentralized applications, or simply looking for a more sustainable way to store and share files, understanding IPFS pinning is crucial. But here's the thing – not all IPFS pinning services are created equal. While basic pinning keeps your files available, advanced solutions like Lighthouse Storage offer perpetual storage, encryption, and 4K streaming capabilities that transform how you think about decentralized storage. What is IPFS? Think of IPFS (InterPlanetary File System) as a completely different approach to storing and accessing files on the internet. Instead of relying on a single server in one location – like traditional cloud storage does – IPFS creates a distributed network where your files live across multiple computers worldwide. Here's the key difference: when you save a file to Google Drive or Dropbox, you're asking, "Where is my file stored?" But with IPFS, you're asking, "What is my file?" This shift from location-based to content-based addressing changes everything. Imagine if, instead of remembering someone's street address, you could find them anywhere in the world just by knowing their unique fingerprint. That's essentially how IPFS works – each file gets a unique identifier called a Content Identifier (CID) based on its actual content, not where it's stored. This distributed file storage approach offers several advantages: - No single point of failure – if one node goes down, your files remain accessible from other nodes - Faster access – files are served from the closest available node to your location - Version control – any change to a file creates a new CID, preserving file history - Censorship resistance – no central authority can remove or block your content What is IPFS Pinning? Now here's where it gets interesting. Just uploading a file to the IPFS network doesn't guarantee it'll stay there forever. IPFS nodes regularly clean up their storage through a process called "garbage collection" – essentially deleting files that haven't been requested recently to free up space. IPFS pinning is the solution to this problem. When you "pin" a file, you're telling an IPFS node: "Keep this file available no matter what." It's like putting a permanent bookmark on your content that prevents it from being garbage collected. There are two main types of pinning: Local Pinning: You run your own IPFS node and pin files to your own hardware. This gives you complete control but requires technical expertise, reliable internet, and significant resources to maintain 24/7 uptime. Remote Pinning (IPFS Pinning Services): Professional services run high-performance IPFS nodes and handle the pinning for you. This is like having a team of experts manage your decentralized storage infrastructure while you focus on building your project. Most developers and businesses choose professional IPFS pinning services because they offer: - Guaranteed uptime and redundancy across multiple locations - Easy-to-use interfaces similar to traditional cloud storage - API access for seamless integration into applications - Technical support and service level agreements - Cost predictability without the overhead of managing infrastructure Lighthouse: Advanced IPFS Pinning Solution While traditional IPFS pinning services only keep files available, Lighthouse Storage combines IPFS with Filecoin and advanced features to create a comprehensive decentralized storage platform. Instead of basic pinning, you get verifiable guarantees, encryption options, and performance optimizations suitable for enterprise applications. Key Lighthouse Features - - Perpetual Storage & Verifiable Persistence - Advanced Encryption & Privacy - Dedicated gateway - Migration support - 4K Video Streaming & Media Optimization - Multichain Integration. How to Pin Files to IPFS using Lighthouse What sets Lighthouse apart from traditional IPFS pinning services is the seamless integration of multiple storage layers. When you upload files to IPFS using the Lighthouse SDK or Files dApp, something powerful happens behind the scenes: your files are automatically pinned to IPFS while simultaneously being stored on the Filecoin network. This dual-layer approach means your files achieve the trifecta of modern decentralized storage – they're accessible through IPFS for fast retrieval, verifiable through Filecoin's proof system, and persistent through long-term storage deals. The following guide walks you through uploading data via the Lighthouse dashboard. For programmatic uploads, refer to the developers' documentation, which provides comprehensive SDK and CLI guides. Uploading Data through the Lighthouse dashboard - Navigate to files.lighthouse.storage and log in to your account. !Screenshot 2025-08-27 at 12.31.00 PM.png - After successful login, the dashboard shows the previously uploaded files along with datacap used. - To upload new content, click the Upload Now button and select Upload File or Upload Folder accordingly. !Screenshot 2025-08-27 at 11.18.28 AM.png - Select the file or folder you would like to upload. On selection, the data is pinned to IPFS immediately. - Once the data is uploaded, you can view the properties in the dashboard, which includes CID, filecoin deals, and access link through ipfs gateway. !Screenshot 2025-08-27 at 11.30.56 AM.png - For using the encryption feature, just toggle the Encryption to on before upload. !Screenshot 2025-08-27 at 11.44.07 AM.png Scaling Your Storage with Lighthouse Plans Lighthouse's free tier provides 5GB of annual storage for 14 days, giving you ample opportunity to test the platform and experience the benefits of perpetual IPFS storage firsthand. The free tier is perfect for experimenting with decentralized storage, uploading your first NFT collection, or building proof-of-concept applications. You get access to all core features, including IPFS pinning, Filecoin storage, and the intuitive dashboard interface. When you're ready to scale up, the Get More Storage button provides access to expanded plans that offer additional annual storage, lifetime storage, and advanced features like token gating, dedicated gateway, etc. Lighthouse accepts multichain crypto payments as well as credit cards. !Screenshot 2025-08-27 at 11.53.31 AM.png Whether you're an individual creator, a development team, or an enterprise looking to leverage decentralized infrastructure, Lighthouse's flexible plans ensure you can find the right balance of features, performance, and cost for your specific needs.

5 min readarrow_forward
Lighthouse Monthly Update – May 2025
Articlecalendar_todayJun 5, 2025

Lighthouse Monthly Update – May 2025

Lighthouse May 2025 Update – AI Memory, Cross-Chain Launches, and Turby the Mascot Explore Lighthouse's May 2025 advancements: partnerships with Codatta, Filecoin integration across Base and Cardano, AI memory innovations, and the debut of our new Web3 mascot, Turby. 🔧 Tech Updates: Scaling AI and Storage Innovation !image7.png 1. Partnership with Codatta We've partnered with Codatta to enhance decentralized knowledge storage. This collaboration ensures high-quality datasets benefit from permanent, censorship-resistant storage, bolstering access and reliability across AI applications. Read here !image4.png 2. Encryptum’s Decentralized AI Memory Proposal Encryptum has proposed a groundbreaking AI memory system utilizing Lighthouse for long-term Filecoin storage and Arweave for immutable logs. Powered by MCP compute on RunOnFlux, this integration aims to empower AI with secure, decentralized memory. Read here !image3.png 3. Blockfrost x Filecoin on Cardano Through Lighthouse, Blockfrost has activated Filecoin storage for Cardano. This integration offers end-to-end encryption, perpetual data retention, and multi-chain smart contract compatibility, all within a unified decentralized framework. Read here !image6.png 4. Lighthouse Now Live on Base We're thrilled to announce that Lighthouse is now live on Base! Users can store data on IPFS/Filecoin using USDC or USDT, enjoy cross-chain compatibility via Axelar, and leverage built-in encryption and token gating features. Read here !image2.png 5. NuklaiData’s Global AI Training Layer NuklaiData is developing a shared metadata and dataset layer for AI training. Utilizing Lighthouse and Filecoin, this initiative supports cross-domain knowledge systems and advances ethical AI model development. Read here 6. SingularityNET Completes Filecoin Phase One SingularityNET has completed Phase 1 of Filecoin integration using Lighthouse, establishing a robust decentralized cloud stack. This milestone advances the creation of Web3-native compute and storage solutions for AI systems. Read here 🎙️ Community Engagements: Voice of the Builders !image1.png DePIN & AI AMA with Sending Network On May 27, Lighthouse joined AgentDefi, TheVapeLabs, and Sending Network in an engaging AMA session. The discussion focused on DePIN, AI infrastructure, and decentralized tooling. Catch the replay here. Read here 🎙️ 🌐 Ecosystem Mentions: Spotlight & Mascot Magic !image5.png Meet Turby – Your New Favorite Web3 Mascot! Introducing Turby, the encrypted turtle champion of Web3 storage. Fast, friendly, and ahead of the current, Turby brings Lighthouse to life with fun, function, and flair. Follow Turby’s adventures on our socials and let the waves begin! 🚀 Wrapping Up: Lighthouse Builds the Future May was a month of significant progress: from AI-native storage proposals and cross-chain launches to major ecosystem integrations and the introduction of Turby. We're not just building technology—we're laying the foundation for an open, intelligent, and unstoppable decentralized future. Let’s continue pushing boundaries—together. 👉 Read our latest blog post 👉 Follow Turby on X , Telegram & Discord for behind-the-scenes updates

5 min readarrow_forward
Lighthouse Monthly Update – April 2025
Articlecalendar_todayMay 12, 2025

Lighthouse Monthly Update – April 2025

Hey Lighthouse Fam 👋 April was nothing short of a breakthrough month for us! From protocol-level innovations to deep ecosystem integrations, we made solid strides in positioning Lighthouse as the go-to layer for decentralized storage. Let’s dive into what we’ve been up to: !681bf2bd2f984f4cead3a44e.jpeg 💸 Stable Payments with USDFC We rolled out USDFC support—a FIL-backed stablecoin native to the Filecoin chain—to make storage payments predictable and smooth. Perfect for projects managing tight or recurring budgets. Read Here 📈 A New Way to Emit Tokens Say hello to our Performance-Based Token Emission Model! Token distribution is now tied to real metrics—like data stored, active users, treasury growth, and governance activity—ensuring the network grows in lockstep with real usage. Read Here !681bf4de5f070e9745859203.png 🌍 Meet the Ecosystem We launched a brand new ecosystem page highlighting projects building with Lighthouse—spanning NFTs, AI, decentralized web, and more. Got something cool? Drop us a line! Read Here ♾️ Perpetual Storage Is Here We introduced a yield-backed perpetual storage model—pay once, store forever. With interest-generating endowments covering long-term costs, this sets the foundation for $HOUSE integration. Read Here !681bf80148232c60367262ba.jpeg Webhash.eth’s 8,000+ dWebs Lighthouse helped deploy thousands of decentralized websites—talk about scale! Read Here SingularityNET x Lighthouse Storing AI metadata for verifiable pipelines and model provenance. Read Here DeepSeek AI Integration Now powering onchain AI workflows with decentralized storage of weights, datasets, and outputs. Read Here Scratchable Monads on Monad An NFT project with scratch-to-reveal logic, backed by Lighthouse’s data permanence. Read Here !681bf9450fc32effd55355d3.png 📈 A New Way to Emit Tokens Say hello to our Performance-Based Token Emission Model! Token distribution is now tied to real metrics—like data stored, active users, treasury growth, and governance activity—ensuring the network grows in lockstep with real usage. Read Here !681bfb040fc32effd55355e7.jpeg 🏙️ Token2049 Dubai Our team was on the ground engaging with AI Agents,Desci, RWA and DePin builders, exploring modular infra, and strengthening collaborations 🎤 CoinferenceX: Storytelling Infra Founder Nandit gave a powerful talk on narrative-driven protocol growth: “Narrative is King: How Stories, Not Data, Move Markets” Read Here 🍛 Naan Fungible Dinner | 8th Edition – Dubai We co-hosted the 8th Naan Fungible Dinner on May 2nd alongside StationX, Raga, and Lucidly—a sold-out evening of ideas, laughter, and Naan with the global Web3 fam. This format is fast becoming our favorite way to connect. April was a whirlwind—stablecoin support, sustainable emissions, infra for RWAs and AI… it’s all happening. We’re laying serious groundwork for what’s next in Q2. Let’s keep building together. 🔦

5 min readarrow_forward
Lighthouse Monthly Update – February 2025
Articlecalendar_todayMay 6, 2025

Lighthouse Monthly Update – February 2025

Hey Hey, I know we are a little late for the monthly recap but we were busy vibing at ETH Denver, hope you had fun as well. But now we are back, all charged up! So let’s get started. February was a month of breakthroughs for decentralized storage! From healthcare to travel, here’s what went down at Lighthouse this month !image1.png Powering Privacy in Healthcare Partnered with @Hippocratio to secure patient-owned medical data on Filecoin. Ensuring patient privacy, security & control over medical records. Read it here Lighthouse Whitepaper is LIVE! Unveiling the future of $HOUSE—the token fueling storage, access control & incentives. Read it here !67cf67371776a292427479db.jpeg Travel Meets Decentralized Storage Partnered with @Traveltorsocial to store travel memories securely on IPFS. Users can store experiences permanently on IPFS with proof-of-attendance & location-based features. [Read it here ](https://x.com/LighthouseWeb3/status/1892966461829763457) Lighthouse Explorer Launched! A real-time dashboard to track storage & token distributions. View $FIL, $USDC & staked assets, analyze pool performance & access key metrics. Read it here !67cf68cb1776a29242747a26.jpeg Advancing Filecoin with @CIDgravity Teamed up with CIDgravity to enhance the Filecoin ecosystem. Merging SP management tools with client-facing interfaces for seamless data solutions. [Read it here ](https://x.com/Filecoin/status/1897032554009502017) ETH Denver: Whitepaper Insights 📜 Spoke at Code 'n Corgi on the Lighthouse Whitepaper Summary. Key insights from the talk: $HOUSE utility, storage economics & the future roadmap. [Read it here ](https://x.com/LighthouseWeb3/status/1896572042910253244) AI x Web3 Hackathon Incoming! Building the future of AI & decentralized data with @Filecoin. Join to build, innovate & shape the next wave of AI & Web3. Read it here February set the stage! We’re building bigger, better, and bolder in 2025. Which update caught your attention the most?

5 min readarrow_forward
Lighthouse Monthly Update – January 2025
Articlecalendar_todayFeb 4, 2025

Lighthouse Monthly Update – January 2025

Welcome to the first edition of Lighthouse’s Monthly Update for 2025! The year has started off strong, and we’ve been making strides in decentralized storage, partnerships, and AI integrations. Here’s a recap of everything we’ve accomplished this month. !image3.png Launching Datahouse: Our Podcast on Decentralized Storage We’re thrilled to introduce Datahouse, our brand-new podcast series dedicated to all things data storage! From emerging trends to deep dives into decentralized infrastructure, this podcast will be your go-to source for insights from industry leaders. Catch the first episode here: [https://x.com/LighthouseWeb3/status/1876276370659234208 ](https://x.com/LighthouseWeb3/status/1876276370659234208) Expanding Reach: Lighthouse Now Supports Abstract Chain Bringing decentralized storage to more ecosystems is at the heart of what we do. This month, we integrated with AbstractChain, making it easier than ever for developers to store and retrieve data on-chain without worrying about centralization. Check out the details here: [https://x.com/LighthouseWeb3/status/1877332825353105671 ](https://x.com/LighthouseWeb3/status/1877332825353105671) !image5.png Powering AI with Secure Storage – CryptoEternalAI Integration As AI continues to scale, so does the need for large, secure, and permanent data storage. This is where Lighthouse steps in! We’re ensuring 1Courier Inc, an AI-driven project by CryptoEternalAI, has the infrastructure it needs to store and access data seamlessly. Learn more about how AI & decentralized storage intersect: [https://x.com/Filecoin/status/1877825266380095951 ](https://x.com/Filecoin/status/1877825266380095951) Enhancing User Experience with Radixdit Partnership A good wallet experience is critical for any Web3 user, and our new collaboration with radixdit ensures just that! Together, we’re working toward an optimized and secure wallet experience for managing decentralized storage. Check out what this means for you: [https://x.com/LighthouseWeb3/status/1879506979246559674 ](https://x.com/LighthouseWeb3/status/1879506979246559674) !image4.png Strengthening AI Storage with Skynet AI applications require reliable and efficient storage solutions, and our partnership with SkynetforAI brings us one step closer to seamless AI storage solutions. This integration ensures that AI agents can store, access, and retrieve data with zero friction. [https://x.com/SkynetforAI/status/1882120797277360562 ](https://x.com/SkynetforAI/status/1882120797277360562) !image1.png Securing Healthcare Data with Hippocratio Healthcare data is sensitive and needs to be stored securely. Our integration with Hippocratio ensures that medical records and patient data are stored in an encrypted and decentralized manner on Filecoin, enhancing privacy and security for healthcare applications. Learn more about our healthcare storage solutions: [https://x.com/LighthouseWeb3/status/1884801071744168243 ](https://x.com/LighthouseWeb3/status/1884801071744168243) What’s Next? January was just the beginning of what’s set to be a game-changing year for decentralized storage and AI. As we continue to build, integrate, and innovate, we’d love to hear from you! Which update excites you the most? What would you like to see next?

5 min readarrow_forward
The Role of Blockchain in AI & Data Storage: A Decentralized Future for Technology
Articlecalendar_todayJan 31, 2025

The Role of Blockchain in AI & Data Storage: A Decentralized Future for Technology

Artificial Intelligence (AI) has emerged as one of the most transformative technologies of our era. From healthcare to finance, AI is reshaping industries and redefining how we interact with technology. However, its potential is heavily constrained by centralized data systems controlled by tech giants like Google, OpenAI, and Amazon. These monopolies dictate who can train AI models, how data is used, and what insights are generated. This centralized approach creates significant challenges, including restricted access, lack of transparency, and vulnerability to censorship and bias. To unlock AI’s full potential, we need a paradigm shift: decentralized, tamper-proof, and verifiable data sources powered by blockchain technology. This blog explores how the convergence of blockchain, data, and AI is reshaping the future of technology, ensuring transparency, accessibility, and ethical AI development. AI is Only as Good as the Data It’s Trained On The quality of AI models depends entirely on the data they’re trained on. Unfortunately, centralized data silos create three major problems: Restricted Access: High-quality data is often locked behind paywalls and permissioned APIs, limiting innovation to those who can afford it. This creates a barrier for smaller organizations, researchers, and independent developers who lack the resources to access premium datasets. As a result, innovation becomes concentrated in the hands of a few corporations, stifling competition and creativity. Lack of Transparency: Users have no insight into how data is sourced, manipulated, or pre-processed, leading to potential biases and misinformation. For example, if an AI model is trained on biased data, it can perpetuate and even amplify those biases in its outputs. This lack of transparency undermines trust in AI systems and raises ethical concerns. Vulnerability to Censorship: Centralized data storage is prone to censorship, manipulation, and security breaches, raising ethical and reliability concerns. Governments or corporations can alter or restrict access to data, influencing AI models to serve specific agendas. This centralization of power undermines the democratization of AI and its potential to benefit society as a whole. For AI to be truly open, unbiased, and beneficial to all, it must rely on decentralized data ecosystems. Blockchain technology offers the perfect solution by enabling secure, transparent, and tamper-proof data storage. The Rise of Decentralized Storage for AI Blockchain-based storage solutions like IPFS (InterPlanetary File System), Filecoin, and Lighthouse are revolutionizing how AI interacts with data. These platforms ensure open access to verifiable datasets, eliminating the risks associated with centralized control. Here’s how decentralized storage is transforming AI: Transparency: AI models trained on blockchain-secured data are more resistant to bias and misinformation. Every piece of data stored on a blockchain is timestamped and immutable, meaning it cannot be altered or tampered with. This ensures that AI models are trained on accurate and reliable data, fostering trust in their outputs. Censorship Resistance: No single entity can impose restrictions, ensuring unbiased decision-making and democratized AI development. Decentralized storage distributes data across a network of nodes, making it nearly impossible for any one party to control or manipulate the data. Data Ownership: Users regain control over their data, deciding whether to share, monetize, or keep it private. Blockchain technology enables individuals and organizations to retain ownership of their data while still contributing to AI development. This shift empowers users and creates a fairer ecosystem where data is treated as a valuable asset. This shift creates a fairer ecosystem where AI development benefits individuals, not just corporations. AI Agents + Decentralized Storage = The Next Leap The future of AI isn’t just about accessing decentralized data; it’s about AI agents autonomously interacting with this data in a trustless environment. Projects like Fetch.ai, SingularityNET, and Ocean Protocol are pioneering this next wave by enabling AI agents to securely store, retrieve, and share decentralized data. These AI agents operate without intermediaries, making unbiased decisions based on verifiable, tamper-proof data. This eliminates reliance on black-box AI models controlled by corporations and fosters a system where AI serves people transparently. For example: Nuklai Data is enhancing AI efficiency through contextualized data storage, enabling AI models to understand and process data in a more meaningful way. Ocean Protocol is enabling private and permissioned data sharing for privacy-first AI operations, ensuring that sensitive data remains secure while still contributing to AI development. Autonome provides tools for developers to deploy AI agents and monetize them in decentralized marketplaces, creating new opportunities for innovation and collaboration. This marks a new era where AI models are not only smarter but also fairer, more autonomous, and accountable. Who Owns AI: Big Tech vs. The People Currently, AI development is dominated by a handful of powerful corporations that control data access, model training, and deployment. This centralized approach stifles creativity, limits accessibility, and prioritizes corporate interests over the public good. However, decentralized AI and blockchain-based storage offer a compelling alternative: Open-Source AI Models: Provide full transparency, allowing anyone to audit how they function. Open-source AI models enable collaboration and innovation, as developers can build on existing models and contribute to their improvement. Autonomous AI Agents: Operate independently, free from corporate control. These agents can perform tasks, make decisions, and interact with other agents without the need for intermediaries, creating a more efficient and equitable ecosystem. Privacy-Preserving AI: Ensures users retain control over their data. Blockchain technology enables secure and private data sharing, allowing individuals and organizations to contribute to AI development without compromising their privacy. Projects like Eliza OS, AIXBT, and Luna Virtuals are leading this movement, demonstrating how AI can be democratized when built on trustless, verifiable, and permissionless data. The Road Ahead: A Decentralized AI Revolution The convergence of AI, blockchain, and decentralized storage isn’t just a theoretical concept; it’s already shaping the future of technology. We’re entering an era where AI models are not only smarter but also more ethical, transparent, and accessible. This shift is critical for ensuring AI serves humanity rather than corporate interests. The decentralized AI revolution will bring: More Transparency: AI models trained on open and verifiable data, eliminating black-box decision-making. This transparency fosters trust and accountability, ensuring that AI systems are used responsibly. Greater Accessibility: AI tools and datasets available to researchers, developers, and individuals without barriers. Decentralized storage and open-source models level the playing field, enabling anyone to contribute to and benefit from AI advancements. Ethical AI Development: AI systems designed to prioritize user control, privacy, and unbiased decision-making. By decentralizing data and AI development, we can create systems that align with societal values and ethical principles. Leading the charge are projects like Lighthouse, Filecoin, SingularityNET, Ocean Protocol, and Fetch.ai. Their innovations are laying the foundation for a world where AI works for people, not against them. Are You Ready for the Decentralized AI Revolution? The time to embrace a decentralized AI future is now. By leveraging blockchain technology, we can create AI systems that are transparent, accessible, and ethical. The decentralized AI revolution represents a fundamental shift in how we approach technology, placing power back into the hands of individuals and communities. The question is: Are we ready to build an AI revolution that truly serves humanity? The tools and technologies are already here. It’s up to us to embrace them and create a future where AI is a force for good, empowering individuals and driving innovation for the benefit of all. Conclusion The intersection of blockchain, AI, and decentralized data storage is more than just a technological advancement; it’s a movement toward a fairer, more transparent, and equitable future. By breaking free from centralized control, we can unlock the full potential of AI and ensure that it serves the needs of humanity, not just the interests of a few corporations. As we move forward, it’s essential to support and invest in decentralized AI projects that prioritize transparency, accessibility, and ethical development. The decentralized AI revolution is not just a possibility, it’s a necessity. The future of technology depends on it. Are you ready to be a part of it?

5 min readarrow_forward
November at Lighthouse: Milestones & Innovations
Articlecalendar_todayDec 4, 2024

November at Lighthouse: Milestones & Innovations

Hey fam, ready for a wild ride? November was all about big moves, stronger partnerships, and unforgettable moments in Bangkok. Missed any of it? Here’s your exclusive recap 👇 !image1.png Powering Decentralized AI with SingularityNET 💪 SingularityNET is pushing decentralized AI (deAI) & AGI with transparency and ethics at the forefront. Lighthouse completed Phase 1 integration, providing decentralized, permanent storage for key data like metadata and .proto files. Our Python SDK, CLI, and Daemon? Fully operational, making this AI future-proof and inclusive! ![Group 1.png](https://x.com/nanditmehra/status/1854508156447318423) Nandit’s DevCon & FIL Dev Summit Highlights ✨ Our founder @nanditmehra stole the show in Bangkok, hopping between podcasts, panel discussions, and networking sessions. From bridging Web3 with Web2 to sharing insights on AWS/GCP’s influence on developers - he kept the innovation vibes high. !Group 3.png FILDev Summit Sponsorship 🤝 We didn’t just attend; we showed up strong! FILDev Summit was buzzing with innovation, and we were at the heart of it. From Protocol Labs to BoostyLabs and Fleek, the ecosystem was alive with groundbreaking discussions, and we’re thrilled to have been part of it! We’re just getting started, and there’s so much more to come! Stay connected and watch this space for bigger, better updates. Catch all the action on Twitter @LighthouseWeb3.

5 min readarrow_forward
October at Lighthouse: Milestones & Innovations
Articlecalendar_todayNov 8, 2024

October at Lighthouse: Milestones & Innovations

GM BUIDLers, what’s cooking? It’s that time of the month again & we are back with another monthly roundup at Lighthouse. October was a pretty epic for us. From new partnerships to exciting milestones, we’re all about turning big ideas into impactful results. Missed out? No worries - we’ve got your recap right here. 👇 Partnering with Powerhouses for Filecoin Growth !2024-11-08 19.21.06.jpg We’ve teamed up with the Filecoin Foundation and Aethir Cloud to amplify the Filecoin network! This partnership brings advanced GPU leasing, giving developers more power and flexibility. Plus, they’ll be storing critical AI and node data through Lighthouse, making Filecoin even more robust and accessible to the Web3 community. 6,000+ ENS Websites Now on Lighthouse Yes, you read that right - 6,000 ENS websites have been deployed on Lighthouse! Thanks to the efforts of WebHash, we’re seeing major growth in decentralized domain adoption. Each ENS deployment takes us one step closer to an internet where ownership and freedom come standard. Making NFTs Truly Permanent !image3.png We’re thrilled to announce our partnership with NFT.Storage, which makes NFT preservation a breeze. By locking in long-term security and efficiency, creators can rest easy knowing their digital assets are here to stay, with no compromise on accessibility. NFTs are forever? Now, they really can be! Eternal AI’s Llama Model on Decentralized Storage !image5.png AI + Web3 just hit new heights. Eternal AI integrated our SDK to store their Llama 3.1 405B model data on Lighthouse, proving that AI doesn’t have to be confined to centralized silos. It’s decentralized, secure, and infinitely scalable. We’re proud to be powering the future of decentralized AI! Secure and Rewarding Interactions with Incentives !image4.jpg We partnered with Incentives to give you control over your social and AI interactions. Think of it as privacy, reimagined—one where your data is secure, interactions are private, and you’re rewarded for every engagement. This is privacy as it should be: all yours. Co-Sponsoring the FILDev Summit with the Best in Web3 !image2.jpg We’re beyond excited to co-sponsor the FILDev Summit alongside Protocol Labs, Boosty Labs, Fleek, Glif, and more! This event is all about empowering developers to build, innovate, and make decentralized tech a reality. We’re thrilled to support the Filecoin community as they bring Web3 to life. October was packed with milestones, but we’re just getting started. November promises even more excitement. Thanks for being part of the Lighthouse journey. Stay tuned for more updates and exciting developments at Lighthouse, or get in touch with us

5 min readarrow_forward
September at Lighthouse: Milestones & Innovations
Articlecalendar_todayNov 8, 2024

September at Lighthouse: Milestones & Innovations

GM BUIDLers, what’s cooking? September has been one of the most transformative months for us yet. From groundbreaking integrations to powerful partnerships, we’ve made big strides in our mission to reshape decentralized storage. Let’s dive into everything we achieved this month. Partnership With Coreum !image6.jpg We were thrilled to announce our partnership with Coreum, the smart blockchain for real-world applications. Now, you can store files on Lighthouse via Coreum with CLI/SDK support, enhanced encryption, token-gated access, direct payments, and seamless login through the Cosmos wallet. Over 900 Projects Integrated With Lighthouse Over 900 projects have now integrated with Lighthouse. This remarkable growth shows how our platform is being adopted across various ecosystems. Check out the announcement here. IRL Travel Bookings via Buk Protocol !image2.jpg On the Real-World Assets (RWA) front, IRL travel bookings are now possible with the Buk Protocol using Lighthouse. Secure Data Storage for StackOS Compute Platform Additionally, we’re offering a secure data storage solution to the StackOS compute platform, further solidifying our role in the DePIN ecosystem. On-Demand GPU Compute for Gaming and AI !image4.jpg We also partnered with Aethir Cloud to provide powerful, on-demand GPU compute for gaming and AI, paired with Lighthouse's decentralized storage. This collaboration promises to elevate the user experience in the gaming and AI sectors. Find out more here. Token2049 Presence !image3.jpg Our presence at Token2049 was fantastic. We had the chance to showcase our progress and connect with the broader blockchain community. See the highlights from the event here. Keynote Session at FIL Singapore Our co-founder, Nandit Mehra, took the stage with a keynote session at FIL Singapore, where he shared valuable insights and Lighthouse's vision. If you missed it, you can catch the recap here. Partnership With Destra Network !image1.jpg In another exciting development, we’ve partnered with Destra Network to enhance the security and privacy of their storage network while boosting the AI-driven capabilities of the Destra OCAI platform with Filecoin. First-Ever zkTLS x Data Layer Demo We reached a new milestone by showcasing our first-ever zkTLS x data layer demo, marking a significant step forward in our journey. Take a look at the demo here. It’s been an incredible month, and we’re excited about what’s coming next. Stay tuned for more updates and exciting developments at Lighthouse, or get in touch with us

5 min readarrow_forward
August at Lighthouse: Milestones & Innovations
Articlecalendar_todayNov 8, 2024

August at Lighthouse: Milestones & Innovations

GM BUIDLers! August has been a whirlwind of exciting developments at Lighthouse! From groundbreaking collaborations to reaching new milestones, we’ve been busy pushing the boundaries of what’s possible in decentralized storage. Whether it's enhancing our services or supporting innovative projects, we've made significant strides this month. Let's dive into some of the highlights from last month. Keynote Insights from Our Founder !naditPreview.png A special shoutout to our founder, Nandit Mehra, for sharing incredible insights on Filecoin about how decentralized storage will shape the future of the data economy. Missed it? Watch the episode here. Stop rendering websites and HTML content One of the significant moves we made this month was to stop rendering websites and HTML content from our Lighthouse Public Gateway. This strategic shift allows us to hone in on our core strengths, ensuring that we deliver the most secure and reliable decentralized storage solutions. It’s all about focusing on what we do best to serve you better. UngateAI's Autonomous Virtual System (AVS) !image3.jpg We also saw some incredible progress with UngateAI. In just three weeks, they built and deployed an Autonomous Virtual System (AVS) using Lighthouse, pushing the boundaries of decentralized intelligence. This project showcases the full potential of our platform and how it can be used to power innovative solutions across various industries 160k Participants in Galxe Quest A huge milestone was achieved this month—over 160k participants joined our Galxe Quest! This surge in participation is a testament to the growing interest and engagement within our community. It’s been amazing to see so many of you take part, and we’re beyond grateful for the support. Together, we’re building something truly special. Collaborating with Sirio Finance !image4.jpg Another exciting collaboration came from Sirio Finance, who is bringing an AI-driven risk management model to life. By leveraging decentralized storage on FVM via Lighthouse, they’re not only enhancing security but also paving the way for innovation in Lending & Borrowing protocols. Their model can be customized to meet the specific needs of other protocols as well, making it a versatile tool in the DeFi space. Lighthouse SDK: Part of Dynamic Hackathon Starter Kit We’re also proud to announce that the LighthouseWeb3 SDK is now part of the Dynamic Hackathon Starter Kit. This inclusion is a huge win for us as it means more developers will have access to our tools, empowering them to build innovative projects in the decentralized space. We can’t wait to see what amazing ideas come to life using our SDK. NFT Creation Workshop at Inha University !image5.jpg LongfeiW, Developer Advocate at Filecoin, recently led a workshop at Inha University in Korea, focusing on NFT creation on FVM with Lighthouse. This workshop was a great opportunity to showcase our technology to the next generation of builders and creators, and the response was overwhelmingly positive. We’re always excited to see our tech in action and being used to educate and inspire. Supporting Forma Chain: The Future of On-Chain Creations !image2.jpg Last but certainly not least, Lighthouse now supports Forma chain, a cutting-edge network designed for on-chain creations. This partnership marks a significant step forward in the future of digital creation, and we’re thrilled to be a part of it. With Forma chain, creators have more flexibility and power to bring their visions to life on-chain, and we’re excited to see where this leads. With all these exciting developments, we’re more motivated than ever to keep pushing forward. Looking forward to what September has in store for us! Stay tuned for more updates and exciting developments at Lighthouse, or get in touch with us

5 min readarrow_forward
AI Meets Blockchain: Beyond the Hype & Into the Future
Articlecalendar_todaySep 24, 2024

AI Meets Blockchain: Beyond the Hype & Into the Future

The buzz around AI and blockchain is louder than ever, with industries scrambling to understand how these technologies can transform their operations. But as with any hype train, it's crucial to differentiate between genuine innovation and flashy gimmicks. So, what exactly happens when these two tech giants collide? Let's break down the intersection between AI and blockchain, uncover the myths, and explore the genuine potential of this dynamic duo. Blockchain Creates Trust & AI Needs Trust The idea that blockchain could combat misinformation generated by AI sounds compelling. Imagine a world where every piece of digital content is authenticated and verified using an immutable ledger. This would seemingly create a utopia where misinformation is kept at bay, and digital truth is preserved. But before we get carried away, let’s dive deeper into how feasible this actually is. [https://x.com/Polkadot/status/1782514882249703756 ](https://x.com/Polkadot/status/1782514882249703756) Blockchain’s Role in Timestamping Blockchain's main strength lies in its ability to create a permanent, tamper-proof record of transactions. For example, if I upload a photo of a flying saucer above the Washington Monument and register this image on the Ethereum blockchain, the blockchain will timestamp this event. This means we can see that the photo was registered before a specific block number, in this case, block 20,000,000. Advantages of Timestamping - Immutable Record: The blockchain provides an immutable record of when and by whom the content was created. This is useful for verifying the timeline of digital content. - Proof of Existence: By storing a hash of the image on the blockchain, you can prove that the image existed at a certain point in time. This helps in proving ownership and original creation. The Limitation of Authenticity Verification While blockchain is excellent at providing a timestamp and proof of existence, it falls short when it comes to verifying the content's authenticity. Here’s why: 1. Content Verification: - What the Blockchain Can’t Tell: Blockchain can't verify whether a photo is genuine or manipulated. The ledger can tell us when I registered the image, but it can't determine if the photo was created by a camera, edited with Photoshop, or generated by AI. - No Insight into the Creation Process: The blockchain does not offer any insight into how the image was created or whether it has been altered. It only confirms that I registered it, but not the nature of its authenticity. While blockchain can confirm when and by whom a digital asset was created, it does not solve the problem of content authenticity. The immutable nature of blockchain is a powerful tool for timestamps and proof of existence but falls short in verifying the truthfulness of the content itself. Is Blockchain The Guardian of Privacy for AI? The narrative that blockchain can provide privacy for AI, especially in model training, is another area ripe for scrutiny. The concept is that blockchain’s decentralized and transparent nature could somehow secure sensitive data involved in training AI models. But is this a feasible solution or just a misunderstanding of blockchain’s capabilities? [https://x.com/hosseeb/status/1773146428594090473 ](https://x.com/hosseeb/status/1773146428594090473) Blockchain’s Transparency vs. Privacy Needs Blockchain’s core feature is its transparency. Every transaction on the blockchain is visible to all participants in the network, which is great for ensuring data integrity but problematic for privacy. Transparency vs. Confidentiality: - Public Ledger: In a public blockchain, every transaction is recorded on a ledger that is accessible to anyone. This transparency is fundamental to how blockchains operate, but it doesn’t align with the need for privacy in model training. - Privacy Concerns: When training AI models, especially with sensitive data (e.g., medical records), maintaining confidentiality is crucial. Blockchain’s transparency can conflict with the need to keep this data private. Privacy-Enhancing Technologies: While blockchain itself is not suited for privacy, several advanced cryptographic techniques can address these needs. However, these technologies are not inherently part of blockchain systems: 1. Zero-Knowledge Proofs (ZKPs): - How ZKPs Work: Zero-Knowledge Proofs allow one party to prove to another that they know a value without revealing the value itself. This is useful for confirming transactions without disclosing details but doesn’t solve privacy issues for model training directly. - Limitations for AI: ZKPs can’t obscure the data used to train AI models. They can prove that a transaction or computation was performed correctly, but they don’t keep the data used for training confidential. - Organizations Involved: Companies like Zcash, and Peanut Protocol are actively working on ZKP technologies. !image11.gif 2. Fully Homomorphic Encryption (FHE): - What FHE Does: Fully Homomorphic Encryption allows computations to be performed on encrypted data without needing to decrypt it first. This means AI models can be trained on encrypted data without ever exposing the raw data. - Challenges with FHE: While promising, FHE is computationally intensive and has not yet been widely adopted due to performance constraints and complexity. - Organizations Involved: Chalink & Zama are working on bringing FHE onchain. !image10.jpg 3. Secure Multi-Party Computation (MPC): - What MPC Achieves: Secure Multi-Party Computation enables multiple parties to jointly compute a function over their inputs while keeping those inputs private. This can be used for privacy-preserving AI, allowing model training without exposing individual data points. - Adoption and Complexity: Like FHE, MPC is complex and not yet widely implemented in practical systems. - Organizations Involved: Companies such as Lighthouse and startups like Partisia are advancing MPC technologies for privacy-preserving computations. !image4.png AI Bots with Blockchain Wallets: How Does That Work? Jeremy Allaire, CEO of Circle, has suggested that AI and blockchain are a perfect pairing, particularly for bots using cryptocurrency. On the surface, this sounds like a win-win. After all, cryptocurrencies and AI both thrive in digital spaces. However, there’s a darker side to this union. Imagine AI bots wielding crypto to make autonomous transactions. This could mean bots making decisions about financial transactions with real-world consequences. My own research in 2015 explored how smart contracts on Ethereum could facilitate crime if combined with AI. Imagine a rogue AI creating smart contracts that pay bounties for illicit activities. While this scenario isn’t a reality yet, it’s a future risk that needs serious consideration. Blockchain enthusiasts and AI developers must prioritize safety measures to prevent such scenarios. Real Use Cases and Emerging Technologies While many of the common narratives about AI and blockchain may be myths, there’s still real innovation happening at their intersection. Let's explore some of the most promising and realistic use cases, along with the companies pushing the boundaries in these sectors. 1. Transparent Data Sources for AI AI models rely heavily on vast, high-quality datasets to improve their accuracy and efficiency. Blockchain can play a significant role by providing a transparent, verifiable, and tamper-proof source of data. This ensures that the data used for training AI models is authentic and has not been manipulated or tampered with—especially critical in sensitive industries like healthcare and finance. !image6.png - Use Case in Healthcare: Blockchain-based platforms can ensure the integrity of medical records or genomic data used for AI-driven healthcare solutions. - Companies Leading This: - Ocean Protocol provides a decentralized data marketplace where AI developers can access high-quality, verified datasets. - MediBloc is using blockchain to secure medical data and ensure its integrity for healthcare AI applications. 2. Autonomous AI Systems Blockchain’s decentralized architecture supports the development of autonomous AI systems by eliminating the need for a centralized server or intermediary. This enhances both the efficiency and reliability of AI systems as they interact across networks without reliance on a single point of failure. Autonomous systems that can make decisions and execute tasks in real time such as in logistics, supply chains, or smart cities, benefit greatly from the decentralized, trustless nature of blockchain. !image3.png - Use Case in Smart Cities: AI-powered traffic systems running on decentralized blockchain networks can automatically respond to real-time conditions, optimizing flow and reducing congestion. - Companies Leading This: - Fetch.ai is creating autonomous AI-powered systems using blockchain to manage complex tasks in various industries, from transportation to smart energy grids. - IOTA focuses on decentralized, feeless transactions and is being used in autonomous systems for smart city initiatives. 3. Privacy Protection for AI Models As noted, blockchain itself doesn’t inherently provide data privacy. However, when combined with cryptographic technologies such as Fully Homomorphic Encryption (FHE) and Secure Multi-Party Computation (MPC), blockchain can offer robust privacy-preserving solutions. This allows AI to securely process sensitive data without exposing it to unauthorized parties. For example, medical institutions can use AI models to analyze encrypted patient data without directly accessing the raw data, safeguarding privacy. !image1.png - Use Case in Finance and Healthcare: Privacy-preserving AI models can analyze financial data without exposing it to intermediaries, ensuring that sensitive information remains private. - Companies Leading This: - Lighthouse focuses on privacy-preserving encrypted storage using MPC, allowing AI systems to work on encrypted data without revealing the underlying information. - Oasis Labs combines blockchain with privacy-enhancing technologies like FHE to enable secure AI model training on encrypted data. 4. Distributed Computing Power for AI Training AI models requires vast computational resources, often making it a costly and time-consuming process. Blockchain can help distribute this workload across a decentralized network, allowing participants to contribute idle computing power in exchange for tokens. This approach makes AI model training more scalable and cost-effective, particularly for smaller organizations. !image12.png - Use Case in AI Research: AI researchers can access distributed computing power to train large-scale models without needing to rely on centralized cloud providers. - Companies Leading This: - Golem allows users to rent out their unused computing power for AI training and other heavy computational tasks. - SingularityNET connects AI developers with a decentralized marketplace of computing resources for model training and inference. 5. Enhanced Security for Smart Contracts AI can be integrated into blockchain systems to enhance the security of smart contracts. AI-driven security audits can identify vulnerabilities and automatically suggest or implement fixes, reducing the risk of exploits or attacks on blockchain networks. This adds an extra layer of protection for decentralized applications (dApps) and DeFi platforms, where security is paramount. !image9.png - Use Case in DeFi: AI tools can monitor and analyze blockchain transactions in real time to detect and prevent fraudulent activities or attacks on smart contracts. - Companies Leading This - OpenZeppelin integrates AI tools into its smart contract auditing services to identify potential vulnerabilities. - QuillAudits uses AI-driven algorithms to audit smart contracts for DeFi platforms and ensure their security. 6. Efficient Data Querying for Blockchains AI can be employed to optimize the way blockchain systems store and query data. As blockchains grow in size, efficient querying becomes increasingly challenging. AI-enhanced protocols like TTA-CB (Trusted Timestamping Authority - Consensus Blockchain) can improve data access speeds, making blockchain applications more responsive and scalable. !image8.png - Use Case in Data-Intensive Applications: AI-enhanced data querying can improve the performance of blockchain systems used in logistics, supply chains, and digital asset management. - Companies Leading This: - Algorand is developing efficient and scalable solutions for data storage and querying, leveraging AI-driven optimizations. - Graph Protocol enables efficient querying of blockchain data and utilizes AI to optimize these queries for better performance. 7. Authenticity and Audit Trails for AI Models Blockchain can provide an immutable record of how AI models were trained and on what datasets. This allows organizations to ensure the authenticity and traceability of AI models, which is particularly important in regulated industries like healthcare, finance, and government. Audit trails on blockchain allow regulators to verify compliance and ensure that AI models are developed using ethical, transparent practices. !image7.png - Use Case in Compliance: Organizations using AI for decision-making can maintain a transparent, immutable audit trail of how AI models were trained and deployed. - Companies Leading This: - Veracity provides blockchain-based tools for auditing and verifying AI model integrity. - Modex offers blockchain solutions for ensuring AI models’ compliance with industry standards and regulations. 8. Automation of Business Processes The integration of AI with blockchain can automate complex business processes, from dispute resolution to optimizing supply chains. Smart contracts can automatically execute predefined actions based on AI-analyzed data, improving the efficiency and reducing the friction in many industries, including finance, logistics, and manufacturing. !image5.png - Use Case in Finance: AI-powered smart contracts can automatically execute transactions based on predefined criteria, such as when certain stock prices reach a particular threshold. - Companies Leading This: - Chainlink combines AI with blockchain to enable automated data-driven smart contracts. - R3 Corda offers solutions for automating financial services processes using blockchain and AI integrations. Final Thoughts As we explore the intersection of AI and blockchain, it’s clear that while the hype can be overwhelming, there’s genuine potential for transformative impact. The key is to focus on practical applications that leverage the strengths of both technologies. We must move beyond buzzwords and work towards solutions that address real-world challenges. Emerging technologies like Optimistic Machine Learning (ML) and Zero-Knowledge Machine Learning (zkML) are promising, and while they’re not yet mainstream, they offer exciting possibilities. The crucial takeaway is to separate meaningful innovation from mere hype and to approach the integration of AI and blockchain with a critical perspective. While we end the blog here, here is a tip for the degens out there. Don't just invest your money into companies who are trying to ride the AI wave without actually having a proper use case. DYOR. Always.

5 min readarrow_forward
What is FHE and how Lighthouse plans to use it
Articlecalendar_todayAug 21, 2024

What is FHE and how Lighthouse plans to use it

Imagine a world where you can analyze sensitive data without ever decrypting it. Sounds like science fiction, right? But it's not—it's the magic of Homomorphic Encryption. This groundbreaking technology allows computations on encrypted data, preserving privacy while extracting valuable insights. Let’s dive deep into how this works and how Lighthouse Storage is venturing into this fascinating domain with Fully Homomorphic Encryption (FHE). The Encryption Conundrum: Why Traditional Methods Aren’t Enough Encryption is the bedrock of data security, ensuring that your sensitive information stays hidden from prying eyes. But here’s the catch: traditional encryption only protects data when it’s at rest (stored) or in transit (being sent somewhere). As soon as you need to process or analyze that data, you have to decrypt it, exposing it to potential risks. Imagine handing over the keys to your treasure chest just because you need someone to count the gold inside. It’s a vulnerability that businesses, especially those handling sensitive information, have had to live with—until now. These traditional encryption methods, while robust, fall short when applied to the unique challenges of blockchain and AI. Let's break down why: 1. Vulnerability During Data Processing: Traditional encryption methods protect data at rest (when stored) and in transit (when being transferred). However, as soon as you need to process or analyze the data—whether it's running computations on it or training AI models—you have to decrypt it. This decryption process exposes the data to potential breaches. In a blockchain environment, where transparency and immutability are key, this exposure is especially problematic. The moment the data is decrypted, it's vulnerable to attacks from within the network, undermining the very security blockchain aims to provide. 2. Incompatibility with Decentralized Systems: Blockchains are decentralized, meaning data is stored and processed across multiple nodes. Traditional encryption methods, designed for centralized systems, struggle to adapt to this environment. When data is decrypted for processing on a blockchain, it becomes visible to all nodes, increasing the risk of unauthorized access. This is particularly concerning when dealing with sensitive datasets, such as financial information or personal data, where privacy is paramount. 3. Challenges in Secure AI Model Training: Training AI models requires vast amounts of data, often involving personal or proprietary information. Traditional encryption methods necessitate decrypting this data during training, leaving it exposed. On blockchain, this exposure is even more dangerous due to the distributed nature of the network. If any node in the network is compromised, the entire dataset could be at risk. This makes it difficult to ensure the privacy and security of the data used in AI training. 4. Lack of Scalability: Traditional encryption methods were not designed with the scale of blockchain in mind. As the amount of data stored and processed on the blockchain increases, so does the risk. Decrypting and re-encrypting large volumes of data can be time-consuming and resource-intensive, slowing down the entire system. This lack of scalability is a significant hurdle for blockchain applications that require the secure handling of large datasets, such as AI training. Homomorphic Encryption Keeps Secrets While Doing the Math. But How? Imagine needing to perform complex calculations on your most sensitive data—think customer financial records, medical histories, or proprietary algorithms—without ever having to unlock it from its secure vault. That's the promise of Homomorphic Encryption (HE). Homomorphic Encryption allows you to perform computations directly on encrypted data, yielding results that are identical to what you'd get if the data were decrypted. It's as if you hired a vault master who could count your gold, weigh it, and even divide it into piles, all without ever opening the chest. The gold stays safe inside, untouched and unseen, but you still get the precise outcome you need. !image3.png Source How is it different? While traditional encryption methods lock up your data and throw away the key until you need to use it, Homomorphic Encryption keeps the key safely hidden, even during processing. But not all Homomorphic Encryption is created equal. There are mainly 3 forms of HE, each with its own capabilities: - Partial Homomorphic Encryption (PHE): Allows only a specific type of operation (like addition or multiplication) on encrypted data, but not both. - Somewhat Homomorphic Encryption (SHE): Supports a limited number of operations before it needs to be decrypted. These methods, while useful in certain contexts, are still limited. They can't handle the full complexity of operations required by modern applications like machine learning, where data often needs to undergo numerous and varied computations. But Fully Homomorphic Encryption (FHE) allows for any type of computation on encrypted data, no matter how complex. Whether you're running machine learning algorithms, conducting data analytics, or even facilitating secure electronic voting, FHE can process it all without ever exposing the underlying data. What Makes FHE so EPIC? - End-to-End Security in AI: AI model training often requires vast amounts of sensitive data. With FHE, you can train these models directly on encrypted datasets. The data never needs to be decrypted, ensuring that personal information, trade secrets, or proprietary algorithms are never exposed, even during intensive computational processes. - Complex Computations, Zero Exposure: FHE enables you to perform intricate operations, like training AI models or running advanced analytics, without decrypting the data. This is especially critical in blockchain applications, where data is distributed across multiple nodes and must remain secure at all times. - Enabling Trustless Computation: One of the core principles of blockchain is the concept of trustless transactions—where participants don’t need to trust one another because the system itself guarantees security. FHE takes this a step further by enabling trustless computation. Even in decentralized environments where nodes may not fully trust each other, FHE ensures that data can be processed without being exposed, preserving the integrity and confidentiality of the information. - Future-Proofing Against Quantum Threats: As quantum computing advances, the security of traditional encryption methods is increasingly at risk. FHE, with its advanced cryptographic techniques, offers a layer of protection that is more resistant to these emerging threats. By allowing computations on encrypted data, FHE reduces the risk of exposure, even in a quantum world. - Privacy-Preserving Data Sharing: FHE makes it possible to share encrypted data with third parties for processing without ever revealing the underlying information. This is particularly valuable in industries like finance, where institutions need to collaborate on data without compromising privacy. Are There Any Real-World Applications of FHE? Well, there is a whole FHE ecosystem out there. Fully Homomorphic Encryption (FHE) is quickly becoming a cornerstone of privacy-focused innovations, and a vibrant ecosystem is emerging around this technology. !image2.jpg Take a closer look at some of the key players and what they’re bringing to the table: - Zama: With their TFHE and fhEVM, Zama is making FHE work seamlessly with Ethereum, enabling private on-chain computations and smart contracts. - Fhenix: Known for their FHE Layer 2 solutions, Fhenix is developing specialized coprocessors to accelerate FHE computations. - Privasea: At the intersection of AI and FHE, Privasea is creating privacy-preserving AI models that keep sensitive data secure. - Octra: Building an FHE-focused Layer 1 blockchain, Octra is laying the groundwork for a privacy-first decentralized ecosystem. - IncoNetwork: Another player in the FHE Layer 1 blockchain space, IncoNetwork is developing tools to make FHE more practical and scalable. - FairBlock: Specializing in modular FHE solutions, FairBlock is crafting tools that can be easily integrated into existing systems to enhance privacy. - MindNetwork: Exploring decentralized AI with FHE, MindNetwork is pushing the boundaries of what’s possible in secure machine learning. - SunscreenTech: Known for their FHE compilers, SunscreenTech is making it easier for developers to implement FHE in their applications. - zkHoldem: Using FHE to make on-chain gambling secure, zkHoldem is blending privacy with entertainment on blockchain platforms. These companies are not just building tools—they’re crafting the future of privacy in a decentralized world. The FHE ecosystem is rapidly expanding, with innovations in general-purpose FHE blockchains, hardware acceleration, and specialized applications like private voting and confidential ERC20 tokens. Why Should You Care About Homomorphic Encryption? (No, Really) Homomorphic Encryption isn't just a technical marvel—it's a transformative technology with real-world implications that touch every aspect of data security and privacy. Here's why it matters to you: 1. Enhanced Privacy: Your Data Stays Safe, Always Traditional encryption methods are effective at keeping your data safe when it's stored (at rest) or being transmitted (in transit). However, the moment you need to use that data, whether for analysis, processing, or anything else, it must be decrypted, exposing it to potential risks. With Homomorphic Encryption, your data remains encrypted throughout its entire lifecycle, including during computation. This means that even while performing operations on your data, it stays protected, drastically reducing the risk of exposure. For instance, if you're handling sensitive financial information or personal medical records, Homomorphic Encryption ensures that this data is never exposed, not even to those performing the computations. This enhanced privacy is crucial in an era where data breaches and privacy violations are increasingly common. 2. Secure Collaboration: Trust Without Compromise Sharing data with third parties, whether cloud providers, business partners, or research institutions, has always been a double-edged sword. On one hand, collaboration is necessary for innovation and efficiency. On the other, sharing data often means compromising its security, as it typically requires decryption at some stage. Homomorphic Encryption changes the game by allowing you to share encrypted data that can still be processed by the third party. The cloud provider or partner can perform the necessary computations on the data without ever seeing the raw, unencrypted information. This secure collaboration means that you can take advantage of cloud computing's scalability and processing power without sacrificing privacy. Imagine a scenario where multiple organizations need to collaborate on a sensitive research project. With Homomorphic Encryption, they can share encrypted data and run joint analyses without ever exposing their confidential data to one another. This fosters collaboration while maintaining strict privacy controls. 3. Unlocking AI & ML Potential using FHE Artificial Intelligence (AI) and Machine Learning (ML) thrive on data, but when that data is sensitive, like patient records, financial transactions, or proprietary algorithms, there's always a tension between using the data and keeping it secure. Homomorphic Encryption resolves this tension by allowing AI and ML models to be trained on encrypted datasets. This means you can unlock the full potential of AI and ML without ever exposing sensitive information. For instance, a healthcare provider could use Homomorphic Encryption to analyze encrypted patient data for predictive analytics or personalized treatment plans, ensuring that patient privacy is never compromised. Moreover, companies can collaborate on AI projects by sharing encrypted data and models, allowing them to innovate together without risking data breaches. This capability is especially crucial in sectors like finance, healthcare, and cybersecurity, where the integrity and confidentiality of data are paramount. How Does Lighthouse Come Into This? Now, here’s where it gets even more interesting. We at Lighthouse Storage are exploring the integration of Fully Homomorphic Encryption into its platform. But why? We aim to enable our users to store and process large encrypted datasets securely, making it perfect for AI startups, financial institutions, and healthcare organizations. !image4.png By leveraging FHE, Lighthouse can offer: - Encrypted Data Processing: Allowing computations on stored data without ever decrypting it, ensuring that privacy is never compromised. - Secure Sharing: Collaborate across untrusted domains without the risk of data exposure. - Regulatory Adherence: Meet the highest standards of data privacy laws by keeping sensitive data encrypted, even during processing. But Why Isn’t Homomorphic Encryption Everywhere Yet? If Homomorphic Encryption (HE) is so powerful, why isn’t it the standard everywhere? The short answer: it’s complicated. Despite its incredible potential, there are several significant challenges that have prevented HE—especially Fully Homomorphic Encryption (FHE)—from becoming ubiquitous. 1. Computational Cost: FHE is computationally intensive. It requires vast amounts of processing power and time, making it slower and more expensive compared to traditional encryption methods. This high computational cost has been a significant barrier to widespread adoption, particularly for applications that require real-time processing. 2. Noise Accumulation: One of the technical challenges with HE is the accumulation of noise during computations. Each operation on encrypted data introduces a small amount of noise. Over time, this noise can build up, potentially corrupting the results and making the data unusable. While bootstrapping techniques can clean up this noise, they add additional computational overhead, further slowing down the process. 3. Complexity: Implementing and maintaining HE systems is not straightforward. The mathematics behind HE is complex, requiring specialized knowledge to implement effectively. This complexity increases the risk of errors, making it more challenging to develop robust and secure HE solutions. 4. Limited Practical Implementations: Although FHE can theoretically support any computation on encrypted data, practical implementations have been limited to simpler operations or require substantial simplifications. This limitation means that many use cases are still beyond the reach of current FHE technology. Remedies and Ongoing Research Despite these challenges, the field of HE is rapidly advancing, with researchers and innovators working on several promising solutions: - Trusted Execution Environments (TEEs): TEEs provide a secure area within a processor where computations can be performed safely, even in potentially compromised environments. By combining HE with TEEs, it’s possible to offload some of the computational burden while maintaining strong security guarantees. - Improved Algorithms: Advances in HE algorithms, such as more efficient noise management techniques and optimized encryption schemes, are helping to reduce the computational overhead. These improvements are making HE more practical for a broader range of applications. - Hardware Acceleration: Specialized hardware, such as FHE-specific coprocessors or GPUs, can significantly speed up HE operations. Companies like Optalysys and Cysic are developing hardware solutions designed to accelerate FHE computations, making them more feasible for real-world applications. Noise Reduction Techniques: Researchers are exploring new methods to manage and reduce noise accumulation in HE systems. Techniques like TFHE, CKKS, and BGV are being developed to strike a balance between noise tolerance and computational efficiency, making HE more reliable and scalable. - Layered HE Architectures: By using a combination of different HE types, such as PHE, SHE, and FHE, it’s possible to create layered encryption schemes that optimize performance for specific use cases. For instance, PHE or SHE might be used for less sensitive operations, with FHE reserved for critical computations. Does FHE Seem Interesting To You? You will absolutely love this playlist of FHE Summit 2024 by FHEOnChain. https://youtube.com/playlist?list=PLeyFSoYRt-Wmp9w8THT64Bg3XOl1ZEw3O&si=4C3cbAfuHxEgmqJ Final Thoughts While Homomorphic Encryption isn’t yet a silver bullet for all privacy challenges, the progress being made is encouraging. As computational costs decrease and noise management improves, we can expect HE, especially FHE to play an increasingly vital role in securing sensitive data. The integration of HE with technologies like TEEs and hardware acceleration will further enhance its practicality, paving the way for broader adoption across industries. The future of data privacy may well be homomorphic, and as the technology continues to evolve, the dream of secure, private computations without compromising performance is steadily becoming a reality. The future of privacy is bright, and with innovators like Lighthouse leading the charge, we’re well on our way to a world where data is always protected, even when it’s in use.

5 min readarrow_forward
Discover How the Endowment Pool Makes Your Data Immortal
Articlecalendar_todayJul 15, 2024

Discover How the Endowment Pool Makes Your Data Immortal

Imagine a world where your data stays safe forever without you having to lift a finger. No more reminders to renew your storage deals, no more panicking about lost files. Welcome to perpetual storage with Lighthouse, powered by the Filecoin Network. In this blog, we're diving deep into the world of the Endowment Pool. We'll cover everything from what it is to how it works and why it's the future of data storage. So, grab a coffee, and let's dive in! A Revolution in Data Storage Before we get into what the endowment pool is all about, let's set the stage with the Filecoin Network. Filecoin isn’t just any storage network; it’s the superhero of decentralized storage. With over 12 EiB (exbibytes, if you’re wondering) of storage capacity, Filecoin has quickly become the go-to network for storing humanity’s most valuable information. Filecoin is more than just a vast storage network; it’s a revolution in how we store and access data. Traditional storage solutions often rely on centralized servers, which can be vulnerable to hacks, outages, and data manipulation. Filecoin flips this model by leveraging a decentralized approach, distributing data across a global network of storage providers. This not only enhances security but also ensures that data is stored in a redundant, highly reliable manner. The Global Community of Storage Providers One of the key strengths of Filecoin is its extensive community of over 3500 storage providers worldwide. These providers range from small individual operators to large-scale data centers, all contributing to the network's impressive storage capacity. By joining this network, they’re not just storing data; they’re part of a larger mission to preserve humanity’s most important information. This community-driven approach means that data is spread across multiple locations, reducing the risk of loss and ensuring greater resilience. Why Reinvent the Wheel When Filecoin is Already Rolling Strong? Why start from scratch when Filecoin is already a well-oiled machine with 3500+ storage providers globally? That’s why Lighthouse is built on this rock-solid network. Filecoin’s Proof of Replication (PoR) and Proof of Space-Time (PoST) ensure your data is stored uniquely and continuously, making it the perfect partner for perpetual storage. Proof of Replication is Like a Fingerprint for Your Data In the Filecoin network, Proof of Replication (PoR) ensures that storage miners hold a unique copy of your data. It’s like having a fingerprint for your files, ensuring no two are identical. This proof happens once when the data is initially stored, but its importance is monumental. PoR ensures no sneaky miner stores multiple copies of your data in the same space, keeping everything transparent and verifiable. Proof of Space-Time is the Marathon Runner of Data Storage While PoR is a one-time thing, Proof of Space-Time (PoST) is the marathon runner, continuously proving that miners dedicate space to your data over time. Miners must regularly demonstrate their commitment by passing PoST checks, ensuring your data remains safe and sound. Fail these checks, and miners face penalties. This ongoing verification is crucial for maintaining the integrity of perpetual storage on Lighthouse. !1.jpg Meet the Endowment Pool, Your Data’s Financial Guardian Angel Now, let’s talk about one of the most important components of the whole architecture, the Endowment Pool. Imagine Marcus Aurelius, the ancient Roman Emperor, creating the first endowment for philosophy studies in Athens. Fast forward to today, and Lighthouse uses a similar concept to sustain long-term data storage. !2.jpg How the Endowment Pool Works The Endowment Pool is a clever mechanism that ensures your data is stored forever without any additional effort on your part. Here’s how it works, step-by-step: 1. Initial Payment: When you pay to store your data on Lighthouse, your payment is divided into two parts. A small portion of the payment goes directly to the storage providers who will physically store your data on the Filecoin network for a limited period. This covers the immediate cost of storage. 2. Funding the Pool: The majority of your payment goes into the Endowment Pool. This pool is a financial reservoir designed to sustain your data storage indefinitely. It's like setting up a trust fund for your data, where the principal amount is invested wisely to generate continuous returns. 3. Investment and Growth: The funds in the Endowment Pool don’t just sit idle. They are actively invested to grow over time. Here’s how: 3.1 DeFi Protocols: A significant portion of the funds can be lent out in decentralized finance (DeFi) protocols to earn interest.Stablecoins like USDC, USDT, and DAI are typically used for these investments to minimize risk and ensure steady returns. 3.2 Filecoin Staking and Lending: Another part of the funds is held in Filecoin (FIL). These FIL tokens can be staked or lent to storage miners, earning additional rewards and yield. This dual strategy balances the pool's exposure to FIL price fluctuations while maximizing growth. 4. Continuous Funding: The Endowment Pool periodically releases funds to pay for the ongoing storage costs. This is where the magic happens: 4.1 Smart Contracts: The pool operates using smart contracts on the Filecoin Virtual Machine (FVM). These smart contracts automatically manage the release of funds based on predefined conditions and schedules. 4.2.Automated Payments: Funds are distributed regularly to storage providers, ensuring that your data storage fees are covered without any manual effort. When data deals expire, funds are automatically transferred to service providers to renew the deals. This seamless process keeps your storage updated, giving you lifetime data storage without the hassle. 5. Dynamic Management: The pool’s composition and investment strategies are dynamically managed to adapt to changing market conditions. This includes adjusting the proportion of funds allocated to different investment avenues and responding to fluctuations in the cost of storage or the returns on investments. By leveraging smart contracts and sophisticated financial strategies, the Endowment Pool ensures that your data remains safely stored on the Filecoin network indefinitely. This innovative approach not only secures your data but also frees you from the hassle of manual renewals and the risk of data loss. It's a set-it-and-forget-it solution for perpetual data storage. The Formula for Data Perpetuity The sustainability of the endowment pool hinges on a simple formula: !3.png !unnamed.png In essence, the rewards from the pool must always be greater than or equal to the cost of storing the data for the specified time. This formula ensures the perpetual storage of your data, making it financially sustainable. Master and Custom Pools Tailored to Your Needs Lighthouse offers flexibility with its endowment pools. !4.jpg The Master Pool is the default, overseen initially by the Lighthouse team and eventually governed by a DAO. This pool will be deployed across multiple chains for easy access. Custom Pools allow for specialized storage needs. Want a pool dedicated to NFT data? Done. Need a pool for blockchain state data? You got it. These custom pools can be funded and controlled by specific communities or DAOs, offering tailored storage solutions with various risk levels. Governance & Growth for a Bright Future As the endowment pool grows, its governance becomes crucial. Proposals can be made to decide the pool’s composition, investment strategies, and even fund public goods like DeSci initiatives. Transparency is key, with the endowment pool’s reserves and projections available on the blockchain, ensuring trust and accountability. The Replication Worker is Your Data’s Bodyguard Lighthouse doesn’t just rely on storage providers to keep your data safe. Enter the Replication Worker, a vigilant service that monitors storage deals and ensures data replications as requested by clients. If a storage provider drops your data, the Replication Worker triggers a deal repair, creating new storage deals to maintain the initial number of replications. It’s like having a dedicated bodyguard for your data, ensuring it’s always safe and sound. Transparency & Accountability with Smart Contracts One of the standout features of the endowment pool is its transparency. Thanks to EVM-based smart contracts, every transaction, every yield, and every reserve is visible on the blockchain. This transparency isn’t just about trust; it’s about giving users a clear picture of how their funds are being used and how long their data can be sustained. It’s like having a crystal-clear ledger that anyone can audit at any time. Beyond Storage, the Potential for Public Good The endowment pool’s potential doesn’t stop at storage. If the pool grows significantly, surplus funds could be used to support public goods. Imagine funding decentralized science (DeSci) projects, maintaining open-source software, or supporting other community-driven initiatives. The governance mechanisms in place allow for such decisions, ensuring that the benefits of the pool extend beyond just storage. What Happens if the Pool Dries Up While the endowment pool is designed to be sustainable, there’s always the question of what happens if the funds run low. In such a scenario, clients might be required to top up the pool. Governance proposals can also address how to manage such situations, ensuring that there’s always a plan B. Final Thoughts In a nutshell, the endowment pool on the Filecoin Network is not just a storage solution; it’s a revolution in how we think about data preservation. With Lighthouse at the helm, your data isn’t just stored – it’s immortalized. So, say goodbye to storage renewals and hello to the future of perpetual data storage.

5 min readarrow_forward
Web2 Storage Challenges Versus Web3 Solutions Ft. Lighthouse
Articlecalendar_todayMay 30, 2024

Web2 Storage Challenges Versus Web3 Solutions Ft. Lighthouse

When it comes to data storage, Web2 solutions trouble users with numerous problems like cost, efficiency, and security. Here, Web3 Storage emerges as a savior by offering the best possible solutions without compromising on data privacy. The global storage market was valued at over $185 billion in 2023, with North America contributing around $79 billion. This market size is expected to grow at a CAGR of 17.1% and is forecasted to reach a valuation of $774 billion by 2032. According to CoinMarketCap, the market cap of top storage tokens is over $16 billion. The increase in adoption of Web3-based storage solutions will play a crucial role in transforming the traditional storage solution, which has numerous problems. In this article, we'll explore Web2 solutions and their problems, Web3 solutions and their advantages, and the Web3 storage solutions offered by Lighthouse. What is Web2 Storage? !image1.jpg The Web2 storage solutions consist of traditional cloud storage options that save files and data in an offsite location. This stored data or files can be accessed using a dedicated private network or the public internet. Source: Geeksforgeeks.org A third-party cloud provider is responsible for the data transferred to the offsite location. This cloud provider manages, maintains, and secures the server and its infrastructure so that users can access their storage at any time. This storage uses remote servers to save users' data, such as documents, business data, videos, or images. To provide instant data availability to the user, cloud providers spread the available data to numerous virtual machines located in data servers in different parts of the world. Problems in Web2 Storage Now we'll understand the problems that the Web2 storage solutions face: Data Breaches: Web2 data storage systems are prone to various network-based attacks, as a vast quantity of data is stored in a single space or location. Hackers can gain unauthorized access, which has the potential to affect millions of users' data at once. - Single Point of Failure: The servers of Web2 storage create a single point of failure. A large-scale breach can instantly affect the vast amount of users' data, which can be lost forever. - Data Control: A few powerful Web2 entities, like Meta, Amazon, and Google, control users' data. Here, data accessibility can be misused for data monitoring and monetization without the user's permission. - Third-Party Dependency : In the case of Web2 storage solutions, users need to depend heavily on intermediaries for accessing and managing their stored data while accepting their terms and conditions. In addition, users are expected to trust these third parties blindly regarding the security and privacy of the stored data. - High Cost: Web2 storage solutions charge high costs from users for storing their files. The charges vary based on the file size or storage time, and there might be a vendor lock-in depending on the solution provider. What is Web3 Storage? !image5.jpg Web3 storage, or decentralized storage, involves the storing of data on a network of computers instead of a single server. In this storage, unused spaces are utilized efficiently with the help of blockchain technology instead of relying upon vast data centers. Source: Moonbeam.network The workings of Web3 storage involve storing data across multiple nodes connected to P2P networks like the Interplanetary File System (IPFS) protocol. Here, the data is split into numerous pieces and sent across millions of nodes across the network. When a user plans to retrieve their stored data, the network collects all the distributed pieces together. Finally, the user gets back their original data, which is available to access or download. What Problems Does Web3 Storage Solve? Web3 storage solutions help to solve the problems faced by Web2 storage solutions, such as: - Improved Security: The data are stored across different nodes using high-end encryption to protect the user's data. The blockchain's immutability feature helps avoid potential attacks that existed with Web2 storage solutions. - Enhanced Privacy: You also needn't worry about the privacy of your files with sensitive information. Unlike Web2 storage, your file will be fragmented into numerous parts before sharing it with multiple nodes, ensuring maximum privacy. - Low Cost: The availability of numerous nodes that host the data increases the availability of storage space. For this reason, the cost required to pay for the space is lower compared to that of Web2 storage. - Faster Download: Web2 storage solutions can face network issues when the traffic is higher than the network's capacity. Web3 storage, on the other hand, has the potential to reduce bandwidth usage as the nodes that store data are distributed globally. - Data Ownership: In Web3 storage solutions, users have complete ownership and control of their data, allowing them to access their files at any time. This feature helps shift data ownership from a centralized entity to individual users. - Enhanced Accessibility: The Web3 storage solution removes the need for intermediaries between the user and the storage space. This access barrier is removed, allowing users with an internet connection to participate in the benefits of decentralized storage networks. It's important to know about Filecoin, the frontier of Web3 data storage, to better understand the use case of Web3 storage. What is Interplanetary File System (IPFS)? !image3.jpg Interplanetary File System (IPFS) is a decentralized file storage protocol that allows users to store and share files within a peer-to-peer network. It was developed to address the limitations of server-based systems that rely on a centralized entity. Source: Researchgate.net When a user stores data on the IPFS network, it's broken into multiple pieces that can support a maximum payload of 256 KB. Then, each piece of data is cryptographically hashed with a unique content identifier (CID). The data splitting method allows IPFS to store large files without overloading the network. Moreover, the data on IPFS networks are resistant to censorship and tampering. What is Filecoin? !image4.jpg Filecoin is a P2P network that allows users to store files in a decentralized manner using cryptography to safeguard their data. Protocol Labs introduced this blockchain project in 2017 to provide an efficient alternative to Web2 storage solutions. The launch of Filecoin facilitated the efficient use of storage resources, offering users high transparency and security. Filecoin utilizes unused data storage worldwide to offer users cheaper pricing. Filecoin works on top of a decentralized web protocol called the Interplanetary File System (IPFS). This protocol identifies data based on the content type rather than its location to improve transparency, accessibility, and security. Source: Researchgate.net The Filecoin ICO was conducted in 2017, successfully raising over $257 million, the largest ICO figure at that time. At the time of writing, Filecoin (FIL), the native cryptocurrency of Filecoin, is valued at over $3 billion. We'll now explore the contribution of Lighthouse in the Web3 storage ecosystem. What is Lighthouse? !image2.jpg Lighthouse is a permanent file storage facilitator built on Filecoin and IPFS that allows users to permanently store files by paying once. Unlike traditional Web2 storage, users don't need to track time spent storing their data. This permanent ownership-based file storage will help store users' valuable data, including NFT metadata. Lighthouse also supports the deployment of smart contracts on Filecoin Virtual Machine (FVM), Solana, Polygon, and more. Lighthouse's perpetual protocol operates along with a smart contract-powered endowment pool to pay storage providers. When someone pays to store a file, a portion of that fund is distributed to the Filecoin network's storage providers, and the remaining fund is distributed to the endowment pool. Features of Lighthouse The major features of Lighthouse include: - Permanent Storage: Lighthouse allows users to pay once and own the storage space indefinitely. This feature eliminates the pain of subscription model payment options available with the traditional Web2 storage solutions. - Image Optimization: Users have the flexibility to fix the height and width of their stored images while retrieving them from the IPFS. This image optimization option helps users save bandwidth, allowing more storage choices. - Payment Flexibility: Lighthouse allows users to pay with any tokens from popular blockchain networks like Ethereum, Solana, Optimism, and Polygon, to name a few. This multi-chain support allows users to integrate with supported dApps. - Zero Lock-in: Users don't need to face difficulties associated with any constraints associated with specific storage providers. For this reason, you can always access and manage your data 24/7. - Lower Cost: Lighthouse offers low-cost storage solutions by leveraging the open market of Filecoin miners who earn block rewards from its network. - Encryption and Privacy: The user's data are secured efficiently using encryption technology. Moreover, files are stored in fragments to protect the privacy of their file's content. - Fast File Retrievals: The availability of Lighthouse's custom IPFS gateway helps you retrieve your files faster. This feature is applicable to low and high-size files like high-resolution video files. Conclusion There is a growing demand for data storage that needs to be addressed properly. The traditional Web2 storage provider fails to offer its users cost-efficient, secure, and privacy-ensured solutions. The development of Web3 storage solutions emerges to solve the issues faced by Web2 storage. Lighthouse utilizes the potential of IPFS and Filecoin to deliver permanent storage spaces for users for lower fees.

5 min readarrow_forward
On-Chain Encryption: Security Unveiled
Articlecalendar_todayJan 23, 2024

On-Chain Encryption: Security Unveiled

On-Chain Encryption: Security Unveiled In the ever-evolving landscape of blockchain technology, security remains a paramount concern. As the decentralized ecosystem continues to flourish, ensuring the confidentiality and integrity of data has become more critical than ever. One of the key pillars upholding this security is on-chain encryption. In this blog post, we will embark on a journey to unveil the intricacies of on-chain encryption, exploring its significance, implementation, and the transformative impact it has on the blockchain landscape. Understanding On-Chain Encryption At its core, on-chain encryption is a cryptographic technique employed to safeguard data stored on the blockchain. Unlike traditional centralized systems, where data is often vulnerable to breaches, on-chain encryption ensures that information remains confidential and tamper-resistant. This form of encryption involves encoding data before it is stored on the blockchain, making it accessible only to authorized parties with the corresponding decryption keys. The Significance of On-Chain Encryption 1. Confidentiality: Protecting Data from Prying Eyes On-chain encryption provides a robust shield against unauthorized access. By encrypting data before it is added to the blockchain, sensitive information becomes virtually indecipherable to anyone without the proper decryption keys. This not only safeguards user privacy but also enhances the overall security of the blockchain network. 2. Integrity: Safeguarding Against Tampering Tamper-proofing is a crucial aspect of on-chain encryption. Once data is encrypted and added to the blockchain, any attempt to alter it without the correct decryption keys would result in corrupted information. This ensures the integrity of the data and establishes trust within the decentralized network. 3. Access Control: Granting Permissions Wisely With on-chain encryption, access control becomes a nuanced process. Network participants can control who has access to specific encrypted data by managing and distributing decryption keys. This granular control over data access adds an extra layer of security, reducing the risk of unauthorized data exposure. Implementing On-Chain Encryption The implementation of on-chain encryption involves a meticulous process that integrates cryptographic algorithms with blockchain protocols. Smart contracts, a key component of blockchain technology, play a pivotal role in facilitating on-chain encryption. These self-executing contracts enable the creation and enforcement of encryption protocols, ensuring that data is secured before being added to the blockchain. Developers utilize various encryption algorithms such as Advanced Encryption Standard (AES) or Elliptic Curve Cryptography (ECC) to encode data. These algorithms are selected based on their strength, efficiency, and compatibility with the specific blockchain framework. Challenges and Future Developments While on-chain encryption significantly enhances security, it is not without challenges. Balancing the need for security with considerations such as computational overhead and scalability remains an ongoing concern. Researchers and developers continue to explore innovative solutions to optimize on-chain encryption without compromising performance. Looking ahead, the integration of quantum-resistant encryption algorithms and the development of standardized on-chain encryption protocols are expected to further fortify blockchain security. As the technology evolves, the synergy between cryptographic advancements and blockchain applications will continue to shape the future of secure, decentralized systems. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
NFT Storage Strategies
Articlecalendar_todayJan 19, 2024

NFT Storage Strategies

NFT Storage Strategies In the ever-evolving landscape of Non-Fungible Tokens (NFTs), the underpinning infrastructure of storage strategies stands as a critical facet often warranting meticulous consideration. In this discourse, we delve into the nuanced realm of NFT storage, shedding light on key strategies that define the contemporary safeguarding of digital assets. 1. Blockchain Anchors: At the nucleus of NFT storage lies the immutable and decentralized ledger – the blockchain. Predominantly championed by Ethereum, blockchain networks serve as the custodians of ownership details and transaction history. The diversification of blockchain alternatives, exemplified by the emergence of Binance Smart Chain and others, underscores the dynamism within the storage domain. 2. IPFS: Decentralized Resilience: InterPlanetary File System (IPFS), an avant-garde decentralized file storage protocol, adds a layer of resilience to NFT storage. It dissects digital files into smaller fragments, distributed across a decentralized network. This strategic decentralization ensures the preservation of digital assets without reliance on a singular point of vulnerability. 3. Metadata Integrity: The soul of NFTs lies in their metadata – the intricate details that breathe life into these digital artifacts. While blockchain shoulders the weight of transactional data, IPFS serves as an ideal repository for the metadata, ensuring the comprehensive story behind each NFT is securely stored and globally accessible. 4. Cloud Integration: In select instances, a pragmatic approach involves the integration of cloud storage solutions into the NFT storage matrix. This hybrid model leverages the scalability and agility of cloud infrastructure while maintaining the immutability derived from blockchain technology. This symbiosis results in expedited access without compromising the foundational principles of security. 5. Security Orchestration: A paramount concern in the NFT ecosystem is the fortification of assets against potential threats. The security orchestration involves a meticulous interplay of encryption algorithms, private key management, and blockchain consensus mechanisms. This multifaceted approach ensures the impregnability of digital assets amidst the prevailing cyber landscape. Conclusion: The discourse surrounding NFT storage strategies traverses a landscape as expansive and transformative as the digital frontier it seeks to secure. As the NFT ecosystem matures, so too will the strategies and methodologies devised to ensure the resilient preservation of these unique and valuable digital assets. This professional exploration invites stakeholders to navigate the intricate tapestry of NFT storage, where each strategic decision plays a pivotal role in shaping the future of digital ownership.

5 min readarrow_forward
Exploring Web3 Advancements in Storage Solutions
Articlecalendar_todayJan 18, 2024

Exploring Web3 Advancements in Storage Solutions

Exploring Web3 Advancements in Storage Solutions Introduction: In the rapidly evolving landscape of Web3 technologies, the realm of storage solutions has witnessed groundbreaking advancements, ushering in a new era of decentralized data management. Traditional centralized storage systems face challenges such as single points of failure, security concerns, and lack of transparency. Web3, with its emphasis on decentralization, introduces innovative approaches to address these issues and redefine how we store and manage data on the internet. 1. Decentralized Storage Protocols: Web3 storage solutions leverage decentralized protocols to distribute data across a network of nodes, eliminating the need for a central authority. Technologies like InterPlanetary File System (IPFS) and Filecoin enable users to store and retrieve data in a peer-to-peer fashion, enhancing data availability and reducing the risk of data loss. 2. Blockchain Integration for Data Integrity: Blockchain technology plays a pivotal role in ensuring data integrity and security. By anchoring data hashes or references to the blockchain, Web3 storage solutions create an immutable record of the stored information. This not only enhances data integrity but also provides a transparent and auditable trail of changes, making it tamper-resistant. 3. Tokenomics and Incentive Mechanisms: Web3 storage solutions often incorporate tokenomics and incentive mechanisms to encourage users to contribute their storage space and bandwidth to the network. Filecoin, for instance, allows users to earn tokens by renting out their unused storage capacity. This decentralized incentive model fosters a robust and self-sustaining ecosystem. 4. Smart Contracts for Automated Data Management: Smart contracts, a hallmark of blockchain technology, are employed in Web3 storage solutions to automate data management processes. Users can set predefined conditions and rules for accessing or updating data, and smart contracts execute these actions automatically, reducing the need for intermediaries and enhancing efficiency. 5. Content Addressing and Data Retrieval: Content addressing, as seen in protocols like IPFS, enables users to locate and retrieve data based on its content rather than its location. This paradigm shift in data retrieval ensures faster and more reliable access to information, as data remains accessible as long as there is at least one node in the network storing the content. 6. Privacy and Encryption: Web3 storage solutions prioritize user privacy by implementing robust encryption mechanisms. With end-to-end encryption and zero-knowledge proofs, users can retain control over their data, deciding who has access to it. This focus on privacy aligns with the principles of Web3, where users have sovereignty over their digital assets. 7. Challenges and Future Outlook: While Web3 storage solutions have made significant strides, challenges such as scalability, interoperability, and user adoption remain. Ongoing research and development aim to address these issues, and the future holds the promise of even more resilient, efficient, and user-friendly decentralized storage solutions. Conclusion: Web3's impact on storage solutions is transformative, ushering in a decentralized paradigm that empowers users with control, security, and transparency over their data. As the ecosystem continues to evolve, the integration of blockchain, smart contracts, and decentralized protocols will likely pave the way for a more robust and resilient data management infrastructure, shaping the future of the internet.

5 min readarrow_forward
Eternalizing Data: A Permanent storage
Articlecalendar_todayJan 18, 2024

Eternalizing Data: A Permanent storage

Eternalizing Data: A Permanent storage Eternalizing data through permanent storage solutions is a crucial aspect of modern information management. As technology evolves, the need for reliable and long-lasting storage becomes increasingly important. The term "Permanent Storage" encompasses various technologies and methods designed to ensure the durability, accessibility, and integrity of data over extended periods. Let's explore key aspects and technologies associated with eternalizing data in the context of permanent storage: 1. Data Archiving: - Permanent storage often involves the concept of data archiving, where data is stored in a secure and unalterable format for long-term retention. - Archiving solutions may utilize tape drives, optical discs, or other media designed for extended lifespan and minimal risk of data degradation. 2. Solid-State Drives (SSDs): - SSDs are non-volatile storage devices that provide faster access times and better durability compared to traditional hard disk drives (HDDs). - While not strictly "permanent" in the sense of eternal storage, SSDs offer a more robust and reliable option for long-term data retention. 3. Write-Once, Read-Many (WORM) Technology: - WORM technology ensures that data can be written only once and read multiple times. This is particularly useful for compliance and regulatory requirements. - WORM solutions can be implemented using specialized media or software-based approaches to prevent data tampering. 4. Cloud Storage with Replication: - Cloud storage providers often implement replication across multiple geographically dispersed data centers, ensuring data durability and availability even in the face of hardware failures or disasters. - Redundancy and backup strategies contribute to the permanence of data stored in the cloud. 5. Blockchain Technology: - Blockchain offers a decentralized and tamper-resistant ledger system, providing a level of permanence and immutability to data stored on the blockchain. - While not suitable for all types of data, blockchain can be a viable solution for specific use cases requiring secure and permanent record-keeping. 6. Optical Storage Media: - Optical storage, such as Blu-ray discs or archival-grade DVDs, can provide long-term storage with minimal risk of data corruption. - These media types are designed to resist environmental factors that can affect other storage solutions. 7. Magnetic Tape Storage: - Magnetic tapes have been a reliable and cost-effective solution for archival storage over the years. - Tape libraries can store vast amounts of data with a focus on longevity and durability. 8. Data Migration and Refresh Strategies: - To ensure perpetual access to data, organizations may employ data migration strategies, periodically transferring data to newer storage technologies to prevent obsolescence. 9. Data Integrity Checks: - Regular integrity checks, checksums, and error correction mechanisms play a crucial role in maintaining the quality and accuracy of data stored in permanent storage solutions. In conclusion, achieving permanent storage involves a combination of technological choices, adherence to best practices, and a proactive approach to data management. As technology continues to advance, the quest for eternalizing data will likely involve innovative solutions to address evolving challenges in the realm of information storage and preservation.

5 min readarrow_forward
Revolutionizing Permanence in Data Storage
Articlecalendar_todayJan 18, 2024

Revolutionizing Permanence in Data Storage

Revolutionizing Permanence in Data Storage In the rapidly evolving digital era, the quest for eternalizing data has become a paramount concern. As organizations grapple with the challenges of preserving information over the long term, the concept of "Permanent Storage" has taken center stage. This blog delves into the revolutionary landscape of permanent storage solutions, exploring cutting-edge technologies and strategies that redefine the permanence of data. The Evolution of Permanent Storage: A Historical Perspective To appreciate the current state of permanent storage, it's essential to trace the evolution of data preservation. From the early days of magnetic tapes and optical discs to the advent of solid-state drives (SSDs) and cloud storage, the journey has been marked by constant innovation. Today, the landscape is witnessing a paradigm shift as we explore novel approaches to revolutionize permanence. Solid-State Drives (SSDs) - The Power of Persistence One of the standout technologies reshaping permanent storage is the rise of Solid-State Drives (SSDs). With faster access times and enhanced durability compared to traditional hard disk drives (HDDs), SSDs have become a stalwart choice for organizations seeking reliable and long-lasting storage solutions. We explore how SSDs are not only changing the speed of data access but also contributing to the resilience of stored information. Blockchain Technology - Immutable Records for the Ages Enter blockchain technology, a decentralized ledger system that has transcended its roots in cryptocurrency to become a revolutionary force in data permanence. By providing tamper-resistant and immutable records, blockchain is forging new possibilities for industries requiring secure and permanent record-keeping. We explore real-world applications and the transformative impact of blockchain on the permanence paradigm. Cloud Storage Redefined: Replication, Redundancy, and Reliability In the cloud era, data storage has taken on new dimensions. Cloud storage providers are revolutionizing permanence by implementing robust replication strategies across geographically dispersed data centers. Through redundancy and backup mechanisms, organizations can ensure the durability and availability of their data, even in the face of unforeseen challenges. We delve into the architecture and strategies that make cloud storage a game-changer in the pursuit of eternal data. Data Archiving: Preserving the Past, Securing the Future Permanent storage often involves the art of data archiving. We explore how archival-grade media, such as optical discs and magnetic tapes, are providing reliable, long-term storage solutions. With a focus on durability and resistance to environmental factors, these timeless technologies continue to play a pivotal role in the preservation of critical information. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
Decentralized Excellence: Elevating Data Storage with Lighthouse
Articlecalendar_todayJan 9, 2024

Decentralized Excellence: Elevating Data Storage with Lighthouse

Decentralized Excellence: Elevating Data Storage with Lighthouse In the ever-evolving landscape of data management and storage, the need for secure, efficient, and decentralized solutions has become more paramount than ever. Enter Lighthouse, a trailblazer in the realm of decentralized perpetual data storage, reshaping the way we safeguard and access our digital assets. Built on the robust foundations of IPFS (InterPlanetary File System) and Filecoin, Lighthouse brings forth a new era of data storage excellence. 1. Permanent Storage through Filecoin: A Paradigm Shift In a world accustomed to recurring subscription models and the constant threat of data loss, Lighthouse introduces a revolutionary concept – pay once, store forever. The Permanent Storage service, powered by Filecoin, offers users of Venly the opportunity to secure their files through decentralized glacier storage with a single one-time fee. This innovative model not only provides long-term cost efficiency but also ensures data permanence without the hassle of recurring payments. 2. Data Retrieval Services: Paving the Way for Seamless Access Lighthouse goes beyond mere storage; it redefines the entire data retrieval experience. Here's a glimpse into the spectrum of services under this category: - Dedicated Gateways: A Fast Lane for Large Files Lighthouse introduces Dedicated Gateways, serving as the expressway for Venly projects to upload large files on IPFS and retrieve them at unprecedented speeds. With a latency of less than 300 milliseconds, users can seamlessly stream 4K videos on IPFS. This feature not only emphasizes speed but also guarantees a responsive and efficient data retrieval experience. - On-Chain Encryption: Elevating Security Standards Security is paramount in the digital age, and Lighthouse recognizes this imperative. Files stored by Venly projects onto IPFS through Lighthouse gain an additional layer of security with the implementation of on-chain encryption. This advanced security measure ensures that data remains confidential and protected against unauthorized access, setting a new standard for decentralized storage security. - Token-Gated Communities: Empowering Venly Projects Lighthouse extends its capabilities to empower Venly projects further. With the help of Lighthouse's SDKs, creating token-gated communities becomes as simple as a click of a button. This feature allows Venly projects to seamlessly build exclusive communities, fostering a sense of engagement and exclusivity within their user base. Embracing the Future of Data Management Lighthouse's commitment to decentralized excellence is not merely a slogan but a promise upheld through innovative services and a user-centric approach. As we navigate an era where data privacy and accessibility are non-negotiable, Lighthouse stands tall as a beacon of security, efficiency, and decentralization. In Conclusion In the era of decentralized excellence, Lighthouse emerges as a frontrunner, offering a paradigm shift in data storage and retrieval. Through the visionary integration of Filecoin and IPFS, Lighthouse ensures permanence, speed, and security. From the groundbreaking pay-once-store-forever model to the advanced features like Dedicated Gateways, On-Chain Encryption, and Token-Gated Communities, Lighthouse paves the way for a future where data is not just stored but safeguarded, accessed seamlessly, and empowered through decentralization. The journey to decentralized excellence has begun, and Lighthouse leads the way.

5 min readarrow_forward
Navigating Permanent Storage: Harnessing the Power of Filecoin and IPFS
Articlecalendar_todayDec 13, 2023

Navigating Permanent Storage: Harnessing the Power of Filecoin and IPFS

Navigating Permanent Storage: Harnessing the Power of Filecoin and IPFS Introduction: In the rapidly evolving digital landscape, the permanence of data has become a central concern for businesses seeking to safeguard their valuable information. As organizations generate and accumulate vast amounts of data, the need for reliable and permanent storage solutions has never been more critical. This blog post explores the significance of permanent storage and how innovative technologies like Filecoin and IPFS are reshaping the landscape, providing robust solutions for businesses aiming to secure their data for the long term. Understanding the Need for Permanent Storage: The digital age has transformed data from a byproduct to a strategic asset, making the need for permanent storage more crucial than ever. Businesses, whether driven by compliance requirements, historical record-keeping, or future analytics, are compelled to seek solutions that ensure the longevity and accessibility of their critical information. Filecoin and IPFS: Revolutionizing Permanent Storage: Two groundbreaking technologies, Filecoin and IPFS (InterPlanetary File System), have emerged as key players in reshaping the landscape of permanent storage. Let's delve into how these innovative solutions contribute to the permanence and security of data. 1. IPFS (InterPlanetary File System): At the heart of the data permanence revolution is IPFS, a peer-to-peer distributed file system designed to make the web faster, safer, and more open. IPFS fundamentally changes the way data is stored and accessed by utilizing a decentralized network. Decentralization for Resilience: IPFS eliminates the reliance on a centralized server model, mitigating the risk of a single point of failure. By distributing data across a network of nodes, IPFS ensures greater resilience and reliability. This decentralization is foundational to achieving permanence in data storage. Content Addressing for Accessibility: IPFS employs content addressing, a method where files are identified by their content rather than their location. This promotes accessibility and flexibility, ensuring that data remains reachable even if the location or structure of the network changes over time. Versioning and Offline Access: IPFS facilitates versioning, allowing users to track changes to files over time. This feature is invaluable for maintaining historical records and managing data evolution. Additionally, IPFS enables offline access, ensuring that data can be retrieved even when disconnected from the internet—a critical aspect of long-term data preservation. 2. Filecoin: The Incentivized Storage Network: Complementing IPFS, Filecoin introduces an incentivized storage layer, creating a marketplace for decentralized storage. Filecoin allows users to rent out their unused storage space and earn Filecoin (FIL) in return, creating a dynamic and self-sustaining ecosystem. Incentivized Storage for Growth: Filecoin's unique model incentivizes users to actively contribute their storage resources, fostering the growth of a robust and distributed storage network. This approach ensures that there is ample storage capacity available and encourages a diverse range of participants to contribute to the network. Redundancy for Durability: In the Filecoin network, data is replicated across multiple nodes, enhancing redundancy and durability. This distributed redundancy ensures that even in the face of hardware failures or network issues, the data remains intact and accessible. Dynamic Pricing and Fair Competition: The marketplace-driven pricing model of Filecoin ensures fair and competitive rates for both storage providers and consumers. This dynamic pricing structure adapts to market forces, promoting efficiency and fairness in the storage ecosystem.

5 min readarrow_forward
Unveiling the Mechanics of Perpetual Storage
Articlecalendar_todayDec 12, 2023

Unveiling the Mechanics of Perpetual Storage

Unveiling the Mechanics of Perpetual Storage Introduction: In the ever-evolving landscape of data management, the quest for perpetual storage solutions has emerged as a transformative force. This blog aims to unravel the intricacies of perpetual storage, emphasizing its key components and their collective role in creating a resilient, format-agnostic, and perpetually accessible repository for the digital age. Understanding the Mechanics of Perpetual Storage: Perpetual storage is more than just a storage solution; it's a paradigm shift in how we approach data preservation. At its core, perpetual storage seeks to overcome the limitations of traditional storage methods by embracing adaptability, resilience, and longevity. Key Components of Perpetual Storage: 1. Format Agnosticism: The Foundation of Accessibility Perpetual storage relies on format-agnostic principles to ensure that data remains accessible across changing file formats. By divorcing data from specific formats, this approach guards against the risk of obsolescence, allowing information to transcend the ever-evolving landscape of technology. 2. Self-Healing Mechanisms: Preserving Integrity Over Time Critical to the perpetuity of stored data, self-healing mechanisms act as vigilant custodians. These automated processes detect and rectify errors, safeguarding the integrity of information against corruption and degradation. This proactive approach minimizes the risk of data decay, ensuring that stored content remains reliable over extended periods. 3. Decentralization for Resilience: Building Redundancy and Durability Perpetual storage embraces decentralized architectures to enhance resilience. By distributing data across a network of nodes, redundancy is achieved. In the event of hardware failures or technological shifts, the decentralized approach ensures that multiple copies persist, fortifying the longevity of stored information. 4. Integration with Emerging Technologies: Future-Proofing Information Assets Anticipating the inevitability of technological evolution, perpetual storage systems prioritize seamless integration with emerging technologies. This adaptability empowers users to migrate data effortlessly to new platforms or systems, eliminating the risk of data loss or degradation in the face of progress. Applications and Implications: 1. Cultural Heritage Preservation: Digitizing and Safeguarding Human History Perpetual storage finds profound applications in preserving cultural heritage. Whether it's digitized artworks, historical manuscripts, or artifacts, the format-agnostic and resilient nature of perpetual storage ensures that these invaluable cultural assets remain intact and accessible for generations to come. 2. Scientific Research and Archiving: Ensuring Continuity in Discovery Research institutions leverage perpetual storage to secure the longevity of critical scientific findings. Stored data becomes a valuable asset, persistently available for analysis and reference across generations, contributing to the enduring legacy of scientific exploration. 3. Personal and Family Archives: Creating Time Capsules for Generations Individuals entrust perpetual storage with personal and family archives, essentially creating digital time capsules. Family histories, photographs, and personal documents are securely stored, allowing descendants to connect with their heritage and history in a perpetually accessible manner. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
Decentralized Storage: A Smarter, Safer, and Cheaper Way to Manage Your Data
Articlecalendar_todayDec 12, 2023

Decentralized Storage: A Smarter, Safer, and Cheaper Way to Manage Your Data

Decentralized Storage: A Smarter, Safer, and Cheaper Way to Manage Your Data Introduction: In an era dominated by the relentless flow of data, reimagining the foundations of how we store and manage information has become imperative. Enter decentralized storage, a disruptive force challenging the conventional wisdom of centralized storage models. This comprehensive guide explores the intricacies of decentralized storage, shedding light on its key features, advantages, real-world applications, challenges, and the promising future it holds. Understanding Decentralized Storage: Decentralized storage fundamentally alters the landscape of data management. Unlike centralized models that rely on a singular entity, decentralized storage leverages a network of nodes, often underpinned by blockchain technology. This distributed architecture enhances security, transparency, and resilience. Key Features and Advantages: 1. Security and Immutable Ledger: Decentralized storage harnesses the cryptographic principles of blockchain, providing an unprecedented level of security. The decentralized nature of data storage makes it highly resistant to hacking, and the immutability of the blockchain ensures data integrity. 2. Redundancy and Reliability: Unlike traditional storage systems susceptible to single points of failure, decentralized storage thrives on redundancy. Data is replicated across multiple nodes, ensuring seamless retrieval even if one node experiences issues. 3. Cost Efficiency and Sustainability: Decentralized storage transforms the economics of data management by tapping into unused storage space from individuals or organizations. This democratization of resources significantly reduces operational costs and fosters a more sustainable storage solution. 4. Privacy and Ownership Control: Users gain unprecedented control over their data with cryptographic keys and smart contracts. This empowers individuals to dictate access conditions, ensuring data ownership and mitigating concerns of unauthorized use. 5. Scalability: The decentralized architecture of storage allows for organic scalability. As data demands increase, the network can effortlessly expand by integrating additional nodes, preserving performance and responsiveness. Real-World Applications: 1. Blockchain and Cryptocurrencies: Decentralized storage forms the backbone of blockchain networks, enhancing the security and transparency of transactions. Cryptocurrencies, dependent on secure ledgers, benefit immensely from this technology. 2. File Storage and Sharing Platforms: Decentralized storage solutions are ideal for file storage and sharing services. Users can securely store and share files without relying on a centralized service, minimizing the risk of data breaches and ensuring accessibility. 3. Content Delivery Networks (CDNs): Content delivery networks leverage decentralized storage to optimize the distribution of web content. By dispersing data across various nodes globally, latency is reduced, and content availability is enhanced, improving the overall user experience. Conclusion: Decentralized storage is not merely a technological innovation; it represents a fundamental shift in how we safeguard and manage our digital assets. As our reliance on data intensifies, embracing decentralized storage is not just a choice; it is a strategic step toward a future where security, transparency, and user-centricity redefine the landscape of data management. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
Lighthouse: Secure Web3 Storage for Your AI Data
Articlecalendar_todayDec 7, 2023

Lighthouse: Secure Web3 Storage for Your AI Data

Lighthouse: Secure Web3 Storage for Your AI Data In the rapidly evolving landscape of artificial intelligence, ensuring robust data security is paramount. As AI projects increasingly turn to platforms like Hugging Face for data storage, concerns about vulnerability emerge. Enter Lighthouse, a pioneering force in decentralized perpetual data storage, reshaping the narrative by placing unparalleled emphasis on data security through its robust Web3 storage protocol built on IPFS, Filecoin, and cutting-edge encryption technologies. Decentralized Storage: Fortifying Security in the Web3 Realm Traditional centralized storage models have long grappled with security vulnerabilities, but Lighthouse transforms this landscape by harnessing the power of decentralization through IPFS and Filecoin in the Web3 domain. This not only establishes a more resilient infrastructure but also marks a revolutionary shift in addressing data security concerns in the era of artificial intelligence. Permanent Storage: A Pillar of Security in the Web3 Space Central to Lighthouse's commitment to data security is its permanent storage model, powered by Filecoin in the Web3 environment. Users can opt for Web3 storage with a one-time fee, introducing a novel pay-once-store-forever approach. This innovative concept not only eliminates the risks associated with recurring payments but also ensures the perpetual availability of data, securing it within the decentralized Web3 space. Data Retrieval: Web3 Efficiency Harmonizes with Security Lighthouse's multifaceted approach to data retrieval aligns seamlessly with its commitment to security in the Web3 paradigm. 1. Dedicated Gateways: A Web3 Symphony of Speed and Security Lighthouse's dedicated Web3 gateways redefine the landscape of data retrieval through IPFS. Venly projects benefit from an unparalleled latency of less than 300 milliseconds, ensuring not only efficiency but also a secure and streamlined experience. The combination of Web3 speed and security sets new benchmarks for data access reliability. 2. On-Chain Encryption: A Robust Fortress for Web3 Data Addressing the sensitivity of AI project data in the Web3 era, Lighthouse introduces on-chain encryption. This advanced feature adds an extra layer of security to files stored on IPFS within the Web3 space. Through the integration of blockchain technology, Lighthouse ensures data confidentiality and guards against unauthorized access in the Web3 realm. This proactive encryption strategy solidifies Lighthouse as a secure sanctuary for critical datasets within the Web3 landscape. 3. Token-Gated Communities: Precision Control Over Web3 Access Lighthouse's SDK empowers Venly projects to effortlessly create token-gated Web3 communities. This innovative access control mechanism enables project owners to define and enforce access based on specific token criteria within the Web3 environment. Beyond just restricting access, Lighthouse provides project owners with a potent tool to implement nuanced and sophisticated Web3 data access controls, setting new standards for precision control in data security. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
Understanding How web3 storage Operates
Articlecalendar_todayDec 7, 2023

Understanding How web3 storage Operates

Understanding How web3 storage Operates Introduction: In the dynamic landscape of the internet, Web3 storage has emerged as a transformative force, revolutionizing the conventional methods of storing and managing data. This comprehensive guide aims to unravel the intricacies of Web3 storage, shedding light on its fundamental principles, benefits, and operational mechanisms within the broader context of decentralized technologies. I. Understanding Web3 Storage The evolution from Web2 to Web3 The evolution from Web2 to Web3 is a significant paradigm shift from centralization to decentralization. In the past, traditional server models were used to store and retrieve data in a centralized manner. However, with the emergence of Web3 storage, a new era has begun that harnesses decentralized networks to store and retrieve data. This creates a more secure and private experience for users, as well as a more democratic and equitable internet. B. Decentralization and Data Integrity: This approach of Web3 storage is quite different from traditional storage systems. Instead of relying on a centralized system, Web3 storage decentralizes data across a network of nodes. This helps fortify data integrity and security. In this system, each piece of information is distributed across multiple nodes, reducing the risk of single points of failure and enhancing resistance to censorship. II. Core Components of Web3 Storage A. Protocols: Web3 storage is built on top of robust protocols such as the InterPlanetary File System (IPFS) and the innovative Filecoin. IPFS introduces content-addressed storage that links data via cryptographic hashes. On the other hand, Filecoin, a cryptocurrency native to the ecosystem, incentivizes users to contribute and earn tokens based on their storage contributions. B. Encryption: Security is of utmost importance in Web3 storage. The implementation of strong encryption mechanisms, such as end-to-end encryption and cryptographic hashing, is critical to protect data from unauthorized access, ensuring that the privacy and integrity of stored information are maintained. III. How Web3 Storage Works A. Content Addressing: Web3 storage utilizes content addressing, which is a technique that uniquely identifies and retrieves data. Instead of using traditional URLs, data is referenced through cryptographic hashes that are derived from the content itself. This approach enhances both efficiency and security. B. Decentralized File Storage: Web3 storage is designed to break files into smaller chunks and distribute them across multiple nodes. This decentralized approach to file storage ensures that no single entity has complete control over the entire file, which contributes to the resilience and scalability of the storage network. C. Token Incentives: Filecoin has a one-of-a-kind incentive mechanism that uses tokens to encourage users to contribute their unused storage space to the network. This results in the creation of a decentralized marketplace for storage resources, which allows users to participate in the Web3 storage ecosystem and earn Filecoin. IV. Benefits of Web3 Storage A. Enhanced Security: The statement you provided highlights the key benefits of Web3 storage. With its decentralized nature and strong encryption measures, Web3 storage provides enhanced data security. In addition, the distributed architecture helps to reduce the risk of cyberattacks and unauthorized access to data. All of these factors make Web3 storage a compelling solution for organizations looking to keep their data safe and secure. B. Increased Accessibility: Web3 storage has been designed to promote data accessibility by eliminating geographical restrictions. This means that users can access and retrieve data from the nearest available node, which in turn helps to reduce latency and enhance overall user experience. C. Cost Efficiency: Token-based incentive models, as demonstrated by Filecoin, can transform storage into a commodity, resulting in cost efficiencies. By utilizing their excess storage capacity, users have the opportunity to earn tokens, which in turn creates a more sustainable and cost-effective storage solution. Conclusion: Web3 storage is a game-changer when it comes to data storage on the internet. With its focus on decentralization, robust protocols, and innovative incentive mechanisms such as Filecoin, Web3 storage offers enhanced security and accessibility, while paving the way for a new era of data management. Despite the challenges, the potential for Web3 storage to revolutionize the digital landscape is enormous. The Best Web3 Storage Provider – Use web3 storage with Lighthouse As you embark on your journey into the world of Web3 storage, consider exploring the offerings of Lighthouse.Storage. Lighthouse.Storage stands out as a decentralized perpetual data storage protocol on Filecoin, providing a reliable and secure solution for your storage needs. Discover the possibilities of decentralized storage with Lighthouse.Storage and be part of the Web3 revolution today.

5 min readarrow_forward
Web3 Storage: IPFS and Filecoin Guide
Articlecalendar_todayDec 1, 2023

Web3 Storage: IPFS and Filecoin Guide

As the digital landscape moves towards the Web3 era, the internet is undergoing a substantial shift towards decentralization, transparency, and user empowerment. This guide takes you on a comprehensive journey through the intricate world of data storage and highlights two pioneering technologies, IPFS (InterPlanetary File System) and Filecoin. These innovations are not just components of Web3; they are the foundations of a new era in storing data. Understanding Web3: The internet is going through a significant transformation as it transitions into the Web3 era. This shift is bringing about changes in the way we store data, with a focus on decentralization, transparency, and user empowerment. In this guide, we will explore the world of data storage and shed light on two groundbreaking technologies, IPFS (InterPlanetary File System) and Filecoin. These technologies are not just components of Web3, but they are the foundation of a new age of data storage. The Role of IPFS (InterPlanetary File System): IPFS (InterPlanetary File System) is a peer-to-peer distributed file system that plays a vital role in this digital transformation. It is designed to revolutionize the way we store data by moving away from the traditional model that relies on centralized servers. Instead, IPFS uses a decentralized network architecture where each file and its blocks are given a unique cryptographic hash, which ensures data security and integrity. IPFS is more than just a storage solution. It represents a significant shift towards a more resilient and fault-tolerant storage infrastructure. Key Features of IPFS: IPFS is built on several foundational features that contribute to its revolutionary character. One of its most significant features is decentralization, which eliminates the risks associated with a single point of failure and fosters a more robust storage ecosystem. Another cornerstone of IPFS is content addressing, which enables files to be identified by their content rather than their location, promoting accessibility and flexibility. Versioning is another essential feature of IPFS, which makes it easy to track changes to files over time, enhancing collaboration and data management. In addition, IPFS provides offline access to data, ensuring that files can be retrieved even when disconnected from the internet. This feature is a testament to the system's adaptability and makes it an ideal choice for a wide range of use cases. Filecoin: The Incentive Layer for IPFS: Filecoin takes the principles of IPFS to new heights, emerging as an innovative incentive layer for decentralized storage. It is more than just a cryptocurrency; it constitutes the economic backbone of a decentralized storage network. Filecoin establishes a marketplace that allows users to rent out their unused storage space, earning Filecoin (FIL) in return. This dynamic and self-sustaining ecosystem introduces a novel way for individuals and entities requiring storage solutions to seamlessly connect with providers in a secure and decentralized manner. Filecoin's marketplace allows for the creation of a decentralized storage network that is more efficient, secure, and cost-effective than traditional storage solutions. Advantages of Filecoin: Filecoin offers several advantages that make it a game-changer in the realm of decentralized storage. Its incentivized storage model encourages users to actively contribute their storage resources, fostering the growth of a robust and distributed network. This model ensures that there is always enough storage space available to meet the demands of users. Redundancy is inherent in the Filecoin system, as data is replicated across multiple nodes, ensuring enhanced durability and resilience. This feature ensures that data is always available, even in the event of hardware failure or other issues. The dynamic pricing model of Filecoin, influenced by market forces, guarantees fair and competitive rates for both storage providers and consumers. This approach fosters an ecosystem of collaboration and efficiency, ensuring that the network remains stable and sustainable over the long term. Overall, Filecoin represents a significant step forward in the world of decentralized storage, offering a range of benefits that make it an attractive choice for a wide range of users and applications. The Evolutionary Impact: IPFS and Filecoin represent a significant shift in how we perceive and manage data. By combining decentralized file storage with incentivized economic structures, this new paradigm offers a more secure, efficient, and cost-effective way to store data. The integration of these two technologies reshapes the dynamics of the digital space, promoting collaboration and innovation. Real-World Applications: IPFS and Filecoin are not just theoretical concepts but have real-world applications. IPFS is versatile, with applications ranging from content distribution platforms to decentralized applications (dApps). Filecoin's incentivized storage model has spurred the creation of decentralized cloud storage services. These technologies bring transformative possibilities to diverse industries, creating a more secure, efficient, and equitable digital space. Conclusion: IPFS and Filecoin are the catalysts for the evolution of secure, decentralized, and incentivized data storage. As we navigate the Web3 age, there is no doubt that these technologies will guide us towards a future of empowerment, transparency, and collaboration. With IPFS and Filecoin leading the way, we can be certain that the future promises to be a canvas of infinite possibilities. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on GitHub. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
Passkey Demo App with WebAuthn and Ethereum
Articlecalendar_todaySep 21, 2023

Passkey Demo App with WebAuthn and Ethereum

Introduction In the realm of decentralized applications (dApps), user authentication remains a critical aspect. Traditional methods often rely on centralized servers, which can be a point of vulnerability. Enter Passkey: a decentralized authentication method that leverages the power of WebAuthn and Ethereum. What is Passkey? Passkey is a concept where users can authenticate themselves using cryptographic keys instead of traditional usernames and passwords. By integrating WebAuthn, a web standard for secure authentication, with Ethereum, a decentralized blockchain platform, Passkey offers a robust and secure authentication mechanism for dApps. In this guide, we'll walk you through creating a demo app that showcases this integration using create-react-app. Use cases Before jumping onto the tutorial, let us look at some use cases for a passkey type encryption on the decentralized web. The use cases ranges all the way from: - Decentralized Social Media - DeFi Applications - Healthcare Record Management To more general application like: - Website and Application Authentication - Multi-Factor Authentication (MFA) - Secure Document Access Basically anything that needs frequent signing for authentication can make use of Lighthouse Passkey authentication. Prerequisites Ensure you have Node.js and npm installed. If not, download and install them from Node.js official website. Setting Up 1. First, let's create a new React app: bash npx create-react-app passkey-demo cd passkey-demo 1. Install the necessary packages: bash npm install axios Utility Functions These functions will aid in the authentication process: 1. Fetching Authentication Message jsx const getAuthMessage = async (address) = { try { const data = await axios .get(https://encryption.lighthouse.storage/api/message/${address}, { headers: { "Content-Type": "application/json", }, }) .then((res) = res.data[0].message); return { message: data, error: null }; } catch (err) { return { message: null, error: err?.response?.data || err.message }; } }; 1. Buffer and Base64 Conversions jsx function bufferToBase64url(buffer) { const byteView = new Uint8Array(buffer); let str = ""; for (const charCode of byteView) { str += String.fromCharCode(charCode); } // Binary string to base64 const base64String = btoa(str); // Base64 to base64url // We assume that the base64url string is well-formed. const base64urlString = base64String ?.replace(/\+/g, "-") ?.replace(/\//g, "") ?.replace(/=/g, ""); return base64urlString; } function base64urlToBuffer(base64url) { let binary = atob(base64url?.replace(//g, "/")?.replace(/-/g, "+")); let length = binary.length; let buffer = new Uint8Array(length); for (let i = 0; i < length; i++) { buffer[i] = binary.charCodeAt(i); } return buffer; } 1. Transforming Public Key jsx function transformPublicKey(publicKey) { const selectedkeyindex = 0; let transformedPublicKey = { ...publicKey, challenge: new Uint8Array([...publicKey.challenge.data]), allowCredentials: [ { type: "public-key", id: base64urlToBuffer( publicKey.allowCredentials[selectedkeyindex]?.credentialID ), }, ], }; return [ transformedPublicKey, publicKey.allowCredentials[selectedkeyindex]?.credentialID, ]; } The Main App Our main React component will handle user interactions: jsx import React, { useState } from "react"; import axios from "axios"; import "./App.css"; function App() { // State variables for account, error, chain ID, keys, and token const [account, setAccount] = useState(""); const [error, setError] = useState(""); const [chainId, setChainId] = useState(""); const [keys, setKeys] = useState({}); const [token, setToken] = useState(""); // Function to connect to the Ethereum wallet const connectWallet = async () = { if (window.ethereum) { try { // Request account access const accounts = await window.ethereum.request({ method: "ethrequestAccounts", }); setAccount(accounts[0]); const chainId = await window.ethereum.request({ method: "ethchainId", }); setChainId(chainId); } catch (error) { console.error("User denied account access"); } } else { console.error("Ethereum provider not detected"); } }; // Function to disconnect from the Ethereum wallet const disconnect = () = { setAccount(""); setChainId(""); }; // Function to sign a message using the Ethereum wallet const signMessage = async (message) = { try { const signature = await window.ethereum.request({ method: "personalsign", params: [account, message], }); return signature; } catch (error) { setError(error.toString()); } }; // Convert account to lowercase for uniformity const username = account.toLowerCase(); // Function to login using Passkey const login = async () = { try { const startResponse = await axios.post( "https://encryption.lighthouse.storage/passkey/login/start", { address: username, } ); const publicKey = startResponse.data; const [transformedPublicKey, credentialID] = transformPublicKey(publicKey); // Get credentials using WebAuthn const credential = await navigator.credentials.get({ publicKey: transformedPublicKey, }); // Convert credential to a format suitable for the backend const serializeable = { authenticatorAttachment: credential.authenticatorAttachment, id: credential.id, rawId: bufferToBase64url(credential.rawId), response: { attestationObject: bufferToBase64url(credential.response.attestationObject), clientDataJSON: bufferToBase64url(credential.response.clientDataJSON), signature: bufferToBase64url(credential.response.signature), authenticatorData: bufferToBase64url(credential.response.authenticatorData), }, type: credential.type, }; const finishResponse = await axios.post( "https://encryption.lighthouse.storage/passkey/login/finish", { credentialID, data: credential, } ); const token = finishResponse.data.token; setToken(token); if (token) { alert("Successfully authenticated using webAuthn"); } } catch (error) { console.error("Error during login:", error); } }; // Function to register using Passkey const register = async () = { try { const { message } = await getAuthMessage(account.toLowerCase()); const signedMessage = await signMessage(message); const response = await axios.post( "https://encryption.lighthouse.storage/passkey/register/start", { address: account.toLowerCase(), } ); const publicKey = { ...response.data, challenge: new Uint8Array([...response.data?.challenge?.data]), user: { ...response.data?.user, id: new Uint8Array([...response.data?.user?.id]), }, }; // Create credentials using WebAuthn const data = await navigator.credentials.create({ publicKey }); const finishResponse = await axios.post( "https://encryption.lighthouse.storage/passkey/register/finish", { data, address: username, signature: signedMessage, name: "MY Phone", } ); const finishData = await finishResponse.data; if (finishData) { alert("Successfully registered with WebAuthn"); } else { throw new Error("Registration was not successful"); } } catch (error) { alert(error.message); } }; // Function to delete credentials const deleteCredentials = async () = { try { const startResponse = await axios.post( "https://encryption.lighthouse.storage/passkey/login/start", { address: username, } ); const publicKey = startResponse.data; const { message } = await getAuthMessage(account.toLowerCase()); const signedMessage = await signMessage(message); const response = await axios.delete( "https://encryption.lighthouse.storage/passkey/delete", { data: { address: account.toLowerCase(), credentialID: publicKey.allowCredentials[0]?.credentialID, }, headers: { "Content-Type": "application/json", Authorization: Bearer ${signedMessage}, }, } ); } catch (error) { alert(error.message); } }; // Render the app UI return ( <div className="App" <header className="App-header" {!account ? ( <button className="App-link" onClick={connectWallet} Connect Wallet </button ) : ( <button className="App-link" onClick={disconnect} Disconnect </button )} <p{Account: ${account}}</p <p{Network ID: ${chainId ? Number(chainId) : "No Network"}}</p <p Edit <codesrc/App.jsx</code and save to reload. </p {account && ( < <button className="App-link" onClick={register} Register </button <button className="App-link" onClick={login} Login </button <button className="App-link" onClick={deleteCredentials} Delete </button <textarea style={{ fontWeight: "0.9rem", maxWidth: "80vw" }} value={Bearer ${token}} </textarea </ )} </header </div ); } Let's Dive Into the Core Functions: 1. Connecting to Ethereum Wallet connectWallet Function Explanation: - Purpose: - The connectWallet function is designed to establish a connection with the user's Ethereum wallet. - Successful Connection: - Upon a successful connection, the function fetches the user's Ethereum account address and the associated chain ID. - These details, namely the account address and chain ID, are subsequently updated in the component's state. - Denied Access: - In scenarios where the user opts to deny access to their Ethereum wallet, an error message stating "User denied account access" is duly logged to the console. - Ethereum Provider Detection: - The function proactively checks for the existence of an Ethereum provider in the user's browser. This is typically facilitated by browser extensions such as MetaMask. - In the absence of an Ethereum provider, an error message "Ethereum provider not detected" is registered in the console. 2. Disconnecting from the Ethereum Wallet disconnect Function Explanation: - Purpose: - The disconnect function allows users to sever their connection from the Ethereum wallet. - State Reset: - Upon invocation, the function resets the account and chainId state variables to their default values, effectively logging the user out of their Ethereum wallet. 3. Signing a Message with Ethereum Wallet signMessage Function Explanation: - Purpose: - The signMessage function is crafted to solicit a signature from the user's Ethereum wallet for a specified message. - Signature Request: - The function dispatches a request to the user's Ethereum wallet, urging it to sign the provided message. - Error Handling: - Should there arise an error during the signing process, this error is not only logged to the console but also updated in the component's state. 4. Logging in Using Passkey login Function Explanation: - Purpose: - The login function orchestrates the login process leveraging Passkey. - Initial Request: - The function initiates the login process by dispatching a request, which in turn retrieves the public key. - Credential Creation: - Utilizing the WebAuthn API, the function prompts the browser to generate credentials. - Finalizing Login: - Post the creation of credentials, these are dispatched to the server to culminate the login process. - Token Retrieval: - On successful authentication, a token is fetched and updated in the component's state. 5. Registering with Passkey register Function Explanation: - Purpose: - The register function manages the user registration process via Passkey. - Message Retrieval: - Initially, the function fetches an authentication message and subsequently requests the user's Ethereum wallet to sign it. - Registration Start: - A request is dispatched to commence the registration process, fetching the public key in the process. - Credential Creation: - The WebAuthn API is invoked to prompt the browser to generate credentials. - Finalizing Registration: - Once credentials are generated, they, along with other pertinent details, are sent to the server to finalize the registration. 6. Deleting Credentials deleteCredentials Function Explanation: - Purpose: - The deleteCredentials function facilitates the removal of user credentials from the system. - Initial Request: - The function begins by initiating a request to retrieve the public key. - Message Retrieval and Signature: - An authentication message is fetched, which is then signed by the user's Ethereum wallet. - Deletion Request: - A delete request is dispatched to the server, carrying the user's address and credential ID, to remove the associated credentials. - Error Handling: - If any errors arise during the deletion process, they are presented to the user via an alert. Rendering the App UI return Function Explanation: - Main Container: - The entire UI is wrapped inside a <div element with a class of "App". - Header: - The main interactive elements and displays are located within a <header element with a class of "App-header". - Wallet Connection: - Depending on the user's Ethereum account status, either a "Connect Wallet" or "Disconnect" button is displayed. - Account and Network Display: - The Ethereum account address and the network ID are displayed. - Instructions: - A static message guides developers to edit the src/App.jsx file. - User Operations: - If the Ethereum account is connected, options to "Register", "Login", "Delete", and a textarea to display the authentication token are presented. --- Testing the Demo App After setting up the demo app and understanding its various components, it's time to test it out and see the Passkey authentication in action. Here's a step-by-step guide on how to test the demo app: 1. Start the React App: First, navigate to the root directory of your project in the terminal and run the following command to start the React development server: bash npm start This will automatically open a new browser window/tab with the app running on http://localhost:3000. 2. Connect Your Ethereum Wallet: On the app's main page, you'll see a "Connect Wallet" button. Click on it. If you have an Ethereum wallet extension like MetaMask installed, it will prompt you to connect your wallet to the app. Grant permission. !Untitled (10).png This will open your metamask extension asking for permission to connect. Grant the permission. !Untitled (11).png 3. View Account and Network Details: Once connected, the app will display your Ethereum account address and the network ID (or chain ID). This confirms that the app has successfully connected to your Ethereum wallet. !Untitled (12).png 4. Register with Passkey: Click on the "Register" button. This will initiate the Passkey registration process, which involves: - Fetching an authentication message. - Signing the message with your Ethereum wallet. !Untitled (13).png - Registering with the Passkey backend using WebAuthn. !Untitled (14).png - Suppose you use your connected mobile phone with the same google account logged in !Untitled (15).png - Complete the verification on your phone !Untitled (16).png If the registration is successful, you'll receive an alert saying "Successfully registered with WebAuthn". 5. Login using Passkey: After registering, click on the "Login" button. This will authenticate you using the previously registered credentials. Upon successful authentication, you'll receive a token, which will be displayed in Conclusion With the above setup, you now have a demo app that showcases the power and security of Passkey authentication. By combining the cryptographic strength of WebAuthn with the decentralized nature of Ethereum, Passkey offers a future-proof solution for dApp authentication. Dive in and explore the next generation of user authentication!

5 min readarrow_forward
Secure File Sharing using Lighthouse SDK: A Step-by-Step Guide
Articlecalendar_todaySep 4, 2023

Secure File Sharing using Lighthouse SDK: A Step-by-Step Guide

Introduction to Secure File Sharing with Lighthouse SDK In the realm of decentralized technology and applications, ensuring secure and efficient file-sharing has always been a top priority. Lighthouse, a notable player in this domain, has developed a robust SDK that aids developers in achieving this. This SDK leverages blockchain principles and IPFS, which stands for InterPlanetary File System, to ensure that files shared across networks are not only secure but also immutable and tamper-proof. Why is this important? In traditional file-sharing systems, there's a central server where files are stored. This poses several challenges: from server downtimes to the risk of central point failures and vulnerabilities. IPFS and blockchain, as adopted by Lighthouse, circumvent these challenges by storing files across a network, ensuring redundancy and security. Moreover, with the increasing emphasis on privacy and data protection regulations worldwide, tools like the Lighthouse SDK empower developers to build applications that prioritize user data security. By using encryption and decentralized storage, we can ensure that our users' files remain confidential, accessible only by intended recipients. What will you learn in this tutorial? This tutorial will guide you step-by-step on how to integrate the Lighthouse SDK into your Node.js application. By the end, you'll be able to securely share encrypted files with specified recipients, leveraging Lighthouse's decentralized storage and Ethereum's robust authentication mechanisms. Whether you're a seasoned developer or just starting out in the world of decentralized apps, this guide aims to make the process straightforward and intuitive. Let's get started by setting the foundation for our file-sharing application! Preparation: Prerequisites: - Ensure you have Node.js installed. If not, download it here. 1. Set Up Lighthouse SDK and Wallet: - Install the SDK globally: bash npm install -g @lighthouse-web3/sdk - Generate a new Lighthouse wallet. Safeguard the provided Public Key and Private Key: bash lighthouse-web3 create-wallet 2. Project Environment Configuration: - Create and navigate to a new directory for your endeavor: bash mkdir lighthouse-encryption && cd lighthouse-encryption - Commence a new Node.js project: bash npm init -y - Install the necessary local packages: bash npm install dotenv ethers 3. Enhancing Security: - Generate a .env file within your project directory. - Populate .env with your Lighthouse private key: makefile PRIVATEKEY=YourPrivateKey - To maintain security, add .env to your .gitignore file, especially vital if using a version control platform. --- Implementation: 1. Setting the Groundwork: Within your project directory: - Construct a file named fileSharing.js. 2. Import and Initialization: In fileSharing.js, write: jsx import as dotenv from 'dotenv'; dotenv.config(); import { ethers } from "ethers"; import lighthouse from '@lighthouse-web3/sdk'; 3. Message Signing Function: This helper function will assist in the authentication process: jsx const signAuthMessage = async (publicKey, privateKey) = { const provider = new ethers.JsonRpcProvider(); const signer = new ethers.Wallet(privateKey, provider); const messageRequested = (await lighthouse.getAuthMessage(publicKey)).data.message; const signedMessage = await signer.signMessage(messageRequested); return signedMessage; } 4. File Sharing Procedure: Implement the function to handle file sharing via Lighthouse SDK To ensure clarity and simplicity, let's break down the file sharing procedure into three distinct points: 4.1 Initialize Variables: Set up the fundamental variables required for our function. Each variable holds specific data crucial for the operation: jsx const cid = "QmS2NzycJoA7De33qMWwqyE2w3BL1i396qfwZiHBb1KuZh"; // CID: Unique identifier for content on IPFS. const publicKey = "0x5D62F371206306F1ebd4573803F70772f1153186"; // PublicKey: Your Lighthouse identity. const privateKey = process.env.PRIVATEKEY; // PrivateKey: Secured key for authentication, stored away from the codebase. const receiverPublicKey = ["0xea447D81825282D3ec02772f1ab045ec6227F3e4"]; // ReceiverPublicKey: Intended recipient's Lighthouse identity. 4.2 Authenticate and Sign the Message: With our variables set, the next step is to authenticate our actions by signing the message: jsx const signedMessage = await signAuthMessage(publicKey, privateKey); // SignedMessage: A verified authentication message for security. 4.3 Share the File: Having our signed message and our initialized variables, we're ready to share our encrypted file securely: jsx const shareResponse = await lighthouse.shareFile( publicKey, receiverPublicKey, cid, signedMessage ); // ShareFile: Lighthouse function to securely share your file. console.log(shareResponse); // ResponseOutput: Shows the result of the file-sharing action. // To view the shared file, navigate to: // https://files.lighthouse.storage/viewFile/<cid In the event of an error or an issue during this process, the catch block will capture and display it for our reference: jsx } catch (error) { console.log(error); } Lastly, initiate the function: jsx shareFile(); Full Code for Secure File Sharing using Lighthouse SDK: jsx import as dotenv from 'dotenv'; dotenv.config(); import { ethers } from "ethers"; import lighthouse from '@lighthouse-web3/sdk'; const signAuthMessage = async (publicKey, privateKey) = { const provider = new ethers.JsonRpcProvider(); const signer = new ethers.Wallet(privateKey, provider); const messageRequested = (await lighthouse.getAuthMessage(publicKey)).data.message; const signedMessage = await signer.signMessage(messageRequested); return signedMessage; }; const shareFile = async () = { try { const cid = "QmS2NzycJoA7De33qMWwqyE2w3BL1i396qfwZiHBb1KuZh"; // CID: Unique identifier for content on IPFS. const publicKey = "0x5D62F371206306F1ebd4573803F70772f1153186"; // PublicKey: Your Lighthouse identity. const privateKey = process.env.PRIVATEKEY; // PrivateKey: Secured key for authentication, stored away from the codebase. const signedMessage = await signAuthMessage(publicKey, privateKey); // SignedMessage: A verified authentication message for security. const receiverPublicKey = ["0xea447D81825282D3ec02772f1ab045ec6227F3e4"]; // ReceiverPublicKey: Intended recipient's Lighthouse identity. const shareResponse = await lighthouse.shareFile( publicKey, receiverPublicKey, cid, signedMessage ); // ShareFile: Lighthouse function to securely share your file. console.log(shareResponse); // ResponseOutput: Shows the result of the file-sharing action. // Navigate to view the shared file: // https://files.lighthouse.storage/viewFile/<cid } catch (error) { console.log(error); } }; shareFile(); 5. Running the Script: Execute the script: bash node fileSharing.js Observe the file-sharing response and ensure you can access the CID link to validate the secure file sharing. Wrap-Up: Congratulations! You've adeptly shared an encrypted file using the Lighthouse SDK. Always prioritize the security of your private and API keys.

5 min readarrow_forward
Time Lock Encryption using Lighthouse Access Control
Articlecalendar_todayAug 11, 2023

Time Lock Encryption using Lighthouse Access Control

Introduction In this tutorial, we delve into the innovative concept of Time-Lock Encryption on the InterPlanetary File System (IPFS) using Lighthouse Access Control. IPFS, often referred to as the distributed web, offers a decentralized protocol to make the web faster, p2p, and more open. On the other hand, Lighthouse.Storage is a Web3 decentralized storage solution, offering perpetual storage to store your data securely long-term. The amalgamation of these two technologies brings forth an exciting feature – the ability to encrypt files and set conditions for their decryption based on specific blockchain parameters. One of the innovative concept it enables is "Time-Lock Encryption." What exactly does this mean? Think of it as a time capsule. You can securely store a piece of information, and set a condition that this information will only be accessible after a particular block number on the blockchain like ethereum has been reached. Such a feature has a myriad of applications, from securing early-stage project details to establishing wills or contracts that are meant to be executed in the future. This tutorial will walk you through the following: 1. Preparing your environment for Lighthouse.Storage. 2. Encrypting and uploading a file onto IPFS. 3. Setting a blockchain-based time-lock condition for accessing this file on optimism chain. 4. (Optional) Retrieving the conditions set on a file. Whether you're a blockchain enthusiast, a developer looking to integrate time-lock features, or someone curious about decentralized storage and its potential, this guide is tailored for you. Let's embark on this journey and unlock the potential of Time-Lock Encryption on IPFS using Lighthouse Storage. --- Preparation: Note: Ensure you have Node.js installed. If not, download it here 1. Install Lighthouse SDK and Create Wallet: - Install the SDK globally: bash npm install -g @lighthouse-web3/sdk - Create a new Lighthouse wallet, which will provide you with a Public Key and a Private Key. Ensure you safely store this information: bash lighthouse-web3 create-wallet 2. Obtain Lighthouse API Key: - Generate a new API key: bash lighthouse-web3 api-key --new - You will be presented with an API key. Store this securely and avoid sharing it. 3. Environment Setup for Your Project: - Create a new directory for your project: bash mkdir lighthouse-encryption && cd lighthouse-encryption - Initialize a new Node.js project: bash npm init -y - Install required local dependencies: bash npm install dotenv ethers 1. Security Configuration: - Within your project directory, create a .env file. - Inside .env, add your Lighthouse API key and private key: makefile APIKEY=YourLighthouseAPIKey PRIVATEKEY=YourPrivateKey - Always ensure your .env file is added to .gitignore to prevent exposing your credentials, especially if you're using a version control system. --- Step 1: Upload an Encrypted File Set up a script, upload.js, in your project directory. Add the following code: jsx import as dotenv from 'dotenv'; dotenv.config(); import { ethers } from "ethers"; import lighthouse from '@lighthouse-web3/sdk'; const signAuthMessage = async (publicKey, privateKey) = { const provider = new ethers.JsonRpcProvider(); const signer = new ethers.Wallet(privateKey, provider); const messageRequested = (await lighthouse.getAuthMessage(publicKey)).data.message; const signedMessage = await signer.signMessage(messageRequested); return signedMessage; } const deployEncrypted = async () = { const path = "Absolute/path/to/your/file.txt"; // Update this path const apiKey = process.env.APIKEY; const publicKey = "YourPublicKey"; // Update this const privateKey = process.env.PRIVATEKEY; const signedMessage = await signAuthMessage(publicKey, privateKey); const response = await lighthouse.uploadEncrypted( path, apiKey, publicKey, signedMessage ); console.log(response); } deployEncrypted(); Run the script: bash node upload.js Expected Response: bash { data: [ { Name: 'test.txt', Hash: 'ENCRYPTEDCID', Size: '58' } ] } Step 2: Apply Access Control Condition: Create a script, access-control.js, with the following: jsx import as dotenv from 'dotenv'; dotenv.config(); import { ethers } from "ethers"; import lighthouse from '@lighthouse-web3/sdk'; const signAuthMessage = async (publicKey, privateKey) = { const provider = new ethers.JsonRpcProvider(); const signer = new ethers.Wallet(privateKey, provider); const messageRequested = (await lighthouse.getAuthMessage(publicKey)).data.message; const signedMessage = await signer.signMessage(messageRequested); return signedMessage; } const accessControl = async () = { try{ const cid = "YourFileCID"; // Update this with the CID from the previous step const publicKey = "YourPublicKey"; // Update this const privateKey = process.env.PRIVATEKEY; const conditions = [ { id: 1, chain: "Optimism", method: "getBlockNumber", standardContractType: "", returnValueTest: { comparator: "", value: "YourBlockNumber" }, // Update this value as per your requirements }, ]; // Aggregator is what kind of operation to apply to access conditions // Suppose there are two conditions then you can apply ([1] and [2]), ([1] or [2]), !([1] and [2]). const aggregator = "([1])"; const signedMessage = await signAuthMessage(publicKey, privateKey); const response = await lighthouse.applyAccessCondition( publicKey, cid, signedMessage, conditions, aggregator ); console.log(response); } accessControl(); Execute the script: bash node access-control.js Expected Response: bash { data: { cid: 'ENCRYPTEDCID', status: 'Success' } } Note: - Only the owner of the file can apply access conditions - This only works when file is uploaded with lighthouse encryption (Optional) Step 3: Retrieve Access Control Conditions: Formulate another script, get-conditions.js, as: jsx import lighthouse from '@lighthouse-web3/sdk'; const accessConditions = async() = { const cid = "YourFileCID"; // Update this const response = await lighthouse.getAccessConditions(cid); console.log("Condition:", response.data.conditions); console.log("Response:", response) } accessConditions(); Run the script: bash node get-conditions.js Expected Response: bash Condition: [ { id: 1, chain: 'Optimism', method: 'getBlockNumber', standardContractType: '', returnValueTest: { comparator: '', value: 'YourBlockNumber' } } ] Response: { data: { aggregator: '[1]', conditions: [ [Object] ], conditionsSolana: [], sharedTo: [], owner: 'YourPublicKey', cid: 'ENCRYPTEDCID' } } (Receiver side) Step 4: Verify Access and Retrieve Encryption Key: Once you've uploaded a file and set an access control condition, before attempting to download or decrypt it, you might want to check if you have the necessary permissions (or if the conditions have been met). This step will guide you on how to do just that: Prepare Your Script: Create a new script named verify-access.js in your project directory. Insert the following code: jsx import as dotenv from 'dotenv'; dotenv.config(); import { ethers } from "ethers"; import lighthouse from '@lighthouse-web3/sdk'; const signAuthMessage = async (publicKey, privateKey) = { const provider = new ethers.JsonRpcProvider(); const signer = new ethers.Wallet(privateKey, provider); const messageRequested = (await lighthouse.getAuthMessage(publicKey)).data.message; const signedMessage = await signer.signMessage(messageRequested); return signedMessage; } const getFileEncryptionKey = async () = { try { const cid = 'ENCRYPTEDCID'; // Replace with your CID const publicKey = 'Receiversidepublickey'; // Replace with your public key const privateKey = process.env.RECEIVERSIDEPRIVATEKEY; const signedMessage = await signAuthMessage(publicKey, privateKey); const keyResponse = await lighthouse.fetchEncryptionKey( cid, publicKey, signedMessage ); // Print the direct response console.log(keyResponse); } catch (error) { console.log("Error:", error.message); } } getFileEncryptionKey(); Run the Script: Execute the verify-access.js script: bash node verify-access.js Expected Response (When you have access): bash { data: { key: 'KEY' } } Expected Response (When you do not have access): bash { message: "you don't have access", data: {} } Conclusion By following this tutorial, you've encrypted a file on Lighthouse Storage and set a time-lock condition using the Optimism blockchain's block number. Before sharing or deploying any code, always remember to secure your private and API keys. To know more join our discord and get in touch with our team. Follow Lighthouse on X. ---

5 min readarrow_forward
A Comprehensive Guide to Publishing and Updating Content with Lighthouse IPNS
Articlecalendar_todayAug 4, 2023

A Comprehensive Guide to Publishing and Updating Content with Lighthouse IPNS

Introduction: Lighthouse IPNS (InterPlanetary Naming System) is a valuable tool that enables the creation of mutable pointers to content-addressed data in the IPFS (InterPlanetary File System) network. While IPFS ensures content immutability by generating unique CIDs for each piece of data, IPNS allows for regular updates to the content while retaining a consistent address. In this tutorial, we will explore two methods to publish and update content with Lighthouse IPNS: using the CLI (Command Line Interface) and Node.js. By the end of this guide, you will be able to effectively publish and manage IPNS records, making your content easily accessible and updatable. Prerequisites: Before we get started, ensure you have the following: 1. Basic understanding of IPFS and IPNS concepts. 2. Node.js installed on your system (for Node.js method). 3. Lighthouse CLI installed (for CLI method). Understanding Mutability in IPFS: In IPFS, content is typically addressed using CIDs, making it immutable. However, there are scenarios where content needs to be regularly updated, such as publishing a frequently changing website. IPNS addresses this challenge by creating mutable pointers to CIDs, known as IPNS names. These names act as links that can be updated over time while maintaining the verifiability of content addressing. Essentially, IPNS enables the sharing of a single address that can be updated to point to the new CID whenever content changes. How IPNS Works: 1. Anatomy of an IPNS Name: An IPNS name is essentially the hash of a public key. It is associated with an IPNS record that contains various information, including the content path (/ipfs/CID) it links to, expiration details, version number, and a cryptographic signature signed by the corresponding private key. The owner of the private key can sign and publish new records at any time. 2. IPNS Names and Content Paths: IPNS records can point to either immutable or mutable paths. When using IPNS, the CID's meaning in the path depends on the namespace used: - /ipfs/cid: Refers to immutable content on IPFS, with the CID containing a multihash. - /ipns/cid-of-libp2p-key: Represents a mutable, cryptographic IPNS name that corresponds to a libp2p public key. Step 0: Getting your lighthouse API key Files-Lighthouse-storage: 1. Go on https://files.lighthouse.storage/ and Click on Login !Untitled (2).png 2. Select any of the login method and perform verification steps !Untitled (3).png 3. Click on API Key on the left side panel on the dashboard. !Untitled.png 4. Insert name for your API !Untitled (1).png 5. Copy the API Key !Untitled design.png Store and Update content on IPNS using Lighthouse: Method 1: Using Lighthouse CLI - Step 1: Generate an IPNS key using the Lighthouse CLI: bash lighthouse-web3 ipns --generate-key This command will return an IPNS name and ID, which we will use later to publish the content. !Untitled (4).png - Step 2: Make a test file, text.txt: bash echo "Hello World" text.txt - Step 3: Publish this file to the IPFS using lighthouse upload: bash lighthouse-web3 upload ./text.txt !Untitled (5).png - Step 4: Publish the content using the generated IPNS key and the CID of the data you want to publish: bash lighthouse-web3 ipns --publish --key=8f4f116282a24cec99bcad73a317a3f4 --cid=QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u You will receive a link that can be used to access the published content. This link will remain valid even if the content's IPFS hash changes. !Untitled (6).png Updating CID: - Upload another file text2.txt: bash echo "Hello World2" text2.txt - Publish this file to the IPFS using lighthouse upload: bash lighthouse-web3 upload ./text2.txt !Untitled (7).png - Update the content using the generated IPNS key and the CID of the data you want to publish: bash lighthouse-web3 ipns --publish --key=8f4f116282a24cec99bcad73a317a3f4 --cid=QmanCeGkwsaCUHaNT24ndriYTYSwZuAy4JDifdYZpHdmRa You will receive a link that can be used to access the published content. This link will remain valid even if the content's IPFS hash changes. List all IPNS records associated with your Lighthouse account: bash lighthouse-web3 ipns --list This will display a list of IPNS records with their corresponding keys and CIDs. !Untitled (8).png Remove an IPNS record: bash lighthouse-web3 ipns --remove 8f4f116282a24cec99bcad73a317a3f4 This step allows you to remove an IPNS record if needed. !Untitled (9).png Method 2: Using Node.js Step 0: Get API keys from Lighthouse as explained above. Step 1: Import the Lighthouse package and set up your API key: jsx import lighthouse from '@lighthouse-web3/sdk'; const apiKey = process.env.APIKEY; // Replace this with your actual API key Step 2: Generate an IPNS key using the Lighthouse SDK: jsx const keyResponse = await lighthouse.generateKey(apiKey); console.log(keyResponse.data); This will return an IPNS name and ID, which we will use in the next steps. Step 3: Publish the content using the generated IPNS key and the CID: jsx const pubResponse = await lighthouse.publishRecord( "QmWC9AkGa6vSbR4yizoJrFMfmZh4XjZXxvRDknk2LdJffc", keyResponse.data.ipnsName, apiKey ); console.log(pubResponse.data); You will receive a response containing the IPNS name and the link to access the published content. Step 4: Get all IPNS keys associated with your Lighthouse account: jsx const allKeys = await lighthouse.getAllKeys(apiKey); console.log(allKeys.data); This step allows you to retrieve a list of all IPNS keys associated with your account. Step 5: (Optional) Remove an IPNS key: jsx const removeRes = await lighthouse.removeKey(keyResponse.data.ipnsName, apiKey); console.log(removeRes.data); This step enables you to remove an IPNS key if necessary. Conclusion: Lighthouse IPNS is a powerful mechanism for publishing and updating content on the IPFS network. By combining the benefits of content-addressing with the flexibility of mutable pointers, IPNS ensures your content remains accessible and updatable. In this guide, we covered two methods to utilize Lighthouse IPNS: the CLI and Node.js. Armed with this knowledge, you can confidently publish and manage IPNS records, creating a more dynamic and user-friendly experience on the decentralized web. Remember to keep your API key secure and use it responsibly. Happy publishing!

5 min readarrow_forward
Getting Started with Lighthouse Python SDK
Articlecalendar_todayJul 31, 2023

Getting Started with Lighthouse Python SDK

Introduction Welcome to the beginner's tutorial on using the Lighthouse Python SDK for perpetual and decentralized file storage. Lighthouse is a cutting-edge file storage protocol that revolutionizes the traditional rent-based cost model of cloud storage by enabling users to pay once for their files and store them forever. With the integration of IPFS, Filecoin, and smart contracts on various blockchain networks, Lighthouse ensures data permanence, enhanced security, and cost-efficiency. This tutorial will guide you through the essential steps of leveraging the Lighthouse Python SDK to manage files perpetually on the decentralized network. Why Lighthouse Python SDK? Traditional file storage models require users to periodically renew their storage subscription, leading to recurring costs and management efforts. Lighthouse Python SDK eliminates these hassles by offering a perpetual storage model, where users pay once and store files indefinitely. This innovative approach utilizes the robustness of IPFS and the storage capacity of Filecoin's miner network, guaranteeing file permanence and redundancy. Let's dive into the Lighthouse Python SDK to harness the power of perpetual decentralized file storage. Prerequisites Before starting with the Lighthouse Python SDK, ensure you have the following: 1. Basic knowledge of Python programming. 2. Python installed on your computer. 3. A Lighthouse API token. If you haven't obtained one yet, sign up on the Lighthouse website to get your API token. Step 0: Getting your lighthouse API key Files-Lighthouse-storage: 1. Go on https://files.lighthouse.storage/ and Click on Login !Untitled (2).png 2. Select any of the login method and perform verification steps !Untitled (3).png 3. Click on API Key on the left side panel on the dashboard. !Untitled.png 4. Insert name for your API !Untitled (1).png 5. Copy the API Key !Untitled design.png Step 1: Install the Lighthouse Python SDK Begin by installing the Lighthouse Python SDK via pip, allowing you to interact with the Lighthouse protocol seamlessly: bash pip install lighthouseweb3 Step 2: Import the Lighthouse Python SDK and Initialize After installing the SDK, import the required libraries and initialize the Lighthouse client with your API token: python import io from lighthouseweb3 import Lighthouse Replace "YOURAPITOKEN" with your actual Lighthouse API token lh = Lighthouse(token="YOURAPITOKEN") Step 3: Upload a File Next, let's upload a file to Lighthouse. We can use the upload function for this purpose. We'll demonstrate both regular file upload and file upload with tags: python Regular file upload sourcefilepath = "./path/to/your/file/or/directory" upload = lh.upload(source=sourcefilepath) print("Regular File Upload Successful!") File upload with tags taggedsourcefilepath = "./path/to/your/file/or/directory" tag = "yourtagname" uploadwithtag = lh.upload(source=taggedsourcefilepath, tag=tag) print("File Upload with Tag Successful!") Step 4: Get Upload Information After uploading a file, you might want to retrieve its information, such as the Content Identifier (CID). We can use the getUploads function for this purpose: python Replace "YOURCIDTOCHECK" with the actual CID you want to check filecidtocheck = "YOURCIDTOCHECK" listuploads = lh.getUploads(filecidtocheck) print("Upload Information:") print(listuploads) Step 5: Download a File Now, let's download a file from Lighthouse using its CID. We'll use the download function to achieve this: python Replace "YOURCIDTODOWNLOAD" with the actual CID of the file you want to download filecid = "YOURCIDTODOWNLOAD" destinationpath = "./downloadedfile.txt" fileinfo = lh.download(filecid) The fileinfo is a tuple containing the file content and its metadata filecontent = fileinfo[0] Save the downloaded file to the destination path with open(destinationpath, 'wb') as destinationfile: destinationfile.write(filecontent) The file has been successfully downloaded and saved to the destinationpath print("Download successful!") Step 6: Check Deal Status Lighthouse allows you to check the status of a file's deal on the network. This can be useful to ensure that the file is accessible and replicated. Use the getDealStatus function to check the deal status: python Replace "YOURCIDTOCHECKSTATUS" with the actual CID whose deal status you want to check filecidtocheckstatus = "YOURCIDTOCHECKSTATUS" dealstatus = lh.getDealStatus(filecidtocheckstatus) print("Deal Status:") print(dealstatus) Step 7: Download Files by Tag If you've tagged your files during the upload, you can easily retrieve them by tag using the getTagged function: python Replace "YOURTAGTODOWNLOAD" with the actual tag name you want to download files for tagtodownload = "YOURTAGTODOWNLOAD" downloadedfileswithtag = lh.getTagged(tagtodownload) print("Files Downloaded with Tag:") print(downloadedfileswithtag) Conclusion Congratulations! You have successfully learned how to interact with the Lighthouse API for file upload, download, tagging, and checking deal status. You can now integrate Lighthouse into your own applications to manage files securely and efficiently. Keep exploring the Lighthouse documentation to discover more features and functionalities offered by the platform. Remember to handle exceptions appropriately in your applications, and make sure to secure your API token to protect your data on the Lighthouse platform. Happy coding!

5 min readarrow_forward
Creating a Pay-to-View Model Using Lighthouse Storage
Articlecalendar_todayMar 13, 2023

Creating a Pay-to-View Model Using Lighthouse Storage

As the world is advancing towards a more decentralized web infrastructure, storage solutions such as Lighthouse Storage are becoming increasingly popular. Lighthouse Storage is a Web3 Storage Solution that allows users to store their files perpetually on Web3 using Filecoin. Lighthouse Storage can be utilized for creating a pay-to-view model, using custom contracts and NFT-based access control. !Twitter post - 16 (1).png The concept of pay-to-view is not new, but with the rise of blockchain technology, it has become more feasible and secure. With Lighthouse Storage, users can upload their files with encryption, and apply access conditions to them. These access conditions can be defined using NFTs, custom contracts, time-based, or native token-based conditions. In this example, we will consider NFT-based access control. Step 1: Upload the encrypted file to the Lighthouse IPFS node. Users can choose to upload their files either using NodeJS Encryption Upload or ReactJS Browser Encryption Upload code example. Once the file is uploaded, Lighthouse node returns an IPFS CID/Hash for the encrypted file. Step 2: Apply access control to the encrypted file. Let's consider the example of NFT-based access control. The file owner can specify that only users who own NFTs from a particular collection can access the file. To do this, the owner needs to apply the access condition to the encrypted file. After applying the access condition, only the user who owns NFTs from that particular collection can access the file. Step 3: Once the access conditions have been defined, the Lighthouse view URL can be used to view the encrypted file, or the user can build a custom decryption view page using the provided code example. The user who has access to the file can pay using NFT or custom contracts. If the NFT is made a soul-bound token (SBT), the owner will not be able to transfer it to any other address, ensuring that the access is limited to the intended user.

5 min readarrow_forward
Decentralized storage for the Ocean Protocol
Articlecalendar_todayMar 2, 2023

Decentralized storage for the Ocean Protocol

Introduction Lighthouse is now bringing decentralized storage to the entire Ocean Protocol Ecosystem. Using Lighthouse — Ocean data publishers, marketplaces, and dapps will now have access to storing data on the Filecoin network leading to net positive value generation due to the low storage cost across thousands of active miners in the filecoin economy. Ocean Protocol for the new data economy !17HiWEKsVLrh1ezHR8Wer5w.webp Data is the essential resource of modern times and is the new oil. However, unlike oil, which burns and exhausts, data sharing and usage lead to more innovation and a better digital society. Blockchain technology has enabled a new data economy which is Ocean Protocol. Ocean Protocol bridges the gap between data supply and demand, allowing data availability for the researchers and providing a fair share of revenue to the data owners. Especially in the current market scenario, we have seen companies exert tight control over data and not let anybody outside access it. Hence, this led to closed-source ChatGPT models at OpenAI and the recent acquisition of GitHub by Microsoft, leading to AI models being controlled and developed by just a few, due to restricted access to data. Lighthouse — perpetual storage on Filecoin !1X-d6MBzNHB0kOMsDdeptpQ.webp Lighthouse is a perpetual storage protocol built on Filecoin that allows storing your data long-term with a one-time fee. In addition, Lighthouse Storage provides encryption and access control functionality to store private data and create token-gated access to resources. Along with fast gateways to stream 4k videos through its IPFS Gateways, Lighthouse Storage is the feature-rich way to use IPFS and Filecoin. Decentralized Backend Storage Ocean Protocol provides the ability to share data through its app-level interface, like ocean marketplaces and middleware, to compute over data using a privacy-preserving method, i.e., using data without it leaving the premise of the data owners. Data owners can also keep data with a trustful entity like Ocean Protocol Foundation — a non-profit organization. Given the presence of web3 storage systems like Filecoin, there is a demand from the Ocean Protocol ecosystem to store data there. Hence, with the support of the Ocean Protocol team, Lighthouse Storage is chosen for the integration from the Ocean Economy to Filecoin via the Decentralized Backend Storage (DBS) created by the Ocean Protocol team. This backend (DBS) provides the following functionality - allow users to upload content - handle payments - push the content to decentralized storage using Lighthouse Storage - return the storage object to be used in the DDO - Hence, the aim is to improve UX for the data publishers on the Ocean Protocol and provide them with ways to store their data on a decentralized network. !1VrGLhETjXZUsAHLKm1ZCQ.webp Filecoin microservice by Lighthouse Storage registers itself to DBS, using the Register endpoint every 10 minutes per the DBS Spec. The microservice exposes the following API Endpoints: - GetQuote — Gets a quote to store some files - Upload — Upload some files - GetStatus — Gets status for a job - GetLink — Gets DDO files object for a job Summary Lighthouse Storage is now integrated into the Ocean Protocol, which has led to an important piece being attached to the data economy puzzle. The Lighthouse team will continue supporting the Ocean dapps, data publishers, and marketplaces to store data on web3.

5 min readarrow_forward
How To Migrate Your Files To Lighthouse
Articlecalendar_todayMar 2, 2023

How To Migrate Your Files To Lighthouse

Lighthouse is a decentralized storage protocol that utilizes the power of Filecoin and IPFS to provide perpetual storage for your files. Unlike traditional storage solutions, Lighthouse offers a number of advantages, including encryption and access control, as well as cost savings over alternatives. !image2.png Migrating files to Lighthouse is a relatively straightforward process, allowing you to migrate your files from any IPFS node which is on a public network, and it can be done using the CID (Content Identifier) of the files you wish to move. In this article, we will walk you through the steps of migrating both a single CID and multiple CIDs to Lighthouse. Steps for Migrating Using CID: - Copy the CID of the file you want to migrate from your current storage provider. - Go to https://files.lighthouse.storage/ and log in to the Lighthouse Files Dapp. - Go to the Migration tab on the left side of the page. - Click on the "Create Migration" button and paste the CID into the field provided. Press the spacebar, and then press the "Migrate CID" button. - Wait for the CID to migrate. You can check the status of the migration in the "Status" column. NOTE: You can also Upload a CSV File containing a list of all the CID separated by a comma It's important to note that migrating your files to Lighthouse can take some time, depending on peer discoverability in the IPFS network, the size of your data, and the speed of your internet connection. However, once the migration is complete, you just created another replication of your file on the IPFS Network, also a Filecoin deal will get created for the migrated file by Lighthouse. In conclusion, migrating your data to Lighthouse is a great way to ensure that your files are stored securely. Lighthouse is also cheaper than alternatives and provides perpetual storage. With its easy-to-use platform and simple process, you can migrate your files to Lighthouse with ease.

5 min readarrow_forward
Encryption and Access Control for Web3 using Lighthouse
Articlecalendar_todayJul 27, 2022

Encryption and Access Control for Web3 using Lighthouse

Lighthouse is a permanent file storage protocol that allows the ability of perpetual storage for your files. Using Lighthouse you can store your files forever on a distributed web. Lighthouse aims to be the best entrypoint to your files on filecoin network, abstracting away all complexities and with added functionality of permanent and long term storage. Private Data !encryption2.jpg Till now, most of the data stored on Filecoin and IPFS network is public that can be accessed by anyone. Hence, you can’t store files directly on a public network that are sensitive like personal photos, patient data, enterprise data, etc. This leads to developers and users hanging on to build their own encryption layer to store data on storage networks and can often lead to bad practices and over burden of access and key management. This also further leads to centralised key management for files or bad user experience to manage your own keys for files. Not to say, the trouble caused by sharing the files to authorised parties is even more problematic. That’s why we at Lighthouse choose to build an encryption layer and access control for users to store private and sensitive data on filecoin. Using this functionality, developers need not worry about creating their own encryption layer for users and managing keys via unhealthy practices. How it works Lighthouse Encryption and Access Control uses BLS threshold cryptography to ensure that any file’s decrypt key and data stays consistent and is resistant to faults and attacks. Threshold cryptography ensures that even when some parties or nodes in a system are compromised the system architecture is robust enough to keep serving users and also ensuring the data secrecy. Furthermore, Lighthouse at no point in time receives or collects decrypt keys of any file or documents. All decrypt keys are randomly generated and fragmented from the user’s end. After which, the shards are encrypted and stored on nodes alongside user defined access conditions. Retrieving keys has never been easier, our architecture only required the user to sign a randomly generated message, specify the CID of the file or document to be retrieved. After which each node validates the request and access condition independently and sends a copy of the key shards they have in their possession if the access condition(s) are valid which is then aggregated on the user’s end to decrypt the file or document Use Cases This new functionality will enable variety of use cases for applications to store their private and encrypted data on Lighthouse, some of which are listed below - - Encrypted backup of files on Filecoin - Storing personal photos on dweb - Token gated applications - DAOs can store data generated by members - DataDAOs building collectives of data - Restrict access to files by owners of a NFT collection - Sensitive data like patient data can be stored - Enterprises can store their data on a distributed web for lower cost - Recordings for web3 meetings - Private code repositories storage Get Started Checkout these Code Examples Fill in this Form to get free early access and get in touch with our team to receive custom support. Stay in Touch To learn more about Lighthouse, visit the official website, read through the documentation or jump in on Github. You can also join the community on Discord, Twitter, Telegram, or LinkedIn.

5 min readarrow_forward
icon

mail@lighthouse.storage

Sitemap

Memory

Storage

Use cases

FAQ's

Blogs

Documentation

Help

Contact us

Explorer

Report Online Abuse

Talk to Expert

T&C

Newsletter

© Copyright 2026, All Rights Reserved by Lighthouse Storage