O motivo de a maioria das ideias cripto baseadas em localização de 2020 ter morrido em silêncio é que elas confiavam no GPS. O GPS é um sinal transmitido que qualquer receptor pode ouvir, e um receptor pode ser instruído a mentir sobre o que ouviu. As ferramentas para isso custam uns trinta dólares na Amazon, e é assim desde 2015. Qualquer protocolo que paga uma carteira por estar numa coordenada, e verifica isso só com GPS, perde dinheiro para carteiras falsas paradas em sofás. Não é um ataque difícil nem esperto.
A prova de localização é a camada que resolve isso. A expressão é mais usada do que definida, então vamos começar pela definição. Prova de localização é uma afirmação, verificável por alguém que não estava presente, de que um aparelho específico esteve numa coordenada específica dentro de uma janela de tempo específica. É uma afirmação sobre presença, não sobre a coordenada. É nessa distinção que está a maior parte da engenharia.
O modelo de ameaças. Não estamos nos defendendo de um Estado; esse caso extremo aparece no fim. Estamos nos defendendo do atacante comum, com um celular, um notebook e uma tarde livre. Esse atacante consegue falsificar o GPS com uma ferramenta pronta, rodar o app num emulador e criar uma carteira com uma linha de código. Qualquer controle isolado pode ser vencido por ele. O objetivo da engenharia é que o custo de vencer todos juntos seja maior do que a recompensa do drop.
Este texto explica, em termos simples, o que o Seek faz hoje e o que está a caminho. Ele é propositalmente mais curto na parte de marketing e mais longo na mecânica.
Camada um, na captura: atestação do dispositivo. Toda solicitação de captura traz uma declaração assinada pelo sistema operacional. No iOS é o Apple App Attest, no Android é o Google Play Integrity. O Seek verifica os dois no servidor. A atestação diz três coisas numa só assinatura: este é um aparelho real, o binário do app não foi adulterado, e quem faz a chamada tem uma chave criada neste aparelho para o nosso app. Um celular com root falha. Um emulador falha. Um app reempacotado que pulou a verificação de localização falha. A atestação não prova onde o celular está; prova que o celular não está mentindo sobre ser um celular. É isso que faz os outros sinais valerem a leitura.
Camada dois, na captura: distância com margem. O cliente só deixa você tocar no botão de captura quando está dentro do raio de coleta do spawn. O servidor compara, de forma independente, as coordenadas enviadas com as do spawn e aceita até setenta e cinco metros de diferença. A diferença entre o raio do botão e o raio do servidor é proposital. A oscilação do GPS num celular encostado numa parede pode deslocar a posição alguns metros por motivos que não são culpa sua, e recusar capturas dentro dessa oscilação parece arbitrário. Acima de setenta e cinco metros, a solicitação é rejeitada na hora, sem pontuação e sem recurso nessa camada.
Camada dois, continuação: limites de frequência e limites por spawn. Duas solicitações de coleta com menos de cinco segundos de intervalo recebem um 429 de uma barreira baseada em Postgres que funciona entre isolates serverless. Um único spawn aceita no máximo duas tentativas da mesma conta, com a segunda valendo 65 por cento da primeira. Esses limites não servem para detectar fraude; existem para que um bot que já venceu as outras camadas não consiga explorar o endpoint mais rápido do que uma pessoa joga.
Camada três, na captura: sinais do ambiente, registrados mas não aplicados. Toda captura também traz indicadores: se a solicitação veio de um simulador, se o Android informou que a posição veio de um provedor de localização falsa e a precisão do GPS informada, em metros. Eles são registrados e nunca usados para recusar a captura em si. Um cliente que mente sobre eles é exatamente o cliente a quem você não quer confiar a decisão, então a decisão é tomada em outro lugar. Eles importam na camada quatro.
Camada quatro, no pagamento: a barreira antifraude. Os saques passam por uma função de servidor que lê as capturas da conta dos últimos noventa dias. Se alguma delas veio de um simulador, ou se o Android informou um provedor falso, ou se a conta fez duas capturas bem-sucedidas com menos de dez segundos de intervalo, ou se a conta se moveu entre duas coordenadas de captura mais rápido do que uma pessoa consegue, ou se outra conta já sacou a partir da mesma impressão digital de aparelho, o saque vai para revisão humana em vez de ser aprovado automaticamente. O usuário não fica sabendo qual alarme disparou, e a conta continua jogando normalmente. A detecção é uma decisão de negócio sobre pagamentos, não uma punição.
O motivo de separar captura e pagamento é que eles defendem coisas diferentes. A camada de captura defende o jogo. Se a captura foi fraudulenta, ela vira moeda do jogo que nunca sai do app, o que não custa nada. A camada de pagamento defende dinheiro real. Cada dólar que sai do sistema passa pela revisão de noventa dias do que levou ao saldo, e um único sinal suspeito nessa janela basta para passar a decisão a um humano. Juntas, as duas camadas significam que um jogador honesto nunca sente atrito no momento da captura, e um atacante que conseguiu passar uma captura ruim nunca vê o dinheiro.
Camada cinco, na captura: registro de movimento. Todo celular tem um acelerômetro e um giroscópio no mesmo chip que conversa com o GPS. O Seek agora registra uma janela curta de movimento dos segundos que antecedem uma captura, calcula um pequeno conjunto de estatísticas (variância da magnitude, atividade de rotação, número de quadros parados) e envia esse resumo com a solicitação de coleta. Um celular que caminhou até um spawn tem uma assinatura de movimento diferente de um celular parado numa mesa com um simulador de GPS rodando. Essa assinatura não é aplicada na camada de captura hoje, pelo mesmo motivo dos indicadores de ambiente: um cliente modificado pode mentir. Ela entra na barreira antifraude de noventa dias, junto com os sinais de simulador e de provedor falso, e um registro de movimento plano no histórico é mais um alarme que manda um saque para revisão humana.
Um exemplo prático. Um testador roda um falsificador de GPS, define a coordenada num drop do Seek do outro lado da cidade e toca em capturar. A verificação de distância passa, porque a coordenada falsa confere. A atestação passa, porque o app não foi modificado. A captura é registrada. Duas horas depois, o mesmo testador faz mais três capturas, uma delas de outra coordenada, a dez quilômetros. O registro de movimento das quatro é plano (o celular nunca se mexeu), e a verificação de deslocamento impossível dispara nas duas coordenadas que não poderiam ser alcançadas a pé em duas horas. A conta continua jogando, continua coletando e não sabe que há algo errado. Quando o testador pede um saque, ele cai na mesa de revisão humana com o indicador de deslocamento impossível e o registro de movimento plano anexados. O revisor recusa. Os quarenta dólares de saldo coletados pelo testador nunca valem nada fora do app.
O enquadramento econômico. O que importa não é que falsificar a captura em si seja impossível; é que a barreira de pagamento revisa tudo o que a conta fez para chegar ao saldo. Um drop de dois euros protegido por atestação e distância é barato de atacar uma vez e inútil de atacar repetidamente, porque a verificação no saque pega o padrão antes que o padrão vire dinheiro. Um drop de dez mil euros precisa de uma estrutura mais forte na camada de captura, e é disso que trata o roadmap abaixo.
O que está no roadmap. O próximo controle a chegar é o beacon de reserva para drops em ambientes fechados. Para um spawn colocado dentro de um prédio, onde o GPS não significa nada, um pequeno beacon Bluetooth registrado para o drop permite que o app prove a presença sem depender do sinal de satélite. O segundo caminho é a aplicação da atestação: hoje, solicitações sem atestação são registradas mas ainda aceitas, para que possamos medir a taxa de recusas falsas entre aparelhos legítimos antes de acionar o botão e recusá-las de vez. Os dois chegam como acréscimos pequenos, sem graça e verificáveis ao mesmo padrão de captura e pagamento que já está em uso.
O que ainda não funciona bem. O GPS em ambientes fechados erra de dez a quinze metros num shopping, e nenhuma esperteza no servidor resolve isso; a resposta real é um beacon, e é por isso que ele está no roadmap. Latência abaixo de um segundo não existe e provavelmente não vai existir, porque a barreira antifraude lê o histórico, e não uma solicitação isolada. Os wearables têm menos sensores do que os celulares, então um design de prova de localização ajustado para celulares não se transfere bem para óculos. E um Estado com um caminhão de equipamentos de rádio consegue vencer hoje qualquer verificador baseado em celular; qualquer protocolo que diga o contrário não está sendo honesto com você. O nosso não vai dizer.
O princípio de design que vale dizer em voz alta. Um verificador deve ser honesto sobre o que consegue e o que não consegue provar. Apresentar uma pontuação probabilística como um sim ou não absoluto é pior do que apresentar um sim ou não absoluto a partir de regras rígidas, porque uma pontuação cria um controle deslizante, e todo controle deslizante é empurrado para aceitar mais resgates quando as metas de engajamento estão atrasadas. Nossa camada de captura não tem controle deslizante. Ou passa nas verificações, ou não passa. A camada antifraude tem um controle deslizante, e ele fica com um humano, não no código.
Essa é a peça por trás do Seek que faz valer a pena ter ativos ancorados e airdrops verificados por localização. Um publicador coloca um token de valor real numa coordenada porque a pessoa que fica com ele esteve naquela coordenada com um aparelho atestado, e porque a barreira de pagamento vai revisar o histórico da conta antes de o dinheiro se mover. O whitepaper tem a especificação completa. Este texto é a versão em linguagem simples do que acontece dentro do app.
A versão curta. Presença não é uma coordenada. Um único sinal não prova presença. O Seek verifica a presença em duas camadas: atestação, distância e registro de movimento no momento da captura, e uma barreira antifraude de noventa dias no momento do pagamento. O único ponto ainda aberto, o beacon de reserva para drops em ambientes fechados, fecha o último caso de coordenada que o GPS sozinho não resolve. É isso que a prova de localização realmente é dentro do Seek hoje, e é por isso que essa camada importa mais do que qualquer uma das coisas mais chamativas que ela possibilita.
