The reason most location based crypto ideas from 2020 died quietly is that they trusted GPS. GPS is a broadcast signal any receiver can listen to, and a receiver can be told to lie about what it heard. Tooling to do that costs about thirty dollars on Amazon and has done so since 2015. Any protocol that pays a wallet for standing at a coordinate, and verifies the standing with GPS alone, loses money to fake wallets standing on couches. It is neither a hard attack nor a clever one.
Proof of location is the layer that fixes it. The phrase gets used more than it gets defined, so let us start with a definition. Proof of location is a claim, verifiable by a party who was not present, that a specific device was at a specific coordinate within a specific time window. It is a claim about presence, not about the coordinate. That distinction is where most of the engineering lives.
The threat model. We are not defending against a nation state; that ceiling case comes at the end. We are defending against the median attacker with a phone, a laptop, and an afternoon. That attacker can spoof GPS with an off the shelf tool, run the app in an emulator, and mint a wallet in one line of code. Any single control can be defeated by that attacker. The engineering goal is to make the cost of defeating them together higher than the reward at the drop.
This piece covers what Seek does today, in plain terms, and what is on the way. It is deliberately shorter on the marketing side and longer on the mechanics.
Layer one, at catch time: device attestation. Every catch request carries a signed statement from the operating system. On iOS that is Apple App Attest, on Android that is Google Play Integrity. Seek verifies both server side. Attestation says three things in one signature: this is a real device, the app binary has not been tampered with, and the caller holds a key that was minted on this device for our bundle. A rooted phone fails. An emulator fails. A repackaged app that skipped the location check fails. Attestation does not prove where the phone is; it proves the phone is not lying about being a phone. That is what makes the other signals worth reading.
Layer two, at catch time: distance with a grace window. The client only lets you tap the catch button when you are within the collect radius of the spawn. The server independently checks the coordinates you sent against the spawn coordinates, and accepts up to seventy five metres of separation. The gap between the button radius and the server radius is deliberate. GPS jitter on a phone leaning against a wall can drift a few metres for reasons that are not your fault, and refusing catches inside that jitter feels arbitrary. Beyond seventy five metres the request is rejected outright, with no scoring and no appeal at that layer.
Layer two, continued: rate limits and per spawn caps. Two collect requests less than five seconds apart get a 429 from a Postgres backed gate that survives across serverless isolates. A single spawn accepts at most two attempts from the same account, with the second attempt worth about a third of the first. These caps are not there for fraud detection; they are there so that a bot that already beat the other layers cannot mine the endpoint faster than a person can play.
Layer three, at catch time: environment signals, recorded but not enforced. Every catch also carries flags: whether the request came from a simulator, whether Android reported the fix as coming from a mock location provider, and the reported GPS accuracy in metres. These are recorded and never used to refuse the catch itself. A client that lies about them is exactly the client you do not want making the decision, so the decision is made elsewhere. They matter at layer four.
Layer four, at payout time: the fraud gate. Withdrawals go through a server function that reads the last ninety days of catches for the account. If any of those catches came from a simulator, or Android reported a mock provider, or the account made two successful catches less than ten seconds apart, or the account moved between two catch coordinates faster than a person can travel, or another account has withdrawn from the same device fingerprint, the withdrawal is routed to human review instead of being auto approved. The user is not told which wire tripped, and their account keeps playing normally. Detection is a business decision about payouts, not a punishment.
The reason for splitting catch and payout is that they defend different things. The catch layer defends the game. If the catch was fraudulent it turns into game currency that never leaves the app, which costs nothing. The payout layer defends real money. Every dollar leaving the system goes through the ninety day review of what led to the balance, and a single suspicious signal in that window is enough to hand the decision to a human. The two layers together mean a legitimate player never sees friction at the moment of the catch, and an attacker who slipped a bad catch through never sees the money.
Layer five, at catch time: motion trace. Every phone has an accelerometer and a gyroscope on the same chip that talks to GPS. Seek now records a short window of motion for the seconds leading up to a catch, computes a small set of statistics (magnitude variance, rotational activity, number of still frames), and sends that summary with the collect request. A phone that walked to a spawn has a movement signature different from a phone sitting on a desk with a GPS simulator running. The signature is not enforced at the catch layer today, for the same reason the environment flags are not: a patched client can lie. It goes into the ninety day fraud gate, alongside the simulator and mock provider signals, and a flat motion trace on the record is another wire that hands a withdrawal to human review.
A worked example. A tester runs a GPS spoofer, sets the coordinate to a Seek drop across town, and taps catch. The distance check passes because the spoofed coordinate matches. Attestation passes because the app is unmodified. The catch registers. Two hours later the same tester makes three more catches, one of them from a different coordinate ten kilometres away. The motion trace on all four is flat (the phone never moved), and the impossible movement check fires on the two coordinates that could not have been reached on foot in two hours. The account keeps playing, keeps collecting, and does not know anything is wrong. When the tester requests a payout, it lands on a human review desk with the impossible move flag and the flat motion trace attached. The reviewer denies it. The tester's forty dollars of collected balance is never worth anything outside the app.
The economic frame. What matters is not that spoofing the catch itself is impossible; it is that the payout gate reads back through everything the account did to get to the balance. A drop worth two euros protected by attestation and distance is cheap to attack once and pointless to attack repeatedly, because the withdrawal check catches the pattern before the pattern becomes money. A drop worth ten thousand euros needs a stronger frame at the catch layer, which is what the roadmap below is about.
What is on the roadmap. Beacon fallback for indoor drops is the next control landing. For a spawn placed inside a building where GPS is meaningless, a small Bluetooth beacon registered to the drop lets the app prove presence without depending on the satellite fix at all. Attestation enforcement is the second track: today unattested requests are logged but still accepted, so we can measure the false rejection rate against legitimate devices before flipping the switch and refusing them outright. Both land as small, boring, verifiable additions to the same catch and payout pattern already in use.
What still does not work well. Indoor GPS is off by ten to fifteen metres in a shopping mall, and no amount of server side cleverness fixes that; a beacon is the real answer, which is why it is on the roadmap. Sub second latency is not there and probably will not be, because the fraud gate reads history rather than a single request. Wearables have a smaller sensor stack than phones, so a proof of location design tuned for phones does not carry over cleanly to glasses. And a nation state with a truck of RF equipment can defeat any mobile phone verifier today; any protocol that claims otherwise is not being honest with you. Ours will not.
The design principle worth stating out loud. A verifier should be honest about what it can and cannot prove. Presenting a probabilistic score as an absolute yes or no is worse than presenting an absolute yes or no from strict rules, because a score creates a slider, and any slider gets pushed toward accepting more claims when engagement targets are behind. Our catch layer has no slider. It either passes the checks or it does not. The fraud layer has a slider, and that slider lives with a human, not in the code.
This is the piece under Seek that makes anchored assets and location verified airdrops worth doing. A publisher places a token worth real money at a coordinate because the person who ends up with it was at that coordinate on an attested device, and because the payout gate will read back through the account's history before the money moves. The whitepaper has the full specification. This piece is the plain language version of what happens inside the app.
The short version. Presence is not a coordinate. A single signal does not prove presence. Seek verifies presence in two layers: attestation, distance and a motion trace at the moment of the catch, and a ninety day fraud gate at the moment of payout. The one still open, beacon fallback for indoor drops, closes the last coordinate case that GPS alone cannot. That is what proof of location actually is inside Seek today, and it is why the layer matters more than any of the flashier things it enables.
