From a live network that was hard to manage to a platform the client can sustain — without taking it offline.

The situation

Fry Networks is a US company that provides devices to collect environmental data: weather, water, air, and more. The devices are connected in a decentralized network. The people who operate the devices are called miners; they provide the data, and the network rewards them with Fry tokens. Devices are sold through a Wix-based e-commerce store, and miners work on the Algorand blockchain. It is a DePIN project — a decentralized physical infrastructure network.

A network like that runs on three layers that have to agree with each other. Hardware, because the devices in the field are the whole point. Data, because what the devices collect is what the network is actually worth. Rewards, because miners keep their devices running only if they are paid fairly, on-chain. Each layer has its own rules, its own failure modes, and its own idea of what "working" means.

When Fry came to us, all three layers were already in place. Devices were shipping. Miners were providing data. Some of the underlying systems worked. The problem was running it. The network had grown faster than the tools to manage it, and Fry needed a real workflow in place while the main project kept running every day.

Miners were relying on the network for their rewards. A pause-and-rebuild was not an option.

What Discovery found

This engagement did not start with our standard two-week Discovery. Fry came to us with a live network that had to keep running, so discovery happened inside the work: we joined Fry's team and found the problems alongside them, one system at a time. Four findings mattered:

1. This was a rebuild, not a blank page. Devices, miners, and some working systems already existed, and Fry had already invested in them. The job was to rebuild what was there into something manageable — not to replace the network and ask miners to start over.
2. Management was the weak point. A DePIN network only works if someone can see what is going on: which miners are active, what data is coming in, and what each miner is owed. That was the layer Fry still could not see clearly.
3. The data had to be right before the rewards could be. Miners are paid for what they provide, so the reward system is only as good as the data behind it. Data collection came first.
4. The token belonged with Fry. Fry manages its own token. We would build the systems around it. The token itself would stay with them.

Discovery output: a working method for running the network, agreed with Fry's team and refined over the year as we found and fixed each problem. No cutover weekend. No downtime notice to miners. We rebuilt each piece while the rest of the network carried on.

What we built

Data and miners

• Data collection management. How environmental readings from the devices enter the network and how they are managed once they arrive.
• Miner management. The tools Fry uses to run the network's mining side.
• Miner dashboard. A view for miners into their own side of the network.

Rewards and governance

• Reward system. How miners earn Fry tokens for the data they provide.
• Voting system. On-chain voting for the network.

Token tooling

• Token creator. Tooling for creating tokens on the network.

Alongside these, we did the supporting work a live network needs to run day to day.

What happened over the year

The network kept running while we rebuilt it. By the end of the year, the on-chain systems worked correctly, the data from miners was accurate and useful, and Fry had a platform it could sustain instead of one it struggled to manage.

What we did not do

• We did not manage the token. Fry Networks manages its own token. We built the systems around it. We drew that line at the start, in plain terms.
• We did not take the network offline. Miners depended on it for their rewards. Every part we rebuilt, we rebuilt while the network kept running.
• We did not replace what Fry had already built. The devices, the store and the systems that worked stayed. We rebuilt the parts that made the network hard to run.
• We did not work as an outside vendor delivering a sealed box. Our team worked inside Fry's for the length of the engagement, and the systems belong to Fry.
• We did not publish numbers we do not have. There are no miner counts, device counts, or reward volumes here, because we did not measure them for this case study.

Numbers we can share

Numbers we do not have yet: miner and device counts, data volumes, reward or token volumes, and uptime. Not published: contract value and team size.

The pattern this case study represents

DePIN networks that outgrow their systems usually go wrong in one of three ways: the hardware sells before the management layer exists, so the network grows faster than anyone can run it; the rewards get built before the data is trustworthy, so the network pays for readings nobody has checked; or someone decides the fix is to start over, and asks miners to wait while the network goes dark.

The right shape is usually the opposite of starting over. Keep what works. Fix the data first. Rebuild the management layer around the network that already exists, from inside the team that runs it.

Fry's engagement worked because the network never had to stop for us to fix it.