The Path Mobile App

Previously, we dove into how Path Network functions and touched a little bit on our mobile app. With our mobile app now running in the wild, we'd like to cover its capabilities and how they benefit those running the app and monitoring clients alike.

What is the Path Mobile app?

For those not in the know, the Path Mobile app allows anyone with a mobile phone to effortlessly earn PATH tokens throughout the day. Tokens are earned by completing non-resource-intensive networking tasks as the app runs discretely in the background.
The Path Mobile app for Android was recently released to the public via Google Play, so if you haven't already, you can check it out here!

So, how do I use it?

Usage of the app itself is so simple, it can be boiled down to three steps:

  1. Install and open the app.
  2. On the wallet tab, enter and save a valid ERC-20 wallet address to receive earned tokens. If you don't have a wallet address, we recommend using to generate one.
  3. Leave the app running to begin processing jobs on the Path Network!
Adding your wallet to the Path Mobile app.

Behind the scenes

The technology is advanced, but the concept is simple: individual nodes within the network will be assigned monitoring tasks (eg, checking to make sure a website is up and running). In exchange for these tasks, they will be rewarded with PATH tokens.
But what goes on behind the scenes? Our telemetry is really what makes Path Network shine, so let's take a peek at what's going on.
When a node is started, it will check in with our Operator API via a WebSocket connection to let us know it's online and ready to receive tasks. These simple check-ins alone already give us some insight into the health of an ISP; more specifically, where IPs are being assigned within an ASN, and whether connections to our servers are being routed properly.
Once the monitoring jobs start coming in, things can start to really get interesting. While the most common tasks performed are simple pings and HTTP queries, Path nodes are capable of so much more. For example, TCP and UDP connections may be defined with custom payloads within a monitoring task, allowing flexibility previously unseen. DNS queries and traceroutes may be performed to map out exactly where network connections are going.

Regardless of the monitoring task performed, all information will be transmitted back to Path's servers for analysis. Everything from the timestamp of a connection being opened to the very last bit of response data received will be processed to verify an endpoint is available and functioning as expected.

What does running monitoring jobs on mobile nodes mean for a client?

Based on the jobs given, we can answer a variety of questions about a given service.
For example, a basic DNS query can answer:
Which DNS server was queried?
What records came back?
How fast was the resolution?
Were the records what we expected them to be? If not, has the DNS server been compromised?

A traceroute will determine:
What route did the connection take?
How many hops?
How long did it take to establish the initial connection?
Was there a better route that could have been taken?
Is it possible a BGP hijack has occured?

HTTP queries can tell us:
Is the website content loading as it should?
How long did it take for everything to finish loading on the page?
How much data was loaded?
Did we get back the response we expected?

All of these are critical questions, and some may be answered through alternative monitoring services; however, our globally distributed network puts is in a unique position to answer one big question that others simply cannot:
Is this issue affecting everyone or is it limited to a specific location or ISP?

Learn more and get our app on


comments powered by Disqus