FOAM Location Update and Demo Documentation


Hello all, this post is to serve as documentation of the demo that took place during ETH New York 2019. ​​We recently demonstrated a major milestone in our Proof of Location technology by processing and validating a Presence Claim over radio.


At FOAM, we’re building what we call Proof-of-location and are creating an architecture that can be summarized as follows:

  1. ( Rootchain ) Incentivization for producing and validating location data (Presence claims) can be governed using smart-contracts on Ethereum

  2. ( Sidechain ) The data produced can be transmitted to and validated on local blockchains and produce cryptographically proven Presence claims.

  3. ( Radio ) Consumer radio hardware run a byzantine fault-tolerant time synchronization protocol in a mesh configuration over the air with cryptographic signatures

The reasoning behind this architecture is outside the scope of this article, but suffice to say that Ethereum suffers from what’s called the scaling problem : transactions are costly and slow. Scaling solutions such as Plasma and Tendermint allow workarounds and we have therefore embarked on an architecture that fulfill the needs for FOAMs radios to operate without with fast and low cost transactions within the Zones themselves.

Previously, we have shared information about the GeoPickle test net, which allows us to perform simulations and testing of layers 1 and 2 with a virtual layer 3, in this case represented by a rack of 40 Raspberry PIs. For more on what this test set up allows for research and development see the post below: (note that layers were listed in reverse order in this article)

Additionally, this post serves as a higher level explanation of the protocol:

Demo Architecture

The demo outlined in this post demonstrates the first time we utilized a Layer 3 running over radio and thus replacing the virtual layer 1 of the GeoPickle. We consider this a major milestone for FOAM.

For demo purposes we had decided on a couple of technologies for prototyping the architecture of Proof-of-location:

  1. ( Rootchain )
    We deploy the Plasma contracts to Ethereum. These follow the PlasmaMVP implementation which is a design for an extremely simple UTXO-based Plasma chain. The basic Plasma MVP specification enables high-throughput payment transactions but does not support more complicated constructions like scripts or smart contracts. For more of how Plasma MVP functions as well as how a UTXO model works, see:

  2. ( Sidechain )
    We use the FourthState PlasmaMVP Tendermint integration for this layer. Simply speaking, Tendermint ensures that the order in which the radios logs get transmitted is agreed upon by all participants. In addition, we foresee that it is important to be able to store logs from the participants. Therefore we need not just a single plasma operator for the participants to reach consensus over the logs but also need them to be accessible for later inspection. A Tendermint sidechain fits the purposes for this demo to allow that. In order for us to work with the FourthState implementation, we forked their repo and added a REST server on top of their API. We anticipate that this is something that they will want to add to their project in the future and in the event this fits our needs, we’ll be happy to switch to their implementation.

  3. ( Radio )
    In this demo we used the LoRa SX1276 mbed Component Shield alongside a STM32 Nucleo-64 development board with STM32F303RE MCU as the micro-controller. We have developed a custom firmware for the transceiver boards which implements packet transmission and reception with relatively high-resolution timestamps, This allows for messages to be precisely timed for inclusion in the blockchain, enabling the necessary information for localization to be communicated to the blockchain aspects of the stack.

A ZoneAnchor prototype

Transceivers can only operate on one channel, so for this demo each Zone Anchor has four transceivers and a Raspberry Pi. Future iterations of the demo and the FOAM developer kit under development will utilize the LoRa SX1301 gateway chip, which can operate on multiple channels at once.

The Demo

The general outline of the demo is the following:

Three radios are consistently engaging in a time synchronization protocol over radio and thus have the ability to locate a user within their reach. They have formed a Zone on a Plasma sidechain and staked token to guarantee their fulfillment of the protocol.

A user enters the Zone and wants to request a Presence claim. The user transfers tokens to the Plasma sidechain and burns their token there. The radios see the request, logs the exact time it was received and validate the Presence claim. For this, they are rewarded with tokens that they can claim on the root chain. In exchange, the user has a Presence claim signed by the radios that is valid with respect to the logs posted to the sidechain.

The complete flow is described by the following diagram:

We built a simple front-end web interface which shows the status of the Plasma child chain as it pertains to the root chain, i.e. Ethereum which is where the FOAM token is staked. The front-end shows the logs from the radios coming in where they can be staked. The front-end utilizes Metamask to interact with Ethereum and the Plasma chain. What we will see in the demo is that a user wants to establish its location, it can talk to the radios (Zone), request a presence claim and see the transactions happen on the front-end.

Demo browser walkthrough

Note in the following that

  • User or “Account 1” is represented by the address 0x3a9bca...
  • ZoneAnchor or “adversary” is represented by 0x1ea6e6...

Moreover, this demo does not focus on localization, which can be derived from the time-stamped logs. The important demonstration here is that the radios commit proof of the time synchronization and that the logs that they commit are compatible with the signatures used for participations on both root and the Plasma chain that the User and the radios communicate over.

1. User registration

1a. The user deposits ETH to the Plasma contract

1b. The deposit is displayed in the Plasma contract

1c. The user now has an unspent UTXO. In place of a more advanced escrow smart contract, for this demo we are simply burning this UTXO.

1d. By signing a message the UTXO gets included on Tendermint. The burn requires signed confirmation because in the event the user tried to re-instantiate their tokens on Ethereum it would be fraudulent.

1e. The user can now request a Presence claim to be validated

2. Zone creation

2a.Simultaneously, a Zone is created

2b. Zone creation is represented through signing of an UTXO on Tendermint

2c. The Zone has been registered

3. Presence claim submission

3a. A Zone anchor can now sign a Presence claim

3b. The logs are submitted form the Radio as proof that the Presence claim is valid

4. Presence claim is valid

4a. The user can now access their Presence claim

4b. The ZoneAnchor has been rewarded an UTXO that can be transferred to the root chain. Once the Tendermint hashes containing these transactions are posted to the root chain and are verified, the user’s burnt UTXO is distributed to the Zone Anchors as payment for the presence claim.

Conclusion and outlook

We are currently wrapping up the demo so that we can host it and have a small test-net running for public inspection. At this point, we aim to put more work into both the hardware design of our next prototype as well as additional work that is warranted on the time synchronization and blockchain software. Subsequent blog posts will focus on those efforts. Once we reach our milestones for that, we will revisit this demo to see if Plasma and Tendermint remain the technologies we chose to build upon. For now, we are happy to have demonstrated the full life cycle of a Presence claim, with both the sidechain machinery, the radio protocol and the connecting of them both to Ethereum. As mentioned above, along with the recent addition of electrical engineers to the team, future iterations of the demo and the FOAM developer kit under development will utilize the LoRa SX1301 gateway chip, which can operate on multiple channels at once. The goal is for this developer kit and beta software to be available to users later this year for testing. In parallel, Foamspace will be working on a pilot project with partners at the New Lab and across the Brooklyn Navy Yard.

Demo Videos

A recording of this Demo can be Found Here:

Part 1

Part 2

The FOAM Location Update and Demo Documentation will also be the topic of the next FOAM Community Call.


Thank you for the very thorough write up. Tech documentation is hard, and I think you captured the excitement of the demo and were able to provide the detail needed for those evaluating this effort.

I look forward to the next iteration; Zone Anchor’s are really key to moving FOAM to the next step of servicing a wider audience!


Just got done reading this. Awesome demonstration. What is the time delta between action 1a and 4a?


What is the time delta between action 1a and 4a?

Great question! Ignoring the time it took us to explain what was going on, you’d need 1 ETH block for the deposit into the sidechain, minimium of 1 ETH block for withdrawing plus a Plasma MVP exit challenge period. In practice, many presence claims can be made from one deposit into a sidechain as well as many exited with one ETH tx. The actual process of putting tokens into escrow (in that particular demo that was represented as burning) and broadcasting/collecting the presence was 3 Plasma blocks (One escrow burn, one presence claim request, and one presence claim grant). Note that this duration can be as little as 2 Plasma blocks. (one for the escrow burn and one for the radios signing the broadcast presence claim). It’s worth noting that within the Plasma sidechain a more sophisticated behavior can be encoded for the escrow burn (e.g. create multiple presence claim requests from a single escrow burn that I can broadcast out over time) as well as automatically filling presence claims with logs as radios post them. Plasma block times can of course be tuned and as low as sub-second depending on the topology of the sidechain operators. In this demo I believe one Plasma block was 3 seconds.


This video is to serve as documentation of the demo that took place during ETH New York 2019. We recently demonstrated a major milestone in our Proof of Location technology by processing and validating a Presence Claim over radio.

For developer documentation see:


Is this a video related to ETH New York 2019 and the demo that happened there 3 months ago ?

Just want to make sure because you say “we recently demonstrated” so I’m wondering if I missed a major progress that happened since then.

Thanks for clarifying.


It’s old news from May.


Indeed @jazzhands and I would even say that more important than the “news” aspect, it’s old milestone/progress. 3 months is a lot. Going back on something done 3 months ago raise questions on execution. Saying we “recently demonstrated” was misleading I thought it was the release of the testnet which Ryan said it would be released “soon” in the call with Rick Dudley but no update on it so far.

We are doubting with my team that we will see dynamic proof of location by end of year and with no roadmap published to date it’s hard/dangerous for people/stakeholders to put resources at stake with no visibility ahead. Being a web3 open source platform doesn’t mean basic economics and business principles don’t apply …


Would be nice if @Ryan_foam would engage but that doesn’t seem to happen anymore. Who knows what is going on in terms of development, but the community aspect of Foam feels thoroughly dead, which is a massive disappointment but not a surprise, given the lack of investment by the Foam team.


@jazzhands @cartocrypto We have another Community Workshop Call this Thursday, 8/22 @ 12pm EDT to finalize the FIP process and specification. We are driving forwards with hashing out the final details, and then promoting the three improvement proposals that there was consensus around in the last community workshop call into the first formal FIPs. You can see those proposed FIPs that we discussed in the last call here.

It’s clear that activity has tapered off both on the map and in this forum over the past month or so. I think this is due to a combination of factors, including the:

  1. malicious behavior on the map that effectively turned away voters/challengers
  2. repetitious negative posting on the forum here by just a few accounts, despite responses by myself, others, as well as @Ryan_foam, turning readers away
  3. late July through August being vacation time. I myself was away without internet access for over two weeks. I assume other cartographers and active Discourse users have also been away during some of this time.

As I’ve said in the past, you’re always welcome to come join a Community Workshop Call to work with us to constructively develop solutions to current challenges faced by the project, or to work on areas of the project that the core FOAM team deems lower priority at the moment.

At this point it’s pretty clear that repetitive posting of criticism does not help or create any progress, but rolling your sleeves up and offering to help does! :slightly_smiling_face:

Now back to the original topic of the thread!


On the first call we had about 18 people join. On the second, we had about 10, and on the third about 15. It’s not just me and two others.

I, Elvo, Yinzeus, Caleb, and Ryan have already responded to the criticism, most of us multiple times. At this point though, it’s pretty clear that there’s nothing that anyone can say to change your perspective, so we will just have to see how things play out.


Hello guys,

I’m looking for the last update on dynamic proof of location. My clients asked me but I can’t remember what is was. Was it the demo made in ETH NY in May 2019 ? Or anything more recent ?

Has any subsequent and most recent blog posts been released ?

Is there any demo coming soon that actually focus on localization ?


As a user/stakeholder of FOAM I can’t express how much I’m disappointed by the way you @Ryan_foam and the team communicate with the very few people involved/interested in FOAM. I say this as a constructive feedback, how you keep on ignoring people that contribute to what you are building is beyond my understanding.

The thing is there can never be any good reason to ignore the handful people that are actually using or showing interest in FOAM. I repeat that again because I think we can all agree, there can never be any good reason to ignore a user or potential user. I don’t know if you are aware that it gives a very bad impression of FOAM project and undoubtedly explains why people that have been involved in the past are less and less. The message that you are basically expressing is “we don’t care about you” and you either don’t seem to realize that or you just don’t care.

It should be hard to communicate with you or the team when you have a product/market fit and thousands of users are using FOAM on a daily basis not when someone is an early adopter of a protocol that is not launched and not used.


@Ryan_foam It will be nice to get another comprehensive update on the current status of dPOL with a focus on hardware developments, firmware, plasma etc


Agree, would be very nice to get a new update on dPoL. I was expecting one on the previous community call :slight_smile:


Deployable hardware is closer than the FOAM community is aware.


@cryptozen @Zyndar @yinzeus and all, definitely, comprehensive update will be posted tomorrow. A lot to share on the new Zone Anchor architecture and testing we have been building the last months with moving pieces while still under development. This work is just starting to be shared, we are hacking with the LoRa Things Network Community this evening at our offices on the new boards.