What Belongs on the Chain, and What Stays on the NAS?

When people hear that Foldinglink is exploring a blockchain layer, a fair question follows:

Are we planning to put every photo, video, and file on a blockchain?

No. That would make a social product harder to use, harder to scale, and more expensive to operate. The more useful question is how to give two different jobs to two different layers:

The NAS stores the practical content: photos, videos, files, local copies, and download tasks.
The blockchain layer could hold shared records: identity, permissions, transaction state, contribution, and selected community decisions.

This separation is the current architectural direction we are studying for Foldinglink. It is not a live public chain, a token launch, or a promise of financial returns.

The short answer: two jobs, not one

A NAS is good at keeping real files available to a person or a community. It gives the file a physical home and lets the owner manage it.

A blockchain is good at maintaining a shared record of state changes. In simple terms, it can help different participants agree on what was authorized, what happened, and which rule was applied, without relying on one private database as the only source of truth.

That does not make a blockchain a better hard drive. Ethereum's own documentation says the network was not designed for large amounts of data: every node would need to store the growing chain, and putting large files directly on mainnet would be prohibitively expensive. The common pattern is to keep the large data elsewhere and use a hash or reference when a shared integrity check is needed. Ethereum: Decentralized Storage

What stays on the NAS?

The NAS is the content side of the experience. In the Foldinglink whitepaper, personal NAS devices are intended to be the physical foundation for content storage and peer-to-peer distribution.

For a user, that could mean:

uploading a video, design file, tutorial, or other digital resource;
keeping the original file under the creator's control;
seeing where a download task is stored and whether it is still moving;
resuming a transfer after a network interruption;
sharing content from a personal node instead of first handing the original file to a platform-controlled storage bucket.

The current development record reflects this practical side. The team has connected NAS download task data to the client, including task status, progress, and storage path. The data model now normalizes total bytes and completed bytes so that progress can be calculated consistently. The repository layer also has compatibility and exception handling for different response structures.

Those pieces do not prove that every future file transfer will work under every network condition. They are the foundation for testing a clearer user experience around files: what is downloading, where it is going, and what happens when the connection does not behave.

What could belong on the chain?

The chain is being considered for information that several parties may need to recognize in the same way. The current whitepaper direction includes:

Identity and authorization: which account or wallet authorized an action.
Content reference: a hash or content identifier that helps check whether the referenced content has changed.
Transaction state: whether an exchange is pending, completed, disputed, or otherwise needs attention.
Escrow and settlement rules: what should happen to a community transaction when both sides meet the agreed conditions.
Contribution and governance records: which community action was recognized and which decision or rule was applied.

These are design targets, not a list of features that are already live.

When the whitepaper uses the term CID, it is describing a content identifier based on the content itself. IPFS documentation explains that a CID identifies content rather than a particular storage location; if the content changes, its CID changes too. IPFS: Content Identifiers

That distinction matters. A CID can help a user or application check what a reference points to, but it does not by itself guarantee that a file will always be online. Availability still depends on the nodes, copies, retention rules, and recovery paths around the file.

A simple example: exchanging a resource

Imagine that a creator publishes a paid design resource from a personal NAS node.

The user experience we are working toward is easier to describe than the underlying protocol:

The creator selects a file and publishes its description, terms, and price.
The file remains in the creator's storage path, while the application makes the resource discoverable.
A buyer starts an exchange and can see a clear transaction state instead of guessing whether the action went through.
The resource is delivered from the creator's node or an approved storage path.
The system records the relevant state change, such as delivery confirmation or a dispute that needs review.

The file and the record are related, but they are not the same object. The file is the thing the user wants. The record is the shared context that helps both sides understand what was authorized and what happened.

If a disagreement occurs, the whitepaper's longer-term direction includes community dispute handling through a jury or collective process. That governance workflow is not being presented as complete. It is one of the areas that needs careful product and economic design before it can be tested honestly.

Why a NAS changes the architecture question

Many blockchain discussions start with a chain and then ask where the content might go. Foldinglink starts from the opposite end: real users already have files, storage devices, and communities that need a way to exchange information.

The NAS gives the network a physical foundation. It can store content, maintain a local path, and participate in peer-to-peer delivery. But a NAS alone cannot answer every shared social question. It cannot, by itself, tell every participant whether a transaction was authorized, whether a contribution should count, or which community decision should be treated as final.

That is why the blockchain architecture matters. The goal is not to decorate a NAS product with technical language. The goal is to explore whether a shared record can make participation, exchange, and community rules easier to understand and harder for one party to rewrite silently.

There is a wider research basis for treating these as separate responsibilities. Cao and colleagues' 2024 paper proposes combining blockchain, decentralized storage, and access-control smart contracts for decentralized social networks. It is an architecture proposal, not proof that the problem is solved, and its use of trusted nodes is an important limitation to keep in view. Still, it asks the same practical question Foldinglink is asking: which job belongs to storage, which belongs to permissions, and which needs a shared record? Cao et al., Architecture for Protecting Data Privacy in Decentralized Social Networks

What the team has done so far

The current development record separates confirmed work from exploration:

Confirmed or underway:

OP Stack research has been completed for the current exploration phase.
An Ethereum Sepolia testnet node has been set up for experimentation.
Initial OP Stack environment preparation is in progress, including required software, compiled binaries, and configuration work.
Transaction foundations include order flow, the TradeEscrow contract foundation, chain interaction, signature checks, and transaction storage work.
NAS download tasks now have client-side mapping for status, progress, and storage path.

Still being explored or tested:

the final chain architecture and deployment boundary;
which records should be shared, and which should remain local;
how application state and chain state stay consistent;
sequencer and multi-node choices for a later stage;
how points, contribution records, governance, and any future token relationship should work.

OP Stack documentation describes a modular set of components for building Ethereum Layer 2 ecosystems. That makes it a useful route to investigate, not a conclusion that Foldinglink has already built a production L2. Optimism: OP Stack Components

The current record does not include measured latency, cost, throughput, concurrency, failure rate, or recovery time. We will add those numbers only after the relevant tests exist.

What we need to test next

The next useful milestone is not a grand claim. It is a controlled end-to-end test:

Can the application show a transaction state that matches the shared record?
Can the user tell whether a file is missing, still downloading, or successfully stored?
Can the system distinguish a content reference from the storage location that currently serves it?
What happens when a NAS goes offline during delivery?
Which parts of identity, permission, contribution, and governance actually need shared verification?
What are the measured costs and delays of each step?

The industry is already experimenting with layered architectures. Reporting on Ethereum's Dencun upgrade, Axios described rollups executing away from the main chain while using Ethereum for settlement-related data handling. That is useful context for why applications separate execution, settlement, and storage concerns, but it does not choose Foldinglink's architecture for us. Axios: Ethereum's Dencun upgrade rolls out a new type of transaction

The question for the community

If Foldinglink is building a blockchain layer on top of a NAS-based network, which information should be publicly verifiable first?

Who authorized a post, resource, or transaction
Whether a file or resource was delivered as promised
Whether a content reference still matches the original file
How a dispute or community decision was resolved

There is no public chain or token launch behind this post. We are working through the architecture one real user question at a time.