Des actifs numériques qui vivent quelque part

Internet a rendu chaque objet numérique disponible partout à la fois. C'était le but, et cela a marché. Mais cela a aussi retiré aux choses numériques la seule propriété qui donne de la valeur aux choses physiques : être à un endroit précis. Un billet de concert compte parce qu'il ouvre une salle. Un monument compte parce qu'il faut s'y rendre.

Seek Protocol remet le lieu dans les actifs numériques. Un token, un NFT ou une récompense peuvent être émis vers un jeu de coordonnées plutôt que vers un portefeuille, et ils y restent jusqu'à ce que quelqu'un se tienne physiquement dans leur rayon et le prouve. C'est ce que nous appelons la preuve de localisation, et c'est la primitive sur laquelle repose le reste du protocole.

La face visible est SeekAR, une application mobile sur iOS et Android qui affiche ces actifs en réalité augmentée. Vous marchez, votre téléphone montre ce qui est à proximité, et vous récupérez ce que vous trouvez. En dessous, le règlement se fait sur Solana, choisie pour des coûts de transaction assez bas pour que ramasser une petite récompense ne coûte pas plus que ce qu'elle vaut.

Ce que couvre ce document

Seize chapitres, en quatre mouvements. Les trois premiers posent le problème et la primitive qui y répond. Les chapitres quatre à sept sont la mécanique : comment une réclamation circule, comment les couches s'emboîtent et ce que l'application en fait. Huit à onze forment l'économie, de qui paie la pose jusqu'à qui décide des paramètres. Les cinq derniers sont ce qu'un whitepaper laisse d'ordinaire de côté : les attaques, le coût pour la vie privée, la position réglementaire et les limites assumées.

Plusieurs figures se manipulent. Le modèle de vérification, la chronologie d'une réclamation, le tirage de capture et le calculateur de budget font le même calcul que le protocole, avec les mêmes constantes, pour que vous puissiez contester la conception plutôt qu'un dessin de la conception.

Deux groupes ont un problème qui se révèle être le même, vu des deux bouts.

Les marques et les lieux ne peuvent pas acheter de visites

La publicité numérique peut mettre une image devant quelqu'un en quelques millisecondes. Elle ne peut pas le faire marcher trois rues plus loin. Le passage de l'impression à la visite physique est le maillon le plus faible de tout l'entonnoir du commerce et de l'événementiel, et il est mal mesuré, le plus souvent en demandant aux gens en caisse s'ils ont vu une publicité.

La réponse du secteur, c'est la modélisation. Des panels d'appareils consentants sont extrapolés à une population, et le chiffre de visites en magasin qui en sort est rapporté à côté des impressions et des clics comme s'il venait du même compteur. Ce n'est pas le cas. Un chiffre est un événement, l'autre une estimation, et les campagnes sont jugées sur l'estimation.

Les projets crypto ne trouvent pas de vrais utilisateurs

Les airdrops sont l'outil standard de distribution, et ils se font farmer. Créer un portefeuille ne coûte rien, donc toute récompense qu'un portefeuille peut réclamer sera réclamée par des milliers de portefeuilles appartenant à une poignée de personnes. Les projets répondent par des règles d'éligibilité toujours plus alambiquées, qui écartent surtout les utilisateurs ordinaires pendant que les farmeurs aguerris s'adaptent.

Les deux problèmes se dissolvent si l'on peut prouver qu'un être humain était à un endroit précis à un moment précis. La fréquentation devient mesurable parce que l'arrivée est l'événement enregistré. Farmer un airdrop devient coûteux parce qu'un portefeuille est gratuit et pas le déplacement, et personne n'est dans quarante villes à la fois.

Pourquoi c'est constructible maintenant et pas avant

Trois choses devaient converger. Les téléphones devaient embarquer en série un GNSS bifréquence, des caméras avec perception de la profondeur et une attestation matérielle, et non les réserver aux modèles haut de gamme. Le règlement devait devenir assez bon marché pour qu'une récompense de quelques centimes survive au transfert, ce qui excluait toutes les chaînes tant que les frais dépassaient un centime. Et les gens devaient accepter de pointer une caméra vers une rue et d'y voir quelque chose incrusté, ce qu'une décennie d'AR dans les jeux a réglé sans bruit.

La preuve de localisation est l'affirmation qu'un appareil donné se trouvait dans un rayon donné pendant une fenêtre donnée, rendue assez crédible pour libérer quelque chose de valeur sur cette base.

Aucun signal n'est fiable à lui seul. Le GPS brut se falsifie depuis n'importe quel appareil rooté avec un fournisseur de position simulée. Le protocole note donc une réclamation sur plusieurs signaux indépendants et exige que la combinaison soit cohérente, car falsifier un signal est facile et les falsifier tous de façon cohérente ne l'est pas.

Les signaux que nous combinons

• Point GNSS, la position satellite brute avec la précision annoncée, plus la constellation et le nombre de satellites, que les falsificateurs se trompent souvent à reproduire.
• Environnement radio, l'ensemble des SSID Wi-Fi et des antennes proches, comparé à ce que le protocole s'attend à voir à ces coordonnées. Les environnements radio sont difficiles à fabriquer et changent lentement.
• Attestation de l'appareil, Play Integrity sur Android et DeviceCheck ou App Attest sur iOS, qui confirment que l'application est authentique et le système non compromis.
• Continuité du mouvement, la trace de l'accéléromètre entre la position confirmée précédente et celle-ci. Une réclamation affirmant un trajet de 400 km en 90 secondes sans profil de mouvement correspondant est rejetée.
• Plausibilité temporelle, où les heures d'arrivée sont confrontées au temps de trajet qu'implique votre dernière position confirmée.

Chaque signal alimente un score de confiance. Les actifs fixent le score qu'ils exigent : une récompense de quête de faible valeur peut se contenter d'un score moyen, tandis qu'un drop de forte valeur lors d'un événement à billetterie peut exiger l'attestation de l'appareil et un environnement radio concordant. Les réclamations sous le seuil sont refusées, et des refus répétés depuis un même appareil relèvent le seuil pour cet appareil.

Pourquoi les signaux sont pondérés plutôt qu'exigés

Une règle qui exige tous les signaux est une règle qui refuse des utilisateurs honnêtes. Les stations souterraines perdent le GNSS. Les bâtiments neufs ont des environnements radio que la carte n'a jamais vus. Un téléphone deux versions en retard peut échouer à l'attestation pour des raisons sans rapport avec la fraude. La pondération permet à un actif de dire combien de preuves sa valeur mérite, et permet à une réclamation honnête de survivre à un mauvais signal sans laisser une réclamation falsifiée en survivre à quatre.

Le chapitre précédent décrit les preuves. Celui-ci suit une seule réclamation, du moment où vous tendez la main vers un actif jusqu'à celui où il est dans votre portefeuille, car c'est dans l'ordre des opérations que se logent la plupart des décisions de conception.

La frontière qui compte

Regardez où les étapes changent de machine. Tout ce qui est sensible se passe dans les trois premières : la position, le balayage radio, la trace de mouvement, l'attestation. Rien de tout cela ne quitte votre téléphone sous forme brute. Ce qui passe au vérificateur est une réclamation signée, et ce qui passe du vérificateur à la chaîne est une attestation signée que la réclamation a atteint son seuil.

C'est pourquoi la vérification est off-chain. Ce n'est pas un compromis de passage à l'échelle. Mettre la notation on-chain reviendrait à publier les entrées, et ces entrées décrivent où vous vous tenez et quels réseaux sans fil vous entourent.

Ce qui se passe en cas d'échec

• Sous le seuil : la réclamation est refusée, l'actif reste sur la carte, et rien n'est écrit sur la chaîne. Le refus est consigné au compte de l'appareil.
• Refus répétés : le score exigé pour cet appareil monte. Un appareil qui a échoué six réclamations en une heure n'est pas traité comme un appareil qui n'en a raté aucune.
• Échec de règlement : la réclamation est conservée et relancée plutôt qu'abandonnée. Un actif gagné et non livré est un bug qui coûte de la confiance, la file est donc conçue pour mettre de côté un paiement bloqué plutôt que de bloquer ceux qui suivent.
• Expiration en cours de réclamation : les actifs portent une fenêtre, et une réclamation qui arrive après sa fermeture est refusée, même avec un score parfait. La fenêtre appartient à l'actif, pas à l'état du réseau.

Le protocole compte quatre couches. Chacune se raisonne, et se remplace, séparément.

La séparation compte surtout à la frontière entre localisation et règlement. La vérification de localisation est probabiliste et se fait off-chain, parce qu'elle dépend de données de capteurs qui n'ont rien à faire en public. Ce qui atteint la chaîne est une attestation signée qu'une réclamation a atteint son seuil, pas votre historique de déplacements.

Ce qui est stocké, et où

• On-chain : les définitions d'actifs, leurs coordonnées et rayons, les enregistrements de réclamation et les transferts de tokens. Public et permanent.
• Off-chain : les relevés bruts des capteurs, les empreintes radio et les attestations d'appareil. Conservés le temps de noter une réclamation et de traiter les litiges, puis écartés.
• Sur l'appareil : votre historique de positions et les données d'ancrage AR. Cela reste sur votre téléphone sauf partage explicite de votre part.

Pourquoi Solana

L'exigence est inhabituelle pour une chaîne : un très grand nombre de transactions, une très faible valeur par transaction, et une confirmation assez rapide pour qu'une personne debout dans la rue ne la remarque pas. Qui ramasse une récompense de vingt centimes ne peut pas en payer dix pour la recevoir, et ne restera pas immobile trente secondes. Cette combinaison élimine la majeure partie du terrain sur le coût et le reste sur la latence.

Le compromis est réel et mérite d'être dit. Solana a connu des interruptions, et une chaîne à l'arrêt, ce sont des réclamations en file. Le protocole traite le règlement comme une étape qui peut échouer et être relancée plutôt que comme une étape toujours réussie, ce qui est la bonne conception quelle que soit la chaîne mais n'est pas optionnel sur celle-ci.

Ce qui tourne où

SeekAR est l'endroit où le protocole devient utilisable sans rien savoir de ce qui précède. L'application s'ouvre sur une carte de ce qui est à proximité, et lever la caméra affiche ces actifs à leur place via le moteur AR.

Ce que fait l'application

• Découvrir, une carte en direct des drops, quêtes et événements à distance de marche, filtrée selon ce qui vous intéresse vraiment.
• Récupérer, où vous pointez la caméra, voyez l'actif ancré dans le monde, tendez la main et le prenez. Le règlement se fait en arrière-plan.
• Guider, un compagnon IA qui lit vos environs à travers la caméra, propose des itinéraires, explique ce que vous regardez et s'adapte à votre façon de jouer.
• Détenir, un portefeuille intégré créé depuis une connexion sociale, pour qu'un nouvel utilisateur n'ait pas à noter une phrase de récupération avant de pouvoir ramasser quoi que ce soit.

La contrainte d'entrée guide plus de décisions de conception que n'importe quelle autre. La plupart des gens qui utiliseront SeekAR n'ont jamais tenu de clé privée. Si les trente premières secondes contiennent le mot « mnémonique », ils partent. Le portefeuille est donc créé en silence et peut être exporté ensuite par qui veut en avoir la garde.

La marche jusqu'au drop

Les actifs se trouvent à quelques dizaines ou centaines de mètres, une distance où une carte suffit et où un itinéraire est superflu. Marquer un spawn trace une ligne droite de vous à lui. La ligne est volontairement pointillée : c'est un cap, pas un itinéraire, elle ignore les bâtiments, et sur cette distance le cap est généralement le chemin. Elle s'efface d'elle-même dès que vous êtes à portée de capture, où l'anneau prend le relais.

Les spawns expirent en moins d'une heure. C'est une décision de jeu avec une conséquence protocolaire : un marqueur restauré au lancement suivant pointerait vers rien, l'application n'en conserve donc aucun.

L'ancrage, et à quoi sert l'AR ici

Le passage caméra n'est pas décoratif et ce n'est pas non plus la vérification. Il fait deux choses. Il place l'actif à un endroit crédible du monde, de sorte que tendre la main soit un geste plutôt qu'un appui sur un bouton, et il donne au signal de mouvement quelque chose avec quoi être cohérent, car une personne qui tourne autour d'un objet ancré bouge comme une personne, et un falsificateur qui tient son téléphone immobile, non.

Un protocole qui paie l'arrivée a quand même besoin d'une raison pour la première arrivée. Personne ne marche quatre rues pour un mécanisme. La couche de jeu est le côté demande du réseau, et elle est conçue avec la même honnêteté que la vérification : les probabilités sont publiées, elles sont calculées côté serveur, et on ne demande jamais au client ce qui s'est passé.

La capture

Atteindre un actif ne vous le donne pas. Un anneau de charge se remplit tant que vous maintenez l'appui, et la qualité de cette charge alimente un multiplicateur. Ensuite le serveur tire. Vous avez deux tentatives par spawn, et la seconde vaut 0,65 de la première, le chiffre qui fait qu'une seconde chance ressemble à une seconde chance plutôt qu'à un lot de consolation.

Les termes que personne ne publie d'habitude

La plupart des jeux cachent les modificateurs. Il n'y a aucune raison de le faire ici, car la propriété intéressante est que l'adresse pousse et ne décide jamais. L'anneau de charge est un multiplicateur entre 0,85 et 1,0 : une frappe parfaite sur un légendaire reste un légendaire, et une frappe ratée sur un commun reste probablement un commun.

• Bonus de niveau, 0,3 point de chance fixe par niveau de joueur, sur dix niveaux de Seeker à Legend.
• Série froide, un compteur de compensation de 2 points par échec consécutif, plafonné à 12, appliqué aussi à la seconde tentative et d'une pièce à l'autre.
• Pénalité de série, 4 points par réussite consécutive sur la même pièce, plafonnée à 20, pour que farmer un point de spawn empire au lieu de s'améliorer.
• Bonus de clan, plafonné à 5 points, gagné par le clan et non par le joueur.
• Power-ups, achetés ou gagnés, qui multiplient la chance de base avant l'ajout de tous les autres termes.

La progression, et à quoi elle sert

Niveaux, badges, clans, défis de douze heures et objectifs hebdomadaires existent pour donner à la marche une forme plus longue qu'un seul drop. Ils font aussi un travail de protocole : un joueur avec un niveau, un clan et une série a un compte avec une histoire, et une histoire coûte cher à fabriquer à grande échelle. La progression est un second coût imposé au farmeur, qui ne coûte rien au joueur honnête, puisqu'il allait jouer de toute façon.

Un réseau fondé sur les lieux ne vaut rien si les lieux sont vides. Le protocole traite donc le dépôt d'actifs comme un produit à part entière, pas comme un outil interne.

Trois types d'éditeurs

• Les marques et les lieux utilisent le portail entreprise pour déposer des offres devant leurs propres locaux et mesurer qui est réellement venu. Ce qu'ils achètent est une visite vérifiée, pas une impression.
• Les projets de tokens et les communautés NFT distribuent à des personnes plutôt qu'à des portefeuilles, avec la géographie comme filtre que le farming ne peut pas contourner à bas coût.
• Les organisateurs d'événements transforment un festival, un match ou une conférence en carte à réclamer pour la durée de l'événement, avec des actifs qui expirent avec lui.

Les trois utilisent le même créateur de campagnes : poser une épingle, régler le rayon, choisir l'actif et la quantité, fixer le seuil de confiance et la fenêtre, financer, publier. Aucun travail d'intégration, et aucun contrat à écrire.

Le problème de la densité

Ici l'offre et la demande sont géographiques, ce qui rend inutiles les conseils habituels de place de marché. Mille actifs répartis uniformément sur un pays, c'est une carte vide partout. Les mêmes mille dans une seule ville, c'est une raison de sortir. Le prix du dépôt est donc pondéré par la demande dans la zone plutôt que forfaitaire, si bien qu'une rue commerçante saturée coûte plus cher à tenir qu'une rue calme, et le protocole subventionne les rues qui ont besoin de passage plutôt que celles qui en ont déjà.

$SEEK est l'actif de règlement et de coordination du protocole. Il existe parce que le réseau doit déplacer de la valeur entre des parties qui ne se connaissent pas, une marque dans un pays finançant une récompense réclamée par un inconnu dans un autre, et parce que le coût du dépôt d'actifs doit suivre la demande pour les lieux utilisés.

Utilité

• Financement de campagne, où les éditeurs libellent et financent les récompenses en $SEEK.
• Frais de dépôt, un frais par actif déposé, pondéré par le rayon, la durée et la demande pour la zone.
• Staking pour la priorité, où le $SEEK staké relève la priorité de dépôt d'un éditeur quand plusieurs campagnes se disputent les mêmes coordonnées.
• Récompenses, avec la majorité des frais du protocole qui revient à ceux qui font la marche.
• Gouvernance, sur les changements de paramètres, l'allocation de la trésorerie et les seuils de confiance des réclamations de forte valeur.

L'offre dans le temps

Un graphique de répartition dit qui détient quoi et rien sur le quand. Le calendrier ci-dessous est la figure la plus utile, car le risque d'un token est rarement dans le partage, il est dans le cliff.

L'intention de conception est que le flux de frais suive l'activité réelle plutôt que la spéculation : le protocole gagne quand des actifs sont déposés et réclamés, ce qui n'arrive que si quelqu'un accepte de payer pour une visite vérifiée.

Ce que le token ne fait délibérément pas

• Il ne fixe pas de taux entre une unité de jeu capturée et un token. Le jeu valorise une capture, le marché valorise le token, et le protocole ne prétend pas faire le pont entre les deux.
• Il n'est pas nécessaire pour jouer. Capturer, l'XP et les défis sont gratuits, et un joueur qui ne touche jamais au token génère quand même les arrivées que paie un éditeur.
• Il ne conditionne pas le dépôt à une détention minimale. Le staking achète une priorité quand des campagnes se concurrencent, pas le droit de publier.

Un whitepaper qui décrit un token et pas une activité décrit la moitié d'un système. Il y a deux sources de revenus et elles viennent de côtés opposés du réseau, ce qui est voulu : ni l'une ni l'autre ne suffirait à le faire tenir.

Le dépôt, payé par les éditeurs

La source principale. Un éditeur finance les récompenses et paie en plus un frais de dépôt, pondéré par la surface que l'actif occupe, pour combien de temps, et à quel point cette surface est disputée. C'est le frais qui croît avec la valeur créée par le réseau, parce qu'il porte sur ce que les éditeurs achètent réellement : l'arrivée.

Le pass et la boutique, payés par les joueurs

Optionnels, et bornés à dessein. Un pass saisonnier court sur quatre-vingt-dix jours et oriente la pondération des spawns vers des pièces plus rares, avec une réclamation rare hebdomadaire et un boost inclus. Les boosts individuels sont vendus à part : un boost de rareté, un aimant à spawns, un multiplicateur d'XP, ou un lot des trois.

Pourquoi ce partage a la bonne forme

Les dépenses des joueurs sont élastiques, saisonnières et plafonnées par ce qu'une personne consacre à un loisir. Les dépenses des éditeurs sont une ligne marketing, jugée face à un coût par arrivée qui a une vraie alternative de comparaison. La première garde la lumière allumée au début, quand il y a plus de joueurs que de campagnes. La seconde est ce que devient l'activité, et cela ne marche que si la première ne dégénère jamais en pay-to-win, car un réseau de joueurs payants qui capturent tout rapporte des arrivées sans valeur pour le lieu.

Ce protocole comporte un nombre inhabituel de constantes réglables : bornes de rayon, seuils de confiance, pondération des frais de dépôt, part des frais rendue aux seekers, et l'échelle de capture elle-même. Chacune est une décision de politique déguisée en valeur de configuration, et prétendre le contraire, c'est ainsi que des protocoles finissent gouvernés par la dernière personne à avoir modifié un fichier.

La position par étapes, dite franchement

La gouvernance n'est pas active. Les paramètres sont aujourd'hui fixés par l'équipe centrale et modifiés via des migrations consignées et vérifiables. Nous n'allons pas appeler cela décentralisé, parce que ça ne l'est pas.

La raison du délai n'est pas la réticence. Voter sur une économie sans volume relève du théâtre : la participation est faible, une poignée de détenteurs décide, et les décisions portent sur des paramètres que personne n'a assez de données pour juger. La gouvernance prend son sens quand il existe un vrai flux de frais, car un changement de paramètre a alors une conséquence mesurable dont on peut débattre.

Ce qui sera gouverné, et ce qui ne le sera pas

• Gouverné : la pondération des frais, la part des frais du protocole revenant aux seekers, l'allocation de la trésorerie, les bornes de rayon et les seuils de confiance ouverts aux actifs de forte valeur.
• Gouverné avec délai : tout ce qui change la valeur d'actifs déjà déposés. Une campagne financée sous une grille de frais devrait s'achever sous celle-ci.
• Non gouverné : les engagements de confidentialité du chapitre treize. Les limites de conservation et le refus de publier des données de déplacement ne sont pas des paramètres, et un vote n'est pas un moyen légitime de les affaiblir.
• Non gouverné : les issues de réclamations individuelles. Une réclamation refusée relève du règlement des litiges, pas d'un scrutin.

Un protocole qui paie des gens pour être quelque part invite des gens à mentir sur l'endroit où ils sont. Être précis sur les attaques est plus utile que d'affirmer que le système est sûr.

Attaques contre lesquelles nous nous défendons

• Falsification du GPS, atténuée en exigeant que l'environnement radio et la trace de mouvement corroborent le point, et par une attestation d'appareil qui détecte les systèmes modifiés.
• Farming Sybil, atténué par le coût physique du déplacement et par des limites de réclamation par appareil dans un rayon et une fenêtre de temps.
• Attaques par relais, où un vrai appareil sur place signe pour un utilisateur distant, atténuées en liant l'attestation à l'instance de l'application et à la session, et en limitant le débit de réclamations par appareil.
• Fermes d'émulateurs, atténuées par l'attestation, à laquelle les émulateurs échouent, et par des traces de mouvement statistiquement distinguables d'une vraie marche.
• Spawns déclarés par le client, empêchés plutôt qu'atténués : seul le serveur annonce ce qui existe et où, un client modifié peut donc mentir sur ce qu'il voit sans rien y gagner.
• Réclamations en double, empêchées en prenant un verrou avant l'évaluation, pour que deux personnes visant la dernière unité ne s'entendent pas toutes deux dire qu'elles l'ont.

Limites que nous acceptons

Un attaquant suffisamment déterminé, avec du matériel modifié et une présence physique sur un site, peut extraire de ce site plus de valeur qu'un utilisateur honnête. Nous bornons les dégâts par des plafonds par lieu plutôt que de prétendre que c'est impossible. Le positionnement en intérieur reste nettement moins précis qu'en extérieur, les actifs intérieurs utilisent donc des rayons plus larges et s'appuient davantage sur l'empreinte radio. Et aucun appareil grand public ne peut prouver qu'un humain plutôt qu'un appareil était présent : un téléphone dans une camionnette de livraison bouge encore comme un téléphone dans une poche.

Risques qui ne sont pas des attaques

• Dépendance aux plateformes. L'attestation appartient à Apple et Google. Un changement de politique chez l'un ou l'autre pourrait affaiblir du jour au lendemain le signal le plus fort de la pile, et il n'existe pas de version de ceci qui contourne le système d'exploitation.
• Disponibilité de la chaîne. Une chaîne arrêtée, ce sont des réclamations en file. Le protocole relance plutôt que d'abandonner, mais une personne debout dans la rue ne vit pas une relance comme une réussite.
• Sécurité physique. Récompenser les gens pour aller quelque part met des gens quelque part. Les actifs sont posés aux carrefours plutôt qu'à l'intérieur des emprises de bâtiments, les drops de forte valeur évitent les propriétés privées, et l'application affiche un avertissement de sécurité. C'est une contrainte de conception, pas une clause de non-responsabilité.

Un relevé des endroits où quelqu'un se rend révèle son domicile, son travail, sa santé, sa religion et ses relations. Bâtir un réseau sur des réclamations de localisation, c'est accepter cette responsabilité, et la conception responsable consiste à en garder le moins possible.

• Le suivi continu n'est jamais nécessaire. L'application demande une position quand vous tentez une réclamation, pas en arrière-plan.
• Les données brutes de capteurs et de radio servent à noter une réclamation puis sont écartées après une courte durée de conservation.
• Ce qui est écrit on-chain, c'est qu'une réclamation à une coordonnée publique a abouti, la même information qu'un commerce sachant qu'un bon a été utilisé.
• Votre historique de déplacements reste sur votre appareil. Le protocole n'en a pas besoin et n'en veut pas.
• Les éditeurs reçoivent des décomptes agrégés, jamais des traces individuelles.

Le problème que nous n'avons pas résolu

Comme les enregistrements de réclamation sont publics et permanents par nature de la chaîne, un observateur déterminé peut corréler les réclamations faites par un même portefeuille à travers plusieurs lieux. C'est une vraie faiblesse, inhérente au règlement sur un registre public. Qui veut l'éviter devrait utiliser des portefeuilles distincts pour des contextes distincts, et l'application le rend facile au lieu de l'enfouir, mais un réglage par défaut qui suppose que l'utilisateur connaisse le problème n'est pas un correctif.

Trois régimes touchent ce protocole en même temps, ce qui est inhabituel et mérite d'être dit explicitement plutôt que renvoyé en note de bas de page.

Protection des données

Dans la plupart des droits modernes de la protection des données, la localisation frôle les catégories particulières, et le protocole est bâti selon la lecture la plus stricte plutôt que la plus commode. La position est collectée pour une finalité annoncée au moment d'une réclamation, conservée seulement le temps qu'exigent la notation et le règlement des litiges, et jamais agrégée en profil de déplacement. Là où un régime accorde un droit d'effacement, l'enregistrement off-chain peut être supprimé ; l'enregistrement de réclamation on-chain non, ce qui est une limite du registre et est divulgué plutôt qu'enjolivé.

Qualification du token

$SEEK est conçu comme un actif d'usage et de coordination, et l'utilité décrite au chapitre neuf est réelle et non décorative. C'est une position de conception, pas une conclusion juridique. La qualification varie selon la juridiction, évolue dans le temps, et n'est pas quelque chose qu'un whitepaper peut trancher en l'affirmant. La disponibilité est donc restreinte là où les règles locales l'exigent.

Récompenses, hasard et la frontière avec le jeu d'argent

La capture comporte un tirage, ce qui la place près d'une frontière qui varie selon les pays. Deux propriétés la maintiennent du bon côté dans la plupart des régimes et sont tenues volontairement : la participation ne coûte rien, et les articles payants ajustent des probabilités et des cadences au lieu d'être des mises à gain variable. Un pass achète une pondération et un boost achète un multiplicateur ; ni l'un ni l'autre n'est une mise qui peut être perdue. Là où une juridiction le lit autrement, le palier payant est retiré plutôt que discuté.

SeekAR est en ligne sur iOS et Android avec les drops géolocalisés, le rendu AR et le portefeuille social. La pile de vérification exécute aujourd'hui les signaux GNSS, attestation et continuité du mouvement ; l'empreinte radio est en déploiement progressif. L'attestation est imposée derrière un drapeau, et c'est son état honnête : la voie de refus est construite et l'interrupteur n'a pas été basculé pour chaque surface.

Le créateur de campagnes en glisser-déposer est terminé. Vient ensuite le portail en libre-service qui ouvre le dépôt au-delà des partenariats accompagnés, et l'analytique des arrivées qui va avec. À côté figurent l'événement de génération du token, le mode événement en direct, les saisons et le scan d'objets. La gouvernance suit dès qu'il y aura assez de flux de frais réel pour que les décisions de paramètres aient du sens, pour les raisons exposées au chapitre onze.

Ce que nous ne promettons pas

• Une date pour la gouvernance. Elle dépend du volume, et le volume n'est pas une date.
• Une précision équivalente en intérieur. C'est un problème difficile et la réponse honnête, ce sont des rayons plus larges en intérieur pour un bon moment.
• Un déploiement multi-chaînes. Les exigences de latence et de coût du chapitre cinq sont étroites, et une seconde chaîne qui ne les remplirait pas serait une décision marketing plutôt que technique.

Le détail phase par phase se trouve sur la page roadmap, tenue à jour au fil des livraisons.

Les termes employés dans ce document, avec le sens qu'ils ont ici plutôt que celui qu'ils ont en général.