Verdien de GitHub en domeinverificatie badges.
Verificatie gebeurt in het dashboard, niet via de SDK. Voltooi het bewijs - een GitHub OAuth-handshake of een DNS TXT-record - en de badge verschijnt op het openbare profiel van de agent. Badges worden periodiek opnieuw gecontroleerd. Tegenpartijen zweven over de badge om te zien wie wat en wanneer heeft geverifieerd, wat het vertrouwenssignaal is waar serieuze betalers naar op zoek zijn.
Voordat je begint.
- Een bestaande agent en dashboardtoegang voor zijn werkruimte (zie de add-payments-to-agent gids).
- Voor de GitHub-badge: mogelijkheid om de Blockchain0x-app te autoriseren op de GitHub-organisatie of gebruiker die de agent vertegenwoordigt.
- Voor de domeinbadge: controle over DNS voor het apex-domein dat je wilt verifiëren (of welke host je DNS-provider ondersteunt voor TXT-records).
- 10 minuten wandklok voor DNS-verificatie (de meeste verspreiden zich binnen een minuut, maar geef tot 10).
- Bekendheid met het agent betalingsidentiteit concept - badges zijn een van de lagen.
Verifieer met GitHub.
De GitHub-badge bewijst dat de agent is gekoppeld aan een specifieke GitHub-gebruiker of organisatie. Klik in het verificatietabblad van de agent in het dashboard op Verifiëren met GitHub. Je wordt doorgestuurd naar het standaard OAuth-toestemmingsscherm van GitHub, waar de persoon die die identiteit bezit leesrechten verleent voor openbare profielinformatie. Er is geen SDK-aanroep - dit is een eenklik-dashboardflow.
We vragen alleen om leesrechten voor het openbare profiel (gebruikersnaam, accountleeftijd, openbare artefacten) - geen schrijfrechten, geen privé-repositories. Zodra de toestemming is verleend, verschijnt de badge op de openbare pagina van de agent binnen een minuut of twee, met de geverifieerde handle.
Verifieer een domein.
De domeinbadge bewijst controle over een geregistreerd DNS-domein - het sterkste signaal dat een tegenpartij kan lezen. Kies in het verificatietabblad Domein en voer jouw apex of subdomein in. Het dashboard toont een unieke token om als een TXT-record te publiceren. Voeg het toe bij jouw DNS-provider, klik vervolgens op Verifiëren; we vragen DNS en draaien de badge om zodra de token overeenkomt.
Publiceer de token die het dashboard toont als een TXT-record:
# The dashboard shows the exact host and token to publish.
# Most providers use a subdomain host for the verification record.
Type: TXT
Name: _blockchain0x.yourcompany.com
Value: <the token shown in the dashboard>
TTL: 300 (5 minutes is fine)Bevestig dat de badge live is.
Het dashboard toont de status van elke badge. GitHub draait meestal binnen een minuut naar geverifieerd na de OAuth-toestemming; domeinen zijn afhankelijk van DNS-propagatie maar worden meestal binnen ongeveer 10 minuten voltooid. Er is niets om vanuit jouw code te poll - het is een dashboardstatus.
Once verified, the agent's public page (wallet.blockchain0x.com/a/<slug>) shows the badge alongside the agent's other identity claims. Hovering the badge reveals which method earned it and when. That hover popover is what counterparties read before approving a payment or allowlisting your wallet.
Vier fouten die verificatie vertragen of breken.
Verifiëren van de verkeerde GitHub-identiteit
Als je je persoonlijke GitHub-account gebruikt voor de OAuth-handshake maar de agent vertegenwoordigt een organisatie, zal de badge zeggen 'gecertificeerd door @yourhandle' in plaats van 'gecertificeerd door yourcompany'. Tegenpartijen die de organisatie verwachten, zullen sceptisch kijken naar de badge van de persoonlijke handle. Gebruik een GitHub-account dat overeenkomt met de geclaimde identiteit van de agent, en geef de voorkeur aan verificatie op organisatieniveau boven gebruikersniveau wanneer mogelijk.
DNS TXT-records gepubliceerd op de verkeerde host
Sommige DNS-hosts accepteren het TXT-record op de apex (gewoon '@'), anderen vereisen een subdomein (typisch '_blockchain0x'). Als je verificatie 'in afwachting' blijft na 30 minuten, is het record bijna altijd op de verkeerde locatie. De flow-respons bevat zowel de verwachte locatie als de verwachte waarde - controleer beide nogmaals en verifieer extern met 'dig TXT yourdomain.com' voordat je aanneemt dat de API fout is.
Vergeten dat verificatie vervalt
Verificatiebadges worden periodiek opnieuw gecontroleerd. Als je DNS TXT-record wordt verwijderd tijdens een hostmigratie, of als je de OAuth-toestemming van de agent op GitHub verwijdert, mislukt de volgende hercontrole en wordt de badge automatisch verwijderd. Tegenpartijen merken het. Houd de verificatie-artikelen op hun plaats als onderdeel van je bestaande infrastructuur en beschouw hun onopzettelijke verwijdering als een storing.
De badge tonen maar geen vertrouwen opbouwen eromheen
Badges zijn noodzakelijk maar niet voldoende. Een tegenpartij die naar de openbare pagina van je agent kijkt, zal de badge wegen naast recente transactiegeschiedenis, de reden-voor-betaling patronen van de agent, en enig sociaal bewijs in je bredere product. Behandel de badge als de basis - het verdienen ervan maakt je in aanmerking voor serieuze tegenpartijen, maar het maakt ze niet automatisch vertrouwd met jou. Bouw de rest van de vertrouwenssignalen eromheen.
Nadat de badges zijn geplaatst.
Met de identiteit geverifieerd, voltooi de checklist voor productiehardening: een beveiligingsreview van de wallet zelf, uitgavencontroles als de agent uitbetaalt, en de standaard webhookpatronen zodat betalingen niet door de mazen glippen tijdens operationele haperingen.
Beveilig je agent wallet voordat je live gaat
Stel agent uitgavencontroles in die prompt-injectie overleven
De webhook-patronen waar ontwikkelaars het meest naar vragen
Volledige referentie op docs.blockchain0x.com. Productoppervlak: Agentidentiteit.