> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Interoperabilidade da Travel Rule: acesse um VASP Didit > VASPs trocam dados da Travel Rule com clientes Didit via travel addresses, endpoints TRP públicos, callbacks, coleta por e-mail e registro sunrise. Esta página é para o **outro lado** de uma troca do [Didit Travel Rule](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md): a VASP contraparte (ou a equipe de engenharia dela) que precisa enviar dados de Travel Rule para uma VASP que usa a Didit, ou recebê-los dela. Tudo o que está documentado aqui é infraestrutura pública operada pela Didit. Você não precisa de uma conta Didit, de uma chave de API nem de qualquer relação comercial com a Didit para interoperar: a integração mais profunda exige apenas HTTPS e JSON. ## Como a Didit roteia uma transferência Quando um cliente da Didit envia uma transferência, a Didit tenta estes canais em ordem estrita de prioridade e usa o primeiro que consegue alcançar você: | Prioridade | Canal | O que isso significa para você | | - | - | - | | 1 | `INTERNAL` | Os dois VASPs operam na Didit: a transferência é liquidada dentro da plataforma e nenhuma chamada externa é feita. | | 2 | `TRP` | Você expõe um endpoint do Travel Rule Protocol (TRP), ou o cliente da Didit conhece seu [Travel Address](#travel-addresses). A Didit chama seu endpoint de consulta TRP de máquina para máquina, para transferências de `BTC`, `ETH` e `USDC` (`USDC` quando a transferência indica a rede em que é movimentada). | | 3 | `GTR` | Uma associação ao Global Travel Rule (GTR) está ativa para o remetente e você pode ser identificado por um código de VASP do GTR. A Didit lê sua resposta na resposta enviada pelo GTR ou consultando periodicamente o status da requisição. | | 4 | `TRUST` | Uma associação ao TRUST está ativa para o remetente e você pode ser identificado por um id de associação do TRUST. Somente envio: veja o aviso abaixo. | | 5 | `VERIFYVASP` | Uma associação ao VerifyVASP está ativa para o remetente e você pode ser identificado por um id do VerifyVASP. A Didit lê sua resposta consultando periodicamente o status da verificação. | | 6 | `SYGNA` | Uma associação ao Sygna Bridge está ativa para o remetente e você pode ser identificado por um código de VASP do Sygna. A Didit oferece suporte nativo ao protocolo Sygna (IVMS101 criptografado com ECIES, requisições de permissão assinadas) e lê sua resposta de permissão consultando periodicamente o status da transferência: o callback Sygna da Didit ainda não está ativo. | | 7 | `EMAIL` | Nenhum canal de protocolo está disponível: em vez disso, seu contato de conformidade recebe um [link de retirada por e-mail](#acesso-por-e-mail) de uso único. | > [!WARNING] > > **A Didit não consegue receber uma resposta `TRUST` e ainda não aceita transferências enviadas a ela por uma rede.** > Pelo `TRUST`, a transferência de um cliente da Didit chega até você, mas sua resposta não consegue voltar, e a transferência expira no prazo de confirmação do remetente em vez de ser concluída. > Pelo `GTR`, `VERIFYVASP` e `SYGNA`, a Didit lê sua resposta na própria rede, pela resposta dela ou consultando periodicamente o status da transferência. A tabela acima cobre as transferências que um cliente da Didit envia. Quando você envia uma transferência a um cliente da Didit, a Didit só consegue recebê-la como uma [consulta de transferência](#post-/trp/inquiries//) `TRP`, assim que o host TRP público da Didit estiver ativo (ele ainda não responde, veja [Endpoints TRP](#endpoints-trp)), ou, após a liquidação, como um [registro de sunrise](#sunrise-transferências-liquidadas-antes-da-troca): hoje, nenhum canal de rede e nenhum canal de e-mail entrega uma transferência de entrada a um cliente da Didit. Os canais de rede (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) funcionam por meio de uma associação do lado remetente. Hoje, essa precisa ser a associação conectada do próprio cliente da Didit: a Didit ainda não tem associação de plataforma em nenhuma dessas redes e está em processo de onboarding como provedora. O GTR não está incluído por padrão, e o mesmo requisito de associação se aplica às quatro redes. O remetente deve verificar o objeto `networks` em [Obter configurações da Travel Rule](https://docs.didit.me/pt-br/management-api/travel-rule/get-settings.md): `didit` significa que a associação da Didit inclui essa aplicação como participante próprio na rede, `own` significa uma associação conectada do cliente, `off` significa que o roteamento da plataforma está desativado e `unavailable` significa que nada pode enviar por essa rede para a aplicação ainda. Até que a Didit tenha uma associação de plataforma, nenhuma rede informa `didit`. Ativar a Travel Rule não ativa uma associação de rede. Veja [Redes da Travel Rule](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule-networks.md) para saber o que cada rede alcança hoje. Se você estiver em uma dessas redes e o cliente da Didit tiver associação própria nela, compartilhe seu identificador de rede com ele e a transferência chegará até você pela rede que você já opera. Pelo `SYGNA`, sua resposta de permissão conclui ou recusa a transferência: a Didit consulta o status da transferência a cada 5 minutos e também registra `https://trp.didit.me/sygna/callbacks/permission/{token}/` como callback de cada requisição de permissão, com um token gerado para aquela transferência. Esse callback fica no host TRP público da Didit, que ainda não atende requisições. Um `permission_status` igual a `ACCEPTED` move a transferência do remetente para `COMPLETED`, e `REJECTED` a move para `COUNTERPARTY_VASP_GENERAL_DECLINE`, ou para `COUNTERPARTY_MISMATCHED_DATA` quando o `reject_code` é `BVRC007` (o nome do beneficiário não corresponde). O callback exige sua assinatura: ele responde `401` com `{"status": "INVALID_SIGNATURE"}` sem uma assinatura válida, `404` para um token desconhecido e `200` novamente para uma decisão que já aplicou. Sem nenhuma associação em comum, o `TRP` é o caminho para o qual você deve se preparar: compartilhe seu Travel Address com o cliente da Didit, e as transferências dele chegarão ao seu endpoint TRP. Uma resposta que você dá na resposta à consulta conclui ou recusa a transferência imediatamente; uma resposta que você envia depois ao callback da Didit precisa do host TRP público da Didit, que ainda não está ativo. Quando nenhum dos canais consegue identificar você, a Didit executa mais uma etapa de resolução: **atribuição por análise de blockchain**. A carteira de destino é resolvida com base em dados de análise de blockchain e, quando é atribuída à sua exchange ou ao seu serviço de custódia, a Didit registra seu nome no diretório de VASPs dela e tenta novamente os canais com ele. Isso significa que você pode ser identificado mesmo quando o remetente não forneceu nada além de um endereço de carteira. As transferências atribuídas só são roteadas automaticamente para você quando sua entrada no diretório tem uma rota: um endpoint `TRP` verificado, uma listagem em rede ou um contato de conformidade (veja [Como entrar no diretório de VASPs da Didit](#como-entrar-no-diretório-de-vasps-da-didit)). A cadeia completa de resolução é, portanto: um cliente da Didit que comprovou o controle da carteira (`INTERNAL`) e o Travel Address que o remetente armazenou para ela, depois os canais de protocolo e de rede e, por fim, a análise de blockchain. ## Travel addresses Todo VASP da Didit com a Travel Rule ativada tem um **travel address**: uma string compacta que começa com `ta` e codifica a URL do seu endpoint TRP próprio de consulta de transferências. Os clientes da Didit consultam o seu nas configurações da Travel Rule e o compartilham com as contrapartes; quando um cliente da Didit fornece o dele a você, você tem tudo o que é necessário para alcançá-lo via TRP. A codificação segue a convenção de travel address do TRP: * Remova o prefixo `ta`. * Decodifique o restante com Base58Check (alfabeto do Bitcoin, checksum double-SHA256). * Os bytes decodificados são a URL de consulta sem o esquema; adicione `https://` no início. * A URL sempre contém o par de consulta `t=i` (tipo: consulta). Um travel address da Didit decodificado tem um destes dois formatos: ``` https://trp.didit.me/trp/inquiries/{profile_uuid}/?t=i https://trp.didit.me/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/?t=i ``` `{profile_uuid}` identifica o perfil de VASP hospedado: envie suas consultas de transferência via POST para essa URL e, antes, consulte o [endpoint de identidade](#get-/trp/identity//) correspondente para confirmar com quem você está falando. O segundo formato é um travel address **por carteira**: ele indica uma carteira específica do cliente da Didit (`receiving_travel_address` no catálogo de endereços dele), de modo que sua consulta chega a essa carteira sem que o cliente precise identificá-la pelo número da conta ou pelo nome do titular. Ele responde `404` assim que a carteira é excluída ou registrada como pertencente a outro VASP. ## Endpoints TRP A Didit usa a versão `3.2.1` da API TRP na URL base `https://trp.didit.me`. Todos os endpoints trocam JSON por HTTPS. > [!WARNING] > > O host TRP público da Didit ainda não disponibiliza estes endpoints. Até que isso aconteça, uma consulta TRP ou uma requisição de identidade destinada a um cliente da Didit não pode ser entregue; esta seção descreve o contrato que o host atenderá quando estiver ativo. | Método | Caminho | Finalidade | | - | - | - | | `GET` | `/identity` | Identidade do operador da plataforma (também disponível em `/trp/identity`). | | `GET` | `/trp/identity/{profile_uuid}/` | Identidade de um perfil de VASP hospedado. | | `POST` | `/trp/inquiries/{profile_uuid}/` | Envia uma consulta de transferência a um VASP hospedado. | | `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | Envia uma consulta de transferência para uma carteira específica de um VASP hospedado (um Travel Address por carteira). | | `POST` | `/trp/callbacks/resolution/{token}/` | Resolve uma consulta que a **Didit** enviou a você (aprovar ou rejeitar). | | `POST` | `/trp/callbacks/confirmation/{token}/` | Confirma ou cancela uma transferência que a Didit aprovou para você. | Dois cabeçalhos TRP são relevantes: * `api-version` - a versão do protocolo TRP que você usa, por exemplo `3.2.1`. Obrigatório nas consultas e nos dois callbacks. * `request-identifier` - seu id exclusivo para a requisição, devolvido nos cabeçalhos da resposta. Obrigatório nas consultas e nos dois callbacks. Uma requisição aos endpoints de consulta ou de callback sem os dois cabeçalhos retorna `400`. Toda resposta da Didit inclui `api-version: 3.2.1` e devolve o seu `request-identifier`. ### GET /identity Retorna a identidade do operador da plataforma. Nenhum cabeçalho é obrigatório. ```bash theme={null} curl https://trp.didit.me/identity ``` ```json theme={null} { "name": "Didit", "lei": "", "x509": "" } ``` ### GET /trp/identity/{profile_uuid}/ Retorna a identidade do VASP específico com o qual você está prestes a fazer a troca. Use-a para verificar o nome e o LEI antes de enviar dados pessoais (PII). A Didit faz a mesma verificação no sentido inverso quando é ela quem inicia: se a identidade informada pelo seu endpoint não corresponder ao LEI ou ao nome esperado, a troca é interrompida. ```bash theme={null} curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/ ``` ```json theme={null} { "name": "Bene CASP GmbH", "lei": "5493001KJTIIGC8Y1R12", "x509": "" } ``` Retorna `404` quando o perfil não existe ou quando a configuração de Travel Rule dele está desativada. ### POST /trp/inquiries/{profile_uuid}/ Envia uma consulta de transferência. Você é o VASP remetente e o cliente da Didit é o VASP beneficiário. ```bash theme={null} curl -X POST https://trp.didit.me/trp/inquiries/11111111-2222-3333-4444-555555555555/ \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 7f6a1c1e-0a63-4b1f-9f6e-7dcd7c3f1a01" \ -d '{ "asset": { "dti": "X9J9K872S" }, "amount": 250000000000000000, "callback": "https://trp.yourvasp.example/callbacks/inquiry/abc123", "IVMS101": { "originator": { "originatorPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"] }, "beneficiary": { "beneficiaryPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"] } } }' ``` | Campo | Tipo | Descrição | | - | - | - | | `asset.dti` | string | Obrigatório. O Digital Token Identifier (ISO 24165) do ativo transferido. Uma consulta sem ele recebe `400`; o `asset.slip0044` anterior à versão 3.2.0 não é lido. | | `amount` | number | Obrigatório. Valor inteiro na menor unidade do ativo (unidades base conforme as casas decimais do DTI). Qualquer notação JSON de um número inteiro é aceita, inclusive a forma com expoente, assim como uma string de dígitos. Uma fração, ou um valor grande demais para ser registrado, recebe `400`. | | `callback` | string | Obrigatório. URL `http(s)` pública e absoluta do seu lado, para a qual a Didit envia a resolução da consulta (`https` recomendado). Uma nova tentativa que repete o mesmo `callback` é associada à consulta que ela repete. | | `IVMS101` | object | Obrigatório. O payload IVMS 101: `originator.originatorPersons` e `beneficiary.beneficiaryPersons` (a Didit lê o primeiro `naturalPerson` de cada um; dados de pessoa jurídica não são lidos), além dos arrays de carteiras `accountNumber`. | Nesta via, os ativos são identificados por DTI, e um DTI identifica um token em uma única blockchain. Hoje a Didit mapeia `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) e `USDC` em nove redes, e outros ativos são adicionados ao longo do tempo. Consulte [Identificadores de ativos TRP](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md#identificadores-de-ativos-trp) para ver a lista completa. Uma consulta com um DTI que a Didit não reconhece ainda é aceita e apresentada ao VASP beneficiário com o DTI como código do ativo. Uma resposta `200` significa que a consulta foi aceita para processamento; `400` significa cabeçalhos TRP ausentes ou corpo inválido, `404` significa que o perfil (ou a carteira de um endereço por carteira) é desconhecido ou está desativado, e `422` significa que a requisição usa uma extensão TRP: a Didit não oferece suporte a nenhuma, então um cabeçalho `api-extensions` ou uma chave `extensions` no corpo é recusado. Reenviar o mesmo `request-identifier` é idempotente: a consulta original é reutilizada em vez de duplicada. Em seguida, a Didit cria a transferência de entrada na aplicação do cliente e a resolve com base no catálogo de endereços de carteiras e na política do cliente. Ela identifica o beneficiário pela carteira indicada em um Travel Address por carteira; caso contrário, pelo primeiro endereço de carteira em `IVMS101.beneficiary.accountNumber`; ou, sem nenhum, pelo nome em `beneficiaryPersons[0].naturalPerson` comparado às entradas de carteiras verificadas do cliente. A resposta `200` traz a resposta quando a Didit pode fornecê-la imediatamente: * `{"approved": {"address": "...", "callback": "..."}}` quando a consulta foi aprovada automaticamente. A Didit não envia essa aprovação também ao seu `callback`. * `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}` quando a consulta não indica nem o beneficiário nem um endereço de carteira; por isso, sempre inclua os dois. * `{"version": "3.2.1"}` quando a decisão depende do cliente da Didit. A **resolução** chega depois, como um POST para a sua URL de `callback`, com um dos dois corpos abaixo. ```json theme={null} { "approved": { "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/" } } ``` ```json theme={null} { "rejected": "Wallet ownership denied by beneficiary VASP" } ``` A aprovação pode ser automática (quando o VASP beneficiário ativa a aceitação automática e o beneficiário corresponde a uma entrada de carteira verificada na blockchain do ativo) ou ocorrer após uma revisão manual ou uma prova de propriedade da carteira do lado do beneficiário; portanto, considere um possível atraso entre a consulta e a resolução. Uma consulta nunca corresponde a uma carteira que o cliente da Didit registrou como sendo de outro VASP, e o nome do seu VASP em `originatingVASP` é o que o cliente da Didit vê como VASP remetente da transferência. A Didit não define prazo para uma consulta que você envia, e um cliente da Didit que a cancela não envia nenhuma rejeição a você; por isso, aplique seu próprio timeout. Depois de receber uma aprovação e transmitir a transferência on-chain, encerre a troca enviando um POST para a URL `approved.callback` que você recebeu: ```bash theme={null} curl -X POST "https://trp.didit.me/trp/callbacks/confirmation/{token}/" \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 0b8e2f4a-6c1d-4e9a-8f3b-2d7c5a1e9f60" \ -d '{ "txid": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060" }' ``` Em vez disso, envie `{ "canceled": "reason" }` para a mesma URL se você interromper a transferência. `txid` muda a transferência do lado do beneficiário para `FINISHED`; `canceled` a muda para `CANCELLED`. Os dois callbacks respondem `204` após o processamento, `404` para um token desconhecido ou para uma transferência que não está mais aguardando esse callback, e `400` para um corpo que não contém nenhum dos dois campos do callback. ### Como resolver as consultas que a Didit envia para você Quando um cliente da Didit inicia uma transferência para você via TRP, a Didit: 1. Busca `/identity` na raiz do host da sua URL de consulta (`https://{your-host}/identity`) e verifica se o nome e o LEI informados correspondem ao que o cliente espera. Quando a rota vem do diretório da Didit, o seu `/identity` deve informar o LEI dessa entrada do diretório. 2. Envia via POST uma consulta de transferência para a sua URL de consulta, com o mesmo formato de corpo descrito acima: `asset.dti`, um `amount` em unidades base como número JSON, um `callback` e o payload `IVMS101`. Apenas uma resposta `2xx` conta como entregue. Uma `3xx` é recusada, porque redirecionamentos não são seguidos, e qualquer outra resposta é registrada na linha do tempo da transferência do cliente com o seu código de status, por exemplo `refused by counterparty (HTTP 403): ...`. As duas chamadas levam os dois cabeçalhos TRP, e a Didit não segue redirecionamentos HTTP nelas, então sirva `/identity` e a URL de consulta diretamente. Se `/identity` estiver inacessível, não informar nenhum LEI ou informar um LEI diferente quando o cliente tiver fornecido um, ou informar um nome que não corresponda, a Didit para antes de enviar a consulta e a transferência do cliente passa para `COUNTERPARTY_VASP_NOT_REACHABLE`. Se, em seguida, o POST da consulta falhar ou o seu endpoint responder com status `4xx` ou `5xx`, a transferência também passa para `COUNTERPARTY_VASP_NOT_REACHABLE`. O `callback` dessa consulta aponta para o endpoint de resolução da Didit (`/trp/callbacks/resolution/{token}/`). Responda enviando via POST os mesmos corpos de resolução que a Didit usa: `{ "approved": { "address": "...", "callback": "..." } }` para aprovar (o seu `callback` é onde a Didit vai enviar a confirmação on-chain), ou `{ "rejected": "reason" }` para recusar. Envie os dois cabeçalhos TRP junto. A Didit responde `204` quando a requisição é processada, `404` quando a transferência não está mais aguardando uma resolução e `400` para uma aprovação sem `address` ou cujo `callback` não seja uma URL `http(s)` pública que a Didit vá chamar. Após a aprovação, a transferência na Didit passa para `COMPLETED`; assim que o cliente informa o hash on-chain, a Didit envia via POST `{ "txid": "..." }` para o callback de confirmação que você forneceu (ou `{ "canceled": "reason" }` se a transferência for cancelada antes). > [!NOTE] > > Os tokens de callback são segredos destinados a uma única finalidade e impossíveis de adivinhar, gerados por transferência: trate as URLs de retorno completas como confidenciais e observe que uma resolução só é aceita enquanto a transferência ainda estiver aguardando uma. ## Acesso por e-mail Se nenhum canal de protocolo alcançar você e o cliente da Didit tiver fornecido o seu e-mail de conformidade, a Didit recorre ao e-mail: o seu contato de conformidade recebe uma mensagem com o nome do VASP remetente e um link seguro de acesso de uso único. Não é preciso conta, chave de API nem integração: o token do link é a autenticação. Ao abrir o link, você vê a troca pendente; a API subjacente (que a página hospedada chama em seu nome) é pública: ```bash theme={null} curl https://verification.didit.me/v3/travel-rule/pickup/{token}/ ``` ```json theme={null} { "originator_vasp_name": "Origin CASP SL", "amount": "0.250000000000000000", "currency": "ETH", "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "status": "AWAITING_COUNTERPARTY" } ``` `amount` é o decimal armazenado sem alterações, por isso traz as 18 casas decimais completas. ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \ -H "Content-Type: application/json" \ -d '{ "decision": "accept", "beneficiary_name": "Ana Diaz" }' ``` `decision` é `accept` ou `decline`; ao aceitar, informe o nome do beneficiário conforme consta nos seus registros para que a parte remetente possa fazer a correspondência de nomes, ou envie a sua resposta IVMS 101 completa como `ivms_response`, cujo nome de beneficiário passa então a prevalecer. Ao recusar, você pode informar um `decline_reason` (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` ou `other`) e um `decline_detail` de até 512 caracteres, obrigatório para `other`. Uma aceitação sem `beneficiary_name` é registrada como divergência quando o remetente forneceu um nome de beneficiário, a menos que o remetente tenha desativado a correspondência de nomes. A resposta é o `{"status": "..."}` resultante: `COMPLETED` quando os nomes correspondem, `COUNTERPARTY_MISMATCHED_DATA` quando não correspondem, ou `COUNTERPARTY_VASP_GENERAL_DECLINE` após uma recusa. Você pode responder uma única vez, enquanto a transferência estiver aguardando você: depois da sua resposta, depois do cancelamento da transferência ou depois do prazo de confirmação, os dois endpoints retornam `410`, e um token desconhecido retorna `404`. A requisição mostra os campos do remetente que ele compartilha e um `ivms_request` IVMS 101, no idioma da sua jurisdição, e você recebe lembretes 72, 24 e 6 horas antes do prazo enquanto não tiver respondido. ## Sunrise: transferências liquidadas antes da troca Quando uma transferência chega à carteira de um cliente da Didit antes de qualquer troca de Travel Rule, porque não havia um rede compartilhada na época, os dados ainda podem ser entregues após a liquidação. Envie ao cliente da Didit (a sua contraparte beneficiária) o payload de Travel Rule pelo seu canal habitual e peça que ele o registre; ele deve chamar [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule#registro-sunrise-após-o-depósito) com a blockchain do depósito, o `txid`, o endereço da carteira, o valor, a moeda e os seus dados de remetente. Inclua a identidade do seu VASP (nome, LEI e travel address) como `originating_vasp` nesse payload, para que os registros da transferência do cliente da Didit indiquem quem enviou o depósito. Essa informação fica nessa transferência e nunca cria nem altera a sua [entrada no diretório](#como-entrar-no-diretório-de-vasps-da-didit). O LEI deve ser um LEI válido de 20 caracteres e o travel address deve ser válido; caso contrário, o registro é rejeitado. ## Como entrar no diretório de VASPs da Didit A Didit mantém um diretório de VASPs que o roteamento de saída dos seus clientes consulta. As entradas vêm destas fontes: * O registro provisório da ESMA de prestadores de serviços de criptoativos sob o MiCA, lido toda semana: seu nome, LEI e Estado-membro de origem, se você estiver listado nele. * O diretório público da TRISA, lido toda semana: quem você é, seu país e sua listagem na TRISA. * O registro global de LEI, que preenche seu LEI, outras denominações legais e o país. * A atribuição de análise de blockchain, quando uma carteira de destino é identificada como pertencente à sua exchange ou ao seu serviço de custódia: a Didit adiciona ou associa sua entrada e mantém o nome atribuído como alias. * A equipe da Didit, que faz a curadoria das entradas: identificadores de roteamento e listagens em redes que ela verificou, contatos de conformidade, aliases e marcas com suas entidades. O que um cliente da Didit informa sobre você, como um `originating_vasp` em um registro sunrise ou um travel address em uma transferência, fica na transferência desse cliente e nunca altera sua entrada. As consultas de transferência que você envia a um cliente da Didit também não criam nem atualizam sua entrada. Sua entrada roteia uma transferência até você quando contém um endpoint `TRP` verificado, uma listagem em uma rede que o remetente pode usar ou um contato de conformidade para o fallback por e-mail. Um endereço de conformidade em um dos seus próprios domínios que responde a uma requisição pelo link de resposta passa a ser um contato que todos os clientes da Didit podem usar. Enquanto sua entrada não tiver uma rota, um cliente da Didit só chega até você com os campos que envia em cada transferência: seu travel address, seu identificador de rede (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` ou `counterparty_sygna_vasp_code`) ou seu e-mail de conformidade (`counterparty_vasp_email`). Para estar acessível hoje, compartilhe seu travel address, identificador de rede ou e-mail de conformidade com os clientes da Didit com quem você trabalha. ## Checklist para VASPs de contraparte * **Você já opera TRP**: compartilhe seu travel address e seu LEI com o cliente da Didit. As transferências de `BTC`, `ETH` e `USDC` dele chegam ao seu endpoint como consultas TRP padrão. Responda na própria resposta à consulta: uma resposta posterior exige o host TRP público da Didit, que ainda não está ativo. * **Você está na GTR, na TRUST ou na VerifyVASP**: compartilhe seu identificador de rede. As transferências chegam por essa rede quando o cliente da Didit tem a própria associação nela. A Didit lê sua resposta da GTR ou da VerifyVASP pela rede, mas não uma resposta da TRUST, então publique também um endpoint TRP quando uma troca pela TRUST precisar ser concluída. [Redes de Travel Rule](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule-networks.md) informa quando isso muda. * **Você está na Sygna Bridge**: compartilhe seu código de VASP da Sygna. Quando o cliente da Didit tem a própria associação na Sygna, sua resposta de permissão conclui ou recusa a transferência assim que a Didit a lê por polling. * **Você ainda não tem um canal de protocolo**: informe ao cliente da Didit um e-mail de conformidade monitorado. Você receberá links de retirada e poderá responder pela página hospedada, sem nenhuma integração. * **Uma transferência já foi liquidada**: entregue os dados por meio de [registro sunrise](#sunrise-transferências-liquidadas-antes-da-troca), via o cliente da Didit. * **Você também quer originar transferências para VASPs da Didit**: peça à sua contraparte o travel address dela, disponível nas configurações de Travel Rule da Didit, e siga [POST /trp/inquiries](#post-/trp/inquiries//) assim que o host TRP público da Didit estiver ativo. ## Próximas etapas > [card] [Travel Rule](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md) > > O produto voltado ao cliente: ciclo de vida, configurações, redes e a API /v3/. > [card] [Widget de propriedade de carteira](https://docs.didit.me/pt-br/transaction-monitoring/wallet-ownership-widget.md) > > Como as provas de propriedade do lado do beneficiário são coletadas quando a carteira é autocustodiada. > [card] [Registro Sunrise](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md#registro-sunrise-após-o-depósito) > > Registro de dados da Travel Rule para depósitos que já foram liquidados on-chain. > [card] [Webhooks](https://docs.didit.me/pt-br/integration/webhooks.md) > > Como os clientes da Didit acompanham cada transição do intercâmbio do lado deles. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.