Inspiration
I had originally planned to make a location based signing service. It will only accept a signature if the device generating the signature is at particular location. I had thought of implementing it using the GPS to gather the location and submitting it via a signed transaction. But I quickly found the pitfalls of my approach. There are countless ways to fool the GPS. One of them being the Android Developer Mode. Therefore I switched my project to solve the original problem of getting trustworthy location data.
What it does
My project introduces a new Pallet proof-of-location which helps in determining the trustworthiness of a location claim using the help of neighboring nodes. It does not require an Oracle to function correctly. In other words, it implements Decentralized Proof of Location.
Steps
At the start, every node will publish their location and their Bluetooth MAC address on chain.
All the nodes will start a Bluetooth Low Energy Advertisement of a particular service ID so that the neighboring nodes can receive the Advertisement. The nodes can therefore measure the RSSI (Relative Signal Strength Index) of the incoming Advertisement and publish this information on chain.
Since all the location data is public, all inter-node distances are also public. There is a direct relationship between distance and RSSI using the well known Two-Rays Ground-Reflection Path Loss model. We can calculate the expected RSSI for all inter-node distances.
$$ RSSI = RSSI_{ref} + n \times 10.0 \times \log_{10}(d) $$
$$ n = 4.0 $$
For a particular Node A, the neighboring nodes will measure A's RSSI and publish on chain. This value can be subtracted from the expected RSSI to get the error. Each neighbor will provide 1 error value. Therefore, a node will be associated with as many errors as there are neighbors around.
Finally, if the neighbors are greater than 3 then Trimmed Median of the errors of Node A will give the final trust score of Node A. Trimmed Median is the median of 3/4th of the lowest values.
Why Trimmed Median?
Let's say we have 5 nodes: Alice, Bob, Charlie, Dave and Eve. If Alice tries to lie about its location, everyone will report high error for Alice. But Alice will also report high error values for all other nodes. When calculating the error for other nodes, we should skip this high value but not all values. Therefore trimming the highest 1/4th part was introduced.
Why Greater than 3?
Because 3 distances from 3 known points is enough to be able to correctly pinpoint an accurate location on Earth. This is why GPS requires 3 satellites to be above us at all times. I have mandated greater than 3 (not equal to 3) to account for 1 misbehaving node.
Why Bluetooth?
This is a hackathon project demonstrating the concept of decentralized proof of location. In practical implementation, technologies like LoRa or ZigBee is more applicable. I have used Bluetooth here for ease of prototyping with common hardware.
How we built it
The project is built on the Polkadot SDK (formerly Substrate) using the FRAME framework to create a custom blockchain pallet. Here's the technical stack and architecture:
Core Technologies:
- Substrate/FRAME: For the blockchain runtime and consensus (Aura + GRANDPA)
- Rust: All components written in Rust for performance and safety
- BlueZ: Linux Bluetooth stack for RSSI measurements
- Subxt: For communicating between off-chain servers and the blockchain
- Axum: HTTP server framework for the data collection endpoints
- egui: Immediate-mode GUI library for the real-time monitoring dashboard
Architecture Components:
Custom Pallet (
pallet-proof-of-location): The heart of the system that stores node registrations, RSSI data, and provides runtime APIs for trust score calculation. It uses on-chain storage for location and RSSI data while computing trust scores on-demand via RPC.Offchain Worker Integration: Each blockchain node runs an offchain worker that automatically fetches location and RSSI data from the local HTTP server every block. This bridges the gap between hardware sensors and blockchain state.
Bluetooth Server (
server): A Rust application that runs on each device to:- Continuously advertise a BLE service UUID
- Scan for neighbor advertisements
- Measure RSSI values and store them in memory
- Expose HTTP endpoints (
/locationand/rssi) using SCALE codec encoding - Automatically discover neighbors from blockchain state using Subxt
Simulator (
simulator): A web-based testing environment that simulates 5 nodes with realistic RSSI calculations based on the log-distance path loss model, including Gaussian noise distribution. This allowed rapid iteration without physical hardware.Trust Score RPC: Custom JSON-RPC methods that compute trust scores by comparing measured RSSI against expected values derived from GPS distances. Uses trimmed median to handle outliers.
Monitor Dashboard (
monitor): Real-time visualization tool that polls the trust score RPC endpoint and displays error values as bar charts using egui's plotting capabilities.
Development Workflow:
- Used Zombienet to spawn a 5-node local testnet
- Docker-based development container to handle complex Substrate build dependencies
- Cross-compilation toolchain for ARM64 (Raspberry Pi) targets
- SCALE codec for efficient binary serialization between components
- Real-world calibration using collected RSSI measurements and Jupyter analysis
Challenges we ran into
The physical demo with 5 Raspberry Pi
The most challenging part of the project was the physical demo with 5 Raspberry Pi. Simply getting access to 5 Raspberry Pi in such a short time, would not have been possible without the help of my trusty friends. Cross compiling my project for the Aarch64 took some effort.
After getting my project to compile successfully, I tried the demo in my room only to get completely wrong readings. I had realized that a room is not a good site for the demo since the bluetooth signal can easily reflect from walls.
I moved the entire setup on the terrace (which was a challenge on its own) and did the final demo there. Even the RSSI readings inside the measurements folder were taken on the terrace too. All in all, it took about a week just for this demo.
Implementing Runtime API
When searching for examples of Runtime API, I found none of them. If the examples are present online, I can confidently say that it is ranked very low on Google's Search Engine.
Claude was able to take it most of the way to the finish line. But this was the only instance where I was not completely confident with AI generated code, since I could not find examples online to cross check what Claude had written.
Compiling the solochain template
I use Arch Linux as my main Desktop Operating System. It is known to have a rolling release model. Apparently, compiling the solochain template required compiling an older version of RocksDB which required an older version of LLVM. I did try to install an older version of LLVM, which resulted in crashing Hyprland (which was recovered using the Graphical TTY).
Eventually, I made a development container using docker and used VS Code Remote to attach to it. This entire project was built inside a docker container. It had slowed my pace down in the first few weeks before I got used to this kind of a setup.
Accomplishments that we're proud of
Successfully deployed a complete 5-node physical testnet on Raspberry Pis, proving the concept works with real hardware, not just simulation. This involved cross-compiling, Bluetooth configuration, environmental calibration, and coordinating multiple devices simultaneously.
Built a fully functional decentralized location verification system from first principles - combining GPS, Bluetooth RSSI physics (log-distance path loss model), statistical analysis (trimmed median), and blockchain consensus into a cohesive solution.
Implemented custom Runtime APIs and RPC methods - one of the more advanced Substrate patterns with sparse documentation. This enables efficient off-chain computation of trust scores while keeping the blockchain lean.
Created a realistic testing framework with the simulator that accurately models RSSI behavior including Gaussian noise, enabling rapid development without constant hardware access.
End-to-end integration of multiple complex systems: Bluetooth Low Energy scanning, offchain workers with HTTP fetching, SCALE codec serialization, real-time GUI visualization, and multi-node blockchain consensus.
Real-world calibration and validation - collected actual RSSI measurements at different distances and analyzed them in Jupyter to determine optimal reference RSSI and path loss exponent values, grounding the system in physical reality.
Designed a robust trust algorithm that resists both environmental noise (via trimmed median) and Sybil attacks (cross-validation between multiple neighbors).
What we learned
Substrate/FRAME Development:
- Substrate's architecture separates on-chain logic (storage, events, extrinsics) from off-chain computation (runtime APIs, RPC), which is crucial for scalability but requires careful design of the interface boundary.
- Offchain workers provide a powerful bridge between blockchain state and external data sources, but debugging them is challenging since logs are separate from the main node output.
- Runtime APIs must be carefully versioned and can significantly impact performance if they iterate over large storage maps.
Bluetooth RSSI Physics:
- RSSI measurements are highly environment-dependent. Indoor environments with walls cause multipath interference that breaks the log-distance path loss model. The terrace demo was necessary because rooms create reflections that corrupt distance estimation.
- Bluetooth signal strength varies by several dB even at the same distance due to antenna orientation, human body blocking, and radio interference.
- The relationship between RSSI and distance is logarithmic, not linear - doubling the distance doesn't halve the signal strength, which is why the log-distance model is essential.
Statistical Trust Scoring:
- Simple averaging is vulnerable to outliers - a single bad measurement can skew results.
- Trimmed median provides robustness against both environmental noise and adversarial behavior by removing extreme values before calculating the center.
- The trimming percentage (25%) is a tunable parameter that balances between noise tolerance and attack resistance.
Cross-Compilation and Deployment:
- Building for ARM64 on x86_64 requires careful management of system dependencies, especially for BlueZ which has native library bindings.
- Docker development containers solve the "works on my machine" problem but add complexity to the workflow. However, they're essential for projects with complex dependency chains like Substrate.
- Real hardware testing is irreplaceable - the simulator helped development velocity but couldn't reveal the environmental RSSI challenges discovered on physical devices.
What's next for PoLka.Blue
Location-based Signatures
It will enable smartphones (with Bluetooth) to request a location-based signature by paying a small fee to the node. A location-based signature will prove that the device was at a particular location at a particular time.
Tokenomics
The implementation of this project took long enough that I could not focus on the Tokenomics of this chain. Next, I will have to add a system to reward nodes that have less error. When other devices or smart contracts want to generate a proof of location for their device, they would need to pay with this token.
PoLka.LoRa
Currently, I have built this entire project using Bluetooth to measure the RSSI values. But the range of Bluetooth is only 10 metres. LoRa would have been an ideal candiate with a range of 10 km. I did not use LoRa since I did not the required hardware. The obvious next step would be to buy the required hardware and implement the server for LoRa.
Built With
- axum
- bluetooth
- bluez
- docker
- polkadot
- raspberry-pi
- rust
- shell
- substrate
- subxt
Log in or sign up for Devpost to join the conversation.