FOAM is a Proof of Location technology for applications needing secure location services. It enables a handshake between the location service providers (FOAM network) and the user, proving the user’s location. Terrestrial radios and time-of-flight algorithms are used to perform localizations, and digital signatures ensure the location data cannot be spoofed. The system is completely independent of satellite-based location services like GPS.

Our previous post announced the FOAM MVP, the first full-stack demonstration of a Proof of Location network. The end user output of FOAM’s Proof of Location system is a “Presence Claim”, a location proof represented as an onchain NFT(ERC-721). You can think of a Presence Claim as a digital certificate proving the presence of someone or something at a specific location and time. The FOAM MVP demonstrates the creation and usage of Presence Claims.

The MVP ties together key components of the Proof of Location stack, such as radio hardware and the Hostel Webapp front-end UI. Importantly, this also includes onchain smart contracts deployed on our OP testnet for registering Zones, validating localization data, minting Presence Claims, staking and fee payments. There are a number of contracts in use for the MVP. The purpose of this post is to dive deeper into three core contracts and take a look at their functions in the protocol.

Zone Contract

In Proof of Location a Zone consists of four or more Zone Anchor radios. The Zone smart contract is used to create and destroy Zones, via an externally owned Ethereum account. The contract acts as a registry, maintaining a participant list of which Zone Anchors belong to which Zone, along with additional metadata. A Zone Anchor included in a Zone recognized by the Zone contract will be eligible to vote on Presence Claim validations and earn fees.

When interacting with this contract to create a Zone, there is also a requirement to stake FOAM tokens. In this sense the Zone contract also acts as a Service Level Agreement (SLA) dictating the rules of the protocol and what the expected behavior is for a Zone. In addition to earning fees from issuing Presence Claims, this contract will interact with mining rewards and slashing conditions.

CIDManager Contract

As the name suggests, this contract is responsible for managing the content identifiers (“CIDs”) of incoming localization information and storing pending localizations for Zone Anchors to vote on.

As part of the FOAM localization pipeline, metadata generated in the Hostel webapp is stored and written to IPFS/IPLD. The EVM does not currently have native IPLD support, so we require some way of talking about data in IPLD as it is used to inform a presence claim. The GossipUtils contract plays a role here, which stands for Gossip Message Utilities contract. This is technically a solidity library that helps the CIDManager contract by parsing localization data read from DAG-CBOR encoded localizations on IPFS/IPLD to binary. This data is then held by the LocalizationStore contract.

Ultimately, this CIDManager contract is initialized with incoming user localizations and takes votes from the different Zone Anchors. A validity function checks the number of votes / tally before a Presence Claim is Issued.

PresenceClaim Contract

When a user wants to mint a Presence Claim, this contract calls CIDManager to see if a localization message has been deemed valid. If so, the hash is looked up in the LocalizationStore contract and an ERC-721 token is minted for the localization with the owner set to the requesting Mobile Node. Data associated with a minted Presence Claim includes:

• Zone

• Zone Anchors

• Mobile Node

• Timestamp

• Geohash

It should be noted that all of the above contracts are deployed on the FOAM devnet Optimism L2, with the addition of one bridged PresenceClaim contract on the L1 devnet.

Conclusion

This post covers the three core smart contracts of the FOAM MVP, which include Zone CIDManager andPresenceClaim. Together with hardware, firmware and user interfaces these blockchain smart contracts demonstrate the importance of onchain location proofs. Forthcoming posts will focus on demos and use cases of Presence Claims. As for future smart contract development, this will include:

• Voting currently happens on data submitted to CIDManager and is done solely by the Zone Anchors in the relevant Zone. However, due to the distribution of the data on IPFS, it's technically feasible for specific validator agents to participate in the voting (for reaping fees). This is currently out of scope for the MVP.

• Staking rewards and penalties, and their weighing by the signals deployed in a Zone is also not yet implemented, though it is designed to happen on the L2 once the FOAM Signal contract has been snapshot. See a future blogpost for details about this.