IoT blockchain integration:
How Centaur tested a shared history for crop sensor data
A proof of concept that wired Centaur's platform into a permissioned ledger, then tested whether the record it produced held up to inspection.
Centaur Analytics monitors stored crops through its Internet-of-Crops® platform, and all of those readings sat inside one company's cloud. Buyers further down the chain could only trust them. Aetsoft built a proof of concept on Hyperledger Sawtooth: a transaction processor for readings, a REST link into Centaur's platform, and a web client for viewing ledger records. The team also designed an encryption-key model for controlling access in a production version.
001
ClientCentaur Analytics, Inc. Post-harvest quality monitoring for stored crops and food.
002
ChallengeSensor data lived in one cloud. Buyers could read it only by trusting its owner.
003
SolutionA permissioned Sawtooth ledger for measurements, wired into the platform that already ran.
004
EngagementProof of concept, three milestones, 2 to 5 Aetsoft engineers.
Engagement lead
Pavel Sivayeu
CTO, Aetsoft Inc
Pavel wrote the design note behind this build and ran delivery
Engagement lead
Artem Kirylin
Commercial Director, Aetsoft Inc
Commercial lead, product consulting for supply chain and IoT
Six owners between the field and the shelf
Centaur's sensors sit inside silos, warehouses and shipping containers. They read gas, temperature and humidity, and some photograph the stored product. The platform adds weather data and calculated values on top, including moisture content, dry matter loss and mould risk.
Now follow a load of wheat. It leaves the farm for a logistics company, then a miller, then the mill's own transport, then a food factory, then a supermarket, then whoever eats it. Six handovers. At each one the receiving party wants a reason to believe the quality claim attached to the lot.
Picture a whisky distiller buying barley to a specification. The distiller cares about infestation, mould and mycotoxin risk during storage. Centaur's sensors had recorded the storage conditions and its models had calculated the associated risks. Reading any of it meant querying a database owned by the seller's own technology supplier.
Picture a whisky distiller buying barley to a specification. The distiller cares about infestation, mould and mycotoxin risk during storage. Centaur's sensors had recorded the storage conditions and its models had calculated the associated risks. Reading any of it meant querying a database owned by the seller's own technology supplier.
The quickest fix was to hand buyers a login, with a read-only view of whatever concerned their lot
That solves the wrong half of the problem. A database can show historical values and audit logs perfectly well. The party running it still controls both. So the distiller would be trusting the same company twice, once for the measurement and once for the record of what changed.
So the requirement was a history that would show whether anything had been changed after the fact.
We opened with questions, not a proposal
Aetsoft opened with a short architecture sketch and twelve questions attached to it. Some were technical. Most were commercial. Who actually needs to see this data. Do your customers want their own copy of the ledger. Is querying required, or is export enough.
One question changed the shape of the build. How many measurements per second does the platform handle, now and in a few years. The answer was roughly one per second, with a ceiling near a hundred later. That number removed a whole category of work before anyone wrote code.
Most of the requirements were still unresolved, including the ones most likely to derail a fixed-price build. Our blockchain consulting work starts by turning those open questions into a viable delivery path.
What we built
Choosing a ledger that could hold a sensor reading
For the 2019 proof of concept, Aetsoft chose Hyperledger Sawtooth, a permissioned enterprise blockchain originally contributed by Intel.
Sawtooth let a transaction carry arbitrary data, which suits a sensor payload, and it shipped a REST interface out of the box. Three nodes made a working network.
One choice came with a cost. PoET-SGX, the consensus mode chosen here, leans on a security feature built into Intel processors. So the build ran on Linux machines with SGX-capable CPUs. Virtual machines would also have worked, and we said at the time that they weaken the guarantee. For a proof of concept that was a fair trade.
Sawtooth was archived by Hyperledger in February 2024 and is now maintained in the Splinter community. The reasoning behind the 2019 decision still stands. The platform would be a different one today.
Proof by agreement
The transaction processor and the delivery record
Every sensor reading became a transaction. Aetsoft wrote the Sawtooth transaction processor, the application logic that validated each of those transactions and updated ledger state. It runs alongside the validator, which is where Sawtooth departs from an Ethereum-style chain. The logic still demanded the discipline of smart contract development. Execution has to be deterministic, and every edge case has to be handled explicitly.
Underneath sits a second store, holding one object per delivery with its measurements attached. Sawtooth keeps two things at once: the chain of accepted transactions, and a current picture of each delivery built from them.
Wiring it into a platform that already worked
Centaur already ran RabbitMQ and a REST API, so Aetsoft offered a queue connector or a REST endpoint and let the client pick. REST won, because it changed the least. Centaur added the sample calls where measurements were already being written, and the sensors were untouched.
A screen a buyer could read
One delivery at a time appears in the web client: device, reading type, value, time. It runs beside Centaur's own dashboard, so anyone can watch a reading appear in both places. That demo was the point. Trust here is built by watching the new system agree with the one you already believe.
Everything above reached code. This part reached the architecture note and stopped there. Worth saying plainly, because access control was the harder half of the problem, and a proof of concept is allowed to leave the harder half on paper.
Each delivery object was to carry a set of participant keys alongside its measurements and documents. Sensitive values are encrypted under a shared key. That key is then wrapped again with the public key of every participant in the delivery. A logistics operator would open the deliveries it carried and those only.
Commercial pressure drove the whole scheme. Quality data reveals who bought what, at what grade, from whom. Centaur confirmed early that auditors and finance providers would need access too, so openness and confidentiality had to live inside the same record. Specifying that took longer than sizing the network.
The four decisions
that shaped the build
-
Decision
Ledger platform
-
What we chose
Hyperledger Sawtooth, permissioned
-
What we gave up
A public chain, which brings its own confidentiality work and governance overhead
01/03
-
Decision
Consensus
-
What we chose
PoET-SGX, three nodes
-
What we gave up
Hardware independence, since the guarantee ties to Intel processors
02/03
-
Decision
Integration path
-
What we chose
REST endpoint into the existing pipeline
-
What we gave up
A RabbitMQ connector, which read more data at the cost of more change
03/03
-
Decision
Replication
-
What we chose
Three validators, all on Centaur's infrastructure
-
What we gave up
Independent verification, which needs counterparties running nodes of their own
Parameter reference
Three validator nodes on Centaur infrastructure, PoET-SGX consensus, Linux hosts with SGX-capable CPUs and 8 GB of RAM. Transaction payload: asset, asset name, timestamp, reading type, value, sensor, device, user, measurement identifier. State object: one per delivery. Access design: two-layer key wrapping, one shared key per record, participant public keys above it. Load: Centaur estimated roughly one transaction per second across about 2,000 sensors.
Results
“Aetsoft had specialized knowledge in an evolving software domain and a great business acumen.”
Sotiris Bantas 
CEO, Centaur Analytics. Verified Clutch review.
Aetsoft delivered the prototype inside the agreed timeframe, across three agreed milestones. An authorised user could publish a reading through the integration API and then inspect the resulting ledger record in the prototype client. Performance was measured by how long a reading took to land.
Prototype produced a tamper-evident history. Independent verification needs nodes held by separate parties, and that stayed a production question.
Frequently asked questions about blockchain IoT integration
-
Does putting sensor data on a blockchain make the data accurate?
A ledger protects the record from the moment the reading arrives. Accuracy before that point comes from the sensor and its placement. Anyone selling a ledger as a fix for bad measurement is selling the wrong thing.
-
How much throughput does a traceability ledger need?
Far less than most teams assume. Centaur estimated its own load at roughly one transaction per second across about 2,000 sensors. Confidentiality and integration create most of the design pressure.
-
Can an auditor see one delivery and only that one?
That was the job of the access model in the production design. Each record sits behind two layers of encryption, keyed so that an auditor opens the delivery in question while the rest stay closed. The prototype stopped before this reached code.
Since 2019, blockchain development for supply chains, IoT platforms and regulated finance has followed the same shape at Aetsoft. Interesting engineering sits in access control and integration. The volume question comes in smaller than everyone expected.
