Interoperabilidad Travel Rule: llegar a un VASP de Didit

Esta página es para la otra parte de un intercambio de Travel Rule de Didit: la VASP contraparte (o su equipo de ingeniería) que necesita enviar datos de Travel Rule a una VASP que opera con Didit, o recibirlos de ella. Todo lo que se documenta aquí es infraestructura pública operada por Didit. No necesitas una cuenta de Didit, una clave de API ni ninguna relación comercial con Didit para interoperar: la integración más profunda solo requiere HTTPS y JSON.

Cómo Didit enruta transferencias a un exchange

Cuando un cliente de Didit envía una transferencia, Didit prueba estas vías en un orden de prioridad estricto y usa la primera que puede llegar hasta ti:

Prioridad	Vía	Qué significa para ti
1	`INTERNAL`	Ambos VASP operan en Didit: la transferencia se liquida dentro de la plataforma y no se realiza ninguna llamada externa.
2	`TRP`	Expones un endpoint de Travel Rule Protocol (TRP), o el cliente de Didit conoce tu travel address. Didit invoca tu endpoint de consulta TRP de máquina a máquina, para transferencias de `BTC`, `ETH` y `USDC` (`USDC` cuando la transferencia indica la red por la que se mueve).
3	`GTR`	El remitente tiene activa una membresía de Global Travel Rule (GTR) y eres localizable mediante un código de VASP de GTR. Didit lee tu respuesta a partir de la respuesta de GTR, o consultando periódicamente el estado de la solicitud.
4	`TRUST`	El remitente tiene activa una membresía de TRUST y eres localizable mediante un id de membresía de TRUST. Solo para envío: consulta la advertencia más abajo.
5	`VERIFYVASP`	El remitente tiene activa una membresía de VerifyVASP y eres localizable mediante un id de VerifyVASP. Didit lee tu respuesta consultando periódicamente el estado de la verificación.
6	`SYGNA`	El remitente tiene activa una membresía de Sygna Bridge y eres localizable mediante un código de VASP de Sygna. Didit es compatible de forma nativa con el protocolo de Sygna (IVMS101 cifrado con ECIES, solicitudes de permiso firmadas) y lee tu respuesta de permiso consultando periódicamente el estado de la transferencia: su callback de Sygna todavía no está activo.
7	`EMAIL`	No hay ningún canal de protocolo disponible: tu contacto de cumplimiento recibe en su lugar un enlace de recogida por correo electrónico de un solo uso.

Didit no puede recibir una respuesta de TRUST y todavía no acepta transferencias que se le envíen a través de una red. Por TRUST, la transferencia de un cliente de Didit te llega, pero tu respuesta no puede volver, y la transferencia expira cuando vence el plazo de confirmación del remitente en lugar de completarse. Por GTR, VERIFYVASP y SYGNA, Didit lee tu respuesta en la propia red, a partir de su respuesta o consultando periódicamente el estado de la transferencia.

La tabla anterior cubre las transferencias que envía un cliente de Didit. Cuando tú envías una transferencia a un cliente de Didit, Didit solo puede recibirla como una consulta de transferencia TRP, una vez que el host TRP público de Didit esté activo (todavía no responde; consulta Endpoints TRP), o, tras la liquidación, como un registro sunrise: hoy ninguna vía de red ni ningún canal de correo electrónico entrega una transferencia entrante a un cliente de Didit. Las vías de red (GTR, TRUST, VERIFYVASP, SYGNA) funcionan mediante una membresía en el lado del remitente. Hoy esa tiene que ser la propia membresía conectada del cliente de Didit: Didit todavía no tiene ninguna membresía de plataforma en ninguna de estas redes y está en proceso de incorporarse como proveedor. GTR no está incluido por defecto, y el mismo requisito de membresía se aplica a las cuatro redes. El remitente debe revisar el objeto networks en Get Travel Rule Settings: didit significa que la membresía de Didit incluye esa aplicación como su propio participante en la red, own significa una membresía conectada del cliente, off significa que el enrutamiento de la plataforma está desactivado y unavailable significa que todavía no hay nada que pueda enviar por esa red para la aplicación. Hasta que Didit tenga una membresía de plataforma, ninguna red muestra didit. Activar Travel Rule no activa ninguna membresía de red. Consulta Redes de Travel Rule para ver hasta dónde llega cada red hoy. Si estás en una de esas redes y el cliente de Didit tiene allí su propia membresía, compártele tu identificador de red y la transferencia te llegará por la red que ya utilizas. Por SYGNA, tu respuesta de permiso completa o rechaza la transferencia: Didit consulta el estado de la transferencia cada 5 minutos y, además, registra https://trp.didit.me/sygna/callbacks/permission/{token}/ como callback de cada solicitud de permiso, con un token generado para esa transferencia. Ese callback está en el host TRP público de Didit, que todavía no atiende solicitudes. Un permission_status con valor ACCEPTED cambia el estado de la transferencia del remitente a COMPLETED, y un valor REJECTED lo cambia a COUNTERPARTY_VASP_GENERAL_DECLINE, o a COUNTERPARTY_MISMATCHED_DATA cuando el reject_code es BVRC007 (el nombre del beneficiario no coincide). El callback necesita tu firma: responde 401 con {"status": "INVALID_SIGNATURE"} si no hay una firma válida, 404 para un token desconocido y 200 de nuevo para una decisión que ya aplicó. Sin ninguna membresía compartida, TRP es la vía con la que debes contar: comparte tu travel address con el cliente de Didit y sus transferencias llegarán a tu endpoint TRP. Una respuesta que des en la respuesta a la consulta completa o rechaza la transferencia de inmediato; una respuesta que publiques más tarde en el callback de Didit necesita el host TRP público de Didit, que todavía no está activo. Cuando ninguna de las vías puede identificarte, Didit ejecuta un paso de resolución más: la atribución mediante análisis de blockchain. La wallet de destino se coteja con datos de análisis de blockchain y, cuando se atribuye a tu exchange o servicio de custodia, Didit registra tu nombre en su directorio de VASP y vuelve a intentar las vías usando ese nombre. Esto significa que se te puede identificar incluso cuando el remitente no proporcionó nada más que una dirección de wallet. Las transferencias atribuidas se enrutan hacia ti automáticamente solo cuando tu entrada en el directorio incluye una ruta: un endpoint TRP verificado, un registro en una red o un contacto de cumplimiento (consulta Cómo entrar en el directorio de VASP de Didit). Por tanto, la cadena de resolución completa es: un cliente de Didit que demostró controlar la wallet (INTERNAL), la travel address que el remitente guardó para ella, después las vías de protocolo y de red, y por último el análisis de blockchain.

Travel Addresses

Todo VASP de Didit con la Travel Rule activada tiene una Travel Address: una cadena compacta que empieza por ta y codifica la URL de su endpoint TRP propio de consulta de transferencias. Los clientes de Didit consultan la suya en la configuración de la Travel Rule y la comparten con sus contrapartes; cuando un cliente de Didit te da la suya, tienes todo lo necesario para comunicarte con él por TRP. La codificación sigue la convención de Travel Address de TRP:

Quita el prefijo ta.
Decodifica el resto con Base58Check (alfabeto de Bitcoin, suma de verificación doble SHA-256).
Los bytes decodificados son la URL de consulta sin su esquema; antepón https://.
La URL siempre incluye el par de consulta t=i (tipo: consulta).

Una Travel Address de Didit decodificada tiene una de estas dos formas:

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 el perfil de VASP alojado: envía tus consultas de transferencia con POST a esa URL y, antes, consulta el endpoint de identidad correspondiente para verificar con quién te estás comunicando. La segunda forma es una Travel Address por wallet: identifica una wallet concreta del cliente de Didit (receiving_travel_address en su libreta de direcciones), de modo que tu consulta llega a esa wallet sin que el cliente tenga que asociarla por número de cuenta o nombre del titular. Responde 404 en cuanto la wallet se elimina o se registra como perteneciente a otro VASP.

Endpoints de TRP

Didit utiliza la versión 3.2.1 de la API de TRP en la URL base https://trp.didit.me. Todos los endpoints intercambian JSON sobre HTTPS.

El host público de TRP de Didit todavía no expone estos endpoints. Hasta que lo haga, no se puede entregar una consulta TRP ni una solicitud de identidad a un cliente de Didit; esta sección define el contrato al que se ajustará el host cuando esté activo.

Método	Ruta	Propósito
`GET`	`/identity`	Identidad del operador de la plataforma (también disponible en `/trp/identity`).
`GET`	`/trp/identity/{profile_uuid}/`	Identidad de un perfil de VASP alojado.
`POST`	`/trp/inquiries/{profile_uuid}/`	Envía una consulta de transferencia a un VASP alojado.
`POST`	`/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/`	Envía una consulta de transferencia para una wallet de un VASP alojado (una travel address por wallet).
`POST`	`/trp/callbacks/resolution/{token}/`	Resuelve una consulta que Didit te envió (aprobar o rechazar).
`POST`	`/trp/callbacks/confirmation/{token}/`	Confirma o cancela una transferencia que Didit aprobó para ti.

Dos encabezados de TRP son importantes:

api-version: la versión del protocolo TRP que utilizas, por ejemplo 3.2.1. Obligatorio en las consultas y en ambos callbacks.
request-identifier: tu identificador único de la solicitud, que se devuelve en los encabezados de la respuesta. Obligatorio en las consultas y en ambos callbacks.

Una solicitud a los endpoints de consulta o de callback sin ambos encabezados devuelve 400. Cada respuesta de Didit incluye api-version: 3.2.1 y devuelve tu request-identifier.

GET /identity

Devuelve la identidad del operador de la plataforma. No se requiere ningún encabezado.

curl https://trp.didit.me/identity

{
  "name": "Didit",
  "lei": "",
  "x509": ""
}

GET /trp/identity//

Devuelve la identidad del VASP concreto con el que vas a realizar el intercambio; úsala para verificar el nombre y el LEI antes de enviar datos personales (PII). Didit realiza la misma comprobación a la inversa cuando inicia el intercambio: si la identidad que informa tu endpoint no coincide con el LEI o el nombre esperados, el intercambio se cancela.

curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/

{
  "name": "Bene CASP GmbH",
  "lei": "5493001KJTIIGC8Y1R12",
  "x509": ""
}

Devuelve 404 cuando el perfil no existe o su configuración de Travel Rule está desactivada.

POST /trp/inquiries//

Envía una consulta de transferencia: tú eres el VASP ordenante y el cliente de Didit es el VASP beneficiario.

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	Descripción
`asset.dti`	string	Obligatorio. El Digital Token Identifier (ISO 24165) del activo que se transfiere. Una consulta sin él responde `400`; el campo `asset.slip0044` anterior a la versión 3.2.0 no se lee.
`amount`	number	Obligatorio. Importe entero en la unidad mínima del activo (unidades base según los decimales del DTI). Se acepta cualquier notación JSON de un número entero, incluida la forma exponencial, así como una cadena de dígitos. Una fracción, o un importe demasiado grande para registrarlo, responde `400`.
`callback`	string	Obligatorio. URL `http(s)` pública y absoluta de tu lado donde Didit publica la resolución de la consulta (se recomienda `https`). Un reintento que repite el mismo `callback` se asocia a la consulta que repite.
`IVMS101`	object	Obligatorio. El payload IVMS 101: `originator.originatorPersons` y `beneficiary.beneficiaryPersons` (Didit lee el primer `naturalPerson` de cada uno; los datos de personas jurídicas no se leen), además de los arrays de wallets `accountNumber`.

En este canal, los activos se identifican por DTI, y un DTI identifica un token en una única blockchain. Actualmente, Didit asigna BTC (4H95J0R2X), ETH (X9J9K872S) y USDC en nueve redes, y se irán añadiendo más activos con el tiempo. Consulta Identificadores de activos de TRP para ver la lista completa. Una consulta cuyo DTI Didit no reconoce se acepta igualmente y se muestra al VASP beneficiario con el DTI como código del activo. Una respuesta 200 significa que la consulta se aceptó para su procesamiento; 400 significa que faltan encabezados de TRP o que el cuerpo no es válido, 404 significa que el perfil (o la wallet de una dirección por wallet) es desconocido o está desactivado, y 422 significa que la solicitud utiliza una extensión de TRP: Didit no admite ninguna, por lo que se rechaza un encabezado api-extensions o una clave extensions en el cuerpo. Reenviar el mismo request-identifier es idempotente: se reutiliza la consulta original en lugar de duplicarla. A continuación, Didit crea la transferencia entrante en la aplicación del cliente y la resuelve según la libreta de direcciones de wallets y la política del cliente. Identifica al beneficiario por la wallet que indica una travel address por wallet; si no, por la primera dirección de wallet en IVMS101.beneficiary.accountNumber; o, si no hay ninguna, comparando el nombre de beneficiaryPersons[0].naturalPerson con las entradas de wallets verificadas del cliente. La respuesta 200 incluye la respuesta cuando Didit puede darla de inmediato:

{"approved": {"address": "...", "callback": "..."}} cuando la consulta se aprobó automáticamente. Didit no publica además esa aprobación en tu callback.
{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"} cuando la consulta no indica ni el beneficiario ni una dirección de wallet, así que incluye siempre ambos.
{"version": "3.2.1"} cuando la decisión queda a la espera del cliente de Didit. En ese caso, la resolución llega más tarde como un POST a tu URL de callback, con uno de los dos cuerpos siguientes.

{
  "approved": {
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/"
  }
}

{
  "rejected": "Wallet ownership denied by beneficiary VASP"
}

La aprobación puede ser automática (cuando el VASP beneficiario activa la aceptación automática y el beneficiario coincide con una entrada de wallet verificada en la cadena del activo) o producirse tras una revisión manual o una prueba de propiedad de la wallet en el lado del beneficiario, así que ten en cuenta que puede haber un retraso entre la consulta y la resolución. Una consulta nunca coincide con una wallet que el cliente de Didit haya registrado como perteneciente a otro VASP, y el nombre de tu VASP en originatingVASP es el nombre que el cliente de Didit ve como el VASP ordenante de la transferencia. Didit no fija ningún plazo para una consulta que envías, y un cliente de Didit que la cancela no te envía ningún rechazo, así que aplica tu propio tiempo de espera. Después de recibir una aprobación y difundir la transferencia on-chain, cierra el intercambio enviando un POST a la URL approved.callback que se te proporcionó:

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" }'

Si cancelas la transferencia, envía en su lugar { "canceled": "reason" } a la misma URL. txid pasa la transferencia del lado del beneficiario a FINISHED; canceled la pasa a CANCELLED. Ambos callbacks responden 204 una vez procesados, 404 ante un token desconocido o una transferencia que ya no está a la espera de ese callback, y 400 ante un cuerpo que no incluye ninguno de los dos campos del callback.

Resolver las consultas que te envía Didit

Cuando un cliente de Didit origina una transferencia hacia ti mediante TRP, Didit:

Obtiene /identity en la raíz del host de tu URL de consulta (https://{your-host}/identity) y verifica que el nombre y el LEI que devuelves coinciden con lo que espera el cliente. Cuando la ruta procede del directorio de Didit, tu /identity debe devolver el LEI de esa entrada del directorio.
Envía mediante POST una consulta de transferencia a tu URL de consulta con la misma estructura de cuerpo descrita arriba: asset.dti, un amount en unidades base como número JSON, un callback y el payload IVMS101.

Solo una respuesta 2xx cuenta como entregada. Una 3xx se rechaza, porque no se siguen las redirecciones, y cualquier otra respuesta se registra en la cronología de la transferencia del cliente con tu código de estado, por ejemplo refused by counterparty (HTTP 403): .... Ambas llamadas llevan los dos encabezados de TRP, y Didit no sigue redirecciones HTTP en ellas, así que sirve /identity y la URL de consulta directamente. Si /identity no es accesible, no devuelve ningún LEI o devuelve un LEI distinto cuando el cliente indicó uno, o devuelve un nombre que no coincide, Didit se detiene antes de enviar la consulta y la transferencia del cliente pasa a COUNTERPARTY_VASP_NOT_REACHABLE. Si después el POST de la consulta falla o tu endpoint responde con un estado 4xx o 5xx, la transferencia también pasa a COUNTERPARTY_VASP_NOT_REACHABLE. El callback de esa consulta apunta al endpoint de resolución de Didit (/trp/callbacks/resolution/{token}/). Responde enviando mediante POST los mismos cuerpos de resolución que usa Didit: { "approved": { "address": "...", "callback": "..." } } para aprobar (tu callback es donde Didit enviará la confirmación on-chain), o { "rejected": "reason" } para rechazar. Envía ambos encabezados de TRP con ella. Didit responde 204 una vez procesada, 404 cuando la transferencia ya no está esperando una resolución y 400 para una aprobación sin address o cuyo callback no es una URL http(s) pública a la que Didit vaya a llamar. Tras la aprobación, el lado de Didit pasa a COMPLETED; cuando el cliente informa el hash on-chain, Didit envía mediante POST { "txid": "..." } al callback de confirmación que indicaste (o { "canceled": "reason" } si la transferencia se cancela antes).

Los tokens de callback son secretos destinados a un único fin, imposibles de adivinar y generados para cada transferencia: trata las URL de callback completas como confidenciales y ten en cuenta que una resolución solo se acepta mientras la transferencia sigue a la espera de ella.

Recogida por correo electrónico

Si no te llega ningún canal de protocolo y el cliente de Didit indicó tu correo electrónico de cumplimiento, Didit recurre al correo electrónico: tu contacto de cumplimiento recibe un mensaje que identifica al VASP ordenante con un enlace seguro de recogida de un solo uso. No necesitas cuenta, clave de API ni integración: el token del enlace sirve para autenticarte. Al abrir el enlace se muestra el intercambio pendiente; la API subyacente (que la página alojada invoca por ti) es pública:

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "originator_vasp_name": "Origin CASP SL",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY"
}

amount es el decimal almacenado tal cual, por lo que incluye los 18 decimales completos.

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 es accept o decline; al aceptar, indica el nombre del beneficiario tal como figura en tus registros para que la parte ordenante pueda realizar su comparación de nombres, o envía tu respuesta IVMS 101 completa como ivms_response, cuyo nombre de beneficiario prevalece entonces. Al rechazar puedes indicar un decline_reason (data_mismatch, not_our_customer, wallet_not_hosted, sanctions, risk_appetite, jurisdiction, insufficient_data u other) y un decline_detail de hasta 512 caracteres, obligatorio para other. Una aceptación sin beneficiary_name se registra como discrepancia cuando el remitente indicó un nombre de beneficiario, salvo que el remitente tenga desactivada la comparación de nombres. La respuesta es el {"status": "..."} resultante: COMPLETED cuando los nombres coinciden, COUNTERPARTY_MISMATCHED_DATA cuando no coinciden, o COUNTERPARTY_VASP_GENERAL_DECLINE tras un rechazo. Puedes responder una sola vez, mientras la transferencia espera tu respuesta: después de que respondas, después de que se cancele la transferencia o después de que venza su plazo de confirmación, ambos endpoints devuelven 410, y un token desconocido devuelve 404. La solicitud muestra los campos del ordenante que comparte el remitente y una ivms_request de IVMS 101, en el idioma de tu jurisdicción, y recibes recordatorios 72, 24 y 6 horas antes del plazo mientras no hayas respondido.

Sunrise: transferencias liquidadas antes del intercambio

Cuando una transferencia llega a la wallet de un cliente de Didit antes de que se produzca cualquier intercambio de Travel Rule (porque en ese momento no existía un canal compartido), los datos aún pueden entregarse después de la liquidación. Envía al cliente de Didit (tu contraparte beneficiaria) el payload de Travel Rule por tu canal habitual y pídele que lo registre; debe invocar POST /v3/travel-rule/inbound/ con la cadena del depósito, el txid, la dirección de la wallet, el importe, la moneda y tus datos de ordenante. Incluye la identidad de tu VASP (nombre, LEI y travel address) como originating_vasp en ese payload, para que la transferencia del cliente de Didit registre quién envió el depósito. Permanece en esa transferencia y nunca crea ni modifica tu entrada del directorio. El LEI debe ser un LEI válido de 20 caracteres y la travel address debe ser válida; de lo contrario, el registro se rechaza.

Cómo entrar en el directorio de VASP de Didit

Didit mantiene un directorio de VASP que utiliza el enrutamiento saliente de sus clientes. Las entradas provienen de estas fuentes:

El registro provisional MiCA de la ESMA de proveedores de servicios de criptoactivos, que se lee cada semana: tu nombre, tu LEI y tu Estado miembro de origen si figuras en él.
El directorio público de TRISA, que se lee cada semana: quién eres, tu país y tu ficha en TRISA.
El registro global de LEI, que completa tu LEI, otras denominaciones legales y tu país.
La atribución de analítica blockchain, cuando una wallet de destino se asocia a tu exchange o servicio de custodia: Didit añade tu entrada o la hace coincidir y conserva el nombre atribuido como alias.
El personal de Didit, que revisa y mantiene las entradas: identificadores de enrutamiento y registros en redes que ha verificado, contactos de cumplimiento, alias y marcas con sus entidades.

Lo que un cliente de Didit indica sobre ti, como un originating_vasp en un registro sunrise o una travel address en una transferencia, queda en la transferencia de ese cliente y nunca modifica tu entrada. Las consultas de transferencia que envías a un cliente de Didit tampoco crean ni actualizan tu entrada. Tu entrada enruta una transferencia hacia ti cuando contiene un endpoint TRP verificado, un registro en una red que el remitente puede usar o un contacto de cumplimiento para la alternativa por correo electrónico. Una dirección de cumplimiento en uno de tus propios dominios que responde a una solicitud a través de su enlace de respuesta se convierte en un contacto que cualquier cliente de Didit puede usar. Mientras tu entrada no contenga una ruta, un cliente de Didit solo llega a ti con los campos que envía en cada transferencia: tu travel address, tu identificador de red (counterparty_gtr_vasp_code, counterparty_trust_membership_id, counterparty_verifyvasp_id o counterparty_sygna_vasp_code) o tu correo electrónico de cumplimiento (counterparty_vasp_email). Para que puedan contactarte hoy, comparte tu travel address, tu identificador de red o tu correo electrónico de cumplimiento con los clientes de Didit con los que trabajas.

Lista de comprobación para VASP de contraparte

Ya operas TRP: comparte tu Travel Address y tu LEI con el cliente de Didit; sus transferencias de BTC, ETH y USDC llegan a tu endpoint como consultas TRP estándar. Responde en la respuesta a la consulta: una respuesta posterior requiere el host TRP público de Didit, que aún no está activo.
Estás en GTR, TRUST o VerifyVASP: comparte tu identificador de red; las transferencias llegan por esa red cuando el cliente de Didit tiene su propia membresía en ella. Didit lee tu respuesta de GTR o VerifyVASP desde la red, pero no una de TRUST, así que publica también un endpoint TRP cuando un intercambio por TRUST tenga que concluir. Redes de Travel Rule indica cuándo cambiará esto.
Estás en Sygna Bridge: comparte tu código de VASP de Sygna; cuando el cliente de Didit tiene su propia membresía en Sygna, tu respuesta de permiso completa o rechaza la transferencia una vez que Didit la lee mediante sondeo.
Aún no tienes un canal de protocolo: facilita al cliente de Didit una dirección de correo electrónico de cumplimiento que supervises; recibirás enlaces para recoger la información y podrás responder desde la página alojada sin ninguna integración.
Una transferencia ya se liquidó: entrega los datos mediante un registro sunrise a través del cliente de Didit.
También quieres originar transferencias hacia VASP de Didit: pide a tu contraparte su Travel Address, que encontrará en la configuración de Travel Rule de Didit, y sigue POST /trp/inquiries cuando el host TRP público de Didit esté activo.

Próximos pasos

Travel Rule

El producto orientado al cliente: ciclo de vida, configuración, rails y la API /v3/.

Widget de propiedad de wallet

Cómo se recopilan las pruebas de propiedad del lado del beneficiario cuando se trata de una wallet sin custodia.

Registro sunrise

Registro de datos de Travel Rule para depósitos que ya se liquidaron on-chain.

Webhooks

Cómo los clientes de Didit observan cada cambio de estado del intercambio de su lado.

Primeros pasos

Funciones

Referencia

Consola

Interoperabilidad Travel Rule: llegar a un VASP de Didit

Cómo Didit enruta transferencias a un exchange

Travel Addresses

Endpoints de TRP

GET /identity

GET /trp/identity//

POST /trp/inquiries//

Resolver las consultas que te envía Didit

Recogida por correo electrónico

Sunrise: transferencias liquidadas antes del intercambio

Cómo entrar en el directorio de VASP de Didit

Lista de comprobación para VASP de contraparte

Próximos pasos

Travel Rule

Widget de propiedad de wallet

Registro sunrise

Webhooks

​Cómo Didit enruta transferencias a un exchange

​Travel Addresses

​Endpoints de TRP

​GET /identity

​GET /trp/identity//

​POST /trp/inquiries//

​Resolver las consultas que te envía Didit

​Recogida por correo electrónico

​Sunrise: transferencias liquidadas antes del intercambio

​Cómo entrar en el directorio de VASP de Didit

​Lista de comprobación para VASP de contraparte

​Próximos pasos

Travel Rule

Widget de propiedad de wallet

Registro sunrise

Webhooks

Cómo Didit enruta transferencias a un exchange

Travel Addresses

Endpoints de TRP

GET /identity

GET /trp/identity//

POST /trp/inquiries//

Resolver las consultas que te envía Didit

Recogida por correo electrónico

Sunrise: transferencias liquidadas antes del intercambio

Cómo entrar en el directorio de VASP de Didit

Lista de comprobación para VASP de contraparte

Próximos pasos