Passerelles de notification

• Accepter les événements de notification du protocole et les livrer par tout transport
• Retourner des accusés de livraison
• Vérifier les points de contact des utilisateurs par codes à usage unique ou défis anti-bot
• Enregistrer les canaux, régions et tarifs pris en charge dans le registre de services

5 000 OPEN, exigés par le programme de staking lorsque vous misez contre le rôle de passerelle de notification. Cela achète une responsabilité économique et une résistance aux attaques Sybil plutôt qu’un traitement préférentiel : rien ne route le trafic de notifications par stake aujourd’hui, donc atteindre le minimum rend une passerelle éligible, pas favorisée.

Rien encore. Le modèle visé est une part d’un petit frais fixe en OPEN qu’un participant paie pour activer les notifications sur un échange, le reste étant réparti entre les allocations de trésorerie et d’écosystème — mais aucun de ces frais n’existe nulle part dans le protocole aujourd’hui et aucune récompense de passerelle n’est versée. À traiter comme une intention de design, pas un revenu.

• →Implémenter la spécification de notifications publiée
• →Enregistrer les métadonnées de la passerelle : canaux, version du protocole, tarifs, endpoints
• →Accepter que les passerelles ne reçoivent que le minimum d’information nécessaire pour livrer — jamais les soldes, les preuves de litige ni un état de marché sans rapport

• OFS-6000OpenFiat Notification Protocol (ONP)
• OFS-1500Service Registry Protocol (SRP)