> ## 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. # Travel Rule Networks > What each Travel Rule rail and network reaches today, what it needs on your side, and what still waits for a membership Didit does not hold yet. A [Travel Rule](/transaction-monitoring/travel-rule.md) exchange reaches the counterparty VASP over one rail. Three rails need no membership of anyone: `INTERNAL` between two Didit customers, the open Travel Rule Protocol (`TRP`), and `EMAIL`. The four network rails (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) need a membership of that network on the sending side. This page says what each one does today, so you know where your counterparties are reachable before you depend on a route. > [!WARNING] > > **Didit does not hold a live membership on any Travel Rule network yet.** A network rail works today only with a membership you connect yourself in the console **Marketplace**. Nothing reaches a counterparty on GTR, TRUST, VerifyVASP or Sygna Bridge through Didit's own membership, and this page changes the day that does. ## Status at a glance | Rail | What you need | Sending to a counterparty | Receiving from one | | - | - | - | - | | `INTERNAL` | Nothing | Works | Works | | `TRP` | Nothing | Works when the counterparty answers at once | Not available yet | | `EMAIL` | A compliance address | Works | Not a receiving channel | | `GTR` | Your own membership | Implemented, not yet proven live | Not switched on yet | | `VERIFYVASP` | Your own membership | Implemented, not yet proven live | Not switched on yet | | `SYGNA` | Your own membership | Implemented, not yet proven live | Not switched on yet | | `TRUST` | Your own membership | Sends only, never completes | Not available | | CODE, TRISA, Notabene, Veriscope | - | Not integrated | Not integrated | "Works" means Didit sends the exchange and reads the answer. "Implemented, not yet proven live" means Didit sends the exchange and reads the network's answer, but no exchange over that network has completed against a live network yet. Neither ever means a given counterparty is reachable: that depends on the counterparty, and the [directory](/transaction-monitoring/travel-rule.md#directory) `routes` of each VASP say which rails your application can use for it today. `EMAIL` only carries your outbound requests: the response page is where a counterparty answers one of them, and no VASP can send you a transfer by email. Before you rely on GTR, VerifyVASP, Sygna Bridge or TRUST, connect your membership and run a first exchange with a counterparty you know. ## Rails that need no membership ### INTERNAL Both VASPs run on Didit, so the exchange settles inside the platform with no outbound call. The recipient must be a live Didit customer with Travel Rule on that proved control of the destination wallet with a signed message or a test deposit. A self-declared, screenshot-only or unverified wallet receives nothing. See [Sending a transfer](/transaction-monitoring/travel-rule.md#sending-a-transfer). ### TRP Didit speaks the Travel Rule Protocol natively. A transfer goes over `TRP` when it carries the counterparty's travel address, the destination wallet's address-book entry stores one, or the counterparty resolves in the directory with a TRP endpoint the directory verified. Every TRP exchange that does not finish in a single call needs Didit's public TRP host, the one travel addresses point at: * **Sending.** A counterparty that answers your inquiry at once, in its response, completes or declines the transfer. A counterparty that answers later posts its answer to Didit's TRP host, so that exchange cannot complete until the host is live; the transfer waits and expires at its deadline. Didit sends the inquiry once and does not retry it: when the counterparty's TRP host cannot be reached or refuses the inquiry, the transfer becomes `COUNTERPARTY_VASP_NOT_REACHABLE` at once, and you can retry it with `action: "resend"`. * **Receiving.** Other VASPs reach you at your travel address on that host, so no counterparty can send you a TRP inquiry until it is live. Didit's public TRP host does not serve these endpoints yet. [Travel Rule interoperability](/transaction-monitoring/travel-rule-interoperability.md) documents the endpoints counterparties call once it does. ### EMAIL When no protocol reaches the counterparty, Didit emails its compliance addresses a one-time link to a hosted page where they accept or decline. No account or integration is needed on their side. See [Email pickup](/transaction-monitoring/travel-rule.md#email-pickup-for-unreachable-counterparties). ## Network rails ### With your own membership Connect your own membership in the console **Marketplace** (Travel Rule networks category). Your transfers then travel under your own network identity, and a connected membership always takes precedence over Didit's. | Network | What the Marketplace asks for | How the counterparty's answer reaches Didit | | - | - | - | | `GTR` | API base URL, GTR VASP code, access key, secret key, and the ed25519 private key (base64) whose public key is registered in GTR's portal | In GTR's response to the request, or by polling the request's status every 5 minutes while the transfer waits | | `VERIFYVASP` | The URL of your own VerifyVASP Enclave, your VerifyVASP ID, and the token your Enclave presents to Didit | By polling the verification's status every 5 minutes | | `SYGNA` | Sygna VASP code, API key and signing private key. The API base URL is optional: leave it blank for the production Sygna Bridge | By polling the transfer's status every 5 minutes. Sygna's permission callback points at Didit's public TRP host, which is not live yet, so polling is the only way the answer reaches Didit today | | `TRUST` | Base URL, TRUST member ID and API key. An X25519 encryption private key (hex) is optional | Never: TRUST sends nothing back that Didit can read, so a delivered transfer waits until its deadline expires it | GTR, TRUST and VerifyVASP also take an optional mutual TLS client certificate, client key and CA bundle (PEM), for a membership that uses mutual TLS or a private CA. * Didit sends in the background and retries a network that does not answer, or answers with a temporary failure (no answer in time, a failed connection, HTTP `408`, `429` or `5xx`): after 30 seconds, then 2, 10, 30 and 60 minutes. After the sixth failed attempt the transfer becomes `COUNTERPARTY_VASP_NOT_REACHABLE`. A refusal, such as another `4xx` answer or a redirect, is not retried: the transfer becomes `COUNTERPARTY_VASP_NOT_REACHABLE` at once. * A transfer whose answer never arrives waits in `AWAITING_COUNTERPARTY` until `confirmation_timeout_hours` passes, then expires and applies your `timeout_outcome`. * Receiving a transfer that another VASP sends you over GTR, VerifyVASP or Sygna Bridge is not switched on yet: Didit switches it on per network, and until then those networks cannot deliver a transfer to you. * Saving a membership answers `400` when its participant code is Didit's own code on that network, or a code another application already holds. * Network requests carry your credentials only to that network's own host and never follow a redirect. The TRUST data packet goes to the beneficiary without your API key, member ID or client certificate. ### Through Didit's membership Once Didit holds a network membership, a customer without one can reach the network as its own participant on Didit's membership, with the participant code the network gives it: outbound messages name your code, never Didit's. This is offered for GTR and Sygna Bridge only. TRUST admits members one VASP at a time and a VerifyVASP Enclave serves one VASP, so both are reached with your own membership only. Joining takes three steps: answer Didit's network due-diligence questionnaire, have Didit approve it, then request the network. Didit registers you with the network, and your participant becomes active once the network gives it a code. This flow is not open yet. Until it is, saving or submitting the questionnaire and requesting a network answer `403` with `code: travel_rule_platform_networks_disabled`, and `GET /v3/travel-rule/networks/` reports `platform_networks_enabled: false`. ## Reading your application's status `GET /v3/travel-rule/settings/` and `GET /v3/travel-rule/networks/` return `networks`, keyed by `gtr`, `trust`, `verifyvasp` and `sygna`. Each entry says what the network can do for your application today: | `state` | `reason` | Meaning | | - | - | - | | `own_membership` | `own_membership_connected` | You connected your own membership. On a live application it sends for you. | | `live_through_didit` | `participant_active` | Didit's membership carries your application as its own active participant. | | `off` | `platform_network_switched_off` | You turned the network off in `disabled_networks`. | | `didit_onboarding` | `didit_membership_not_live` | Didit's own membership of the network is not live yet. | | `questionnaire_needed` | `questionnaire_not_submitted`, `questionnaire_changes_requested` | Didit's network questionnaire is not submitted, or Didit asked for changes. | | `questionnaire_in_review` | `questionnaire_submitted` | Didit is reviewing your questionnaire. | | `request_access` | `participant_not_requested` | Your questionnaire is approved: request the network. | | `request_sent` | `questionnaire_pending`, `submitted_to_network` | Your request is waiting for Didit to register you, or for the network's onboarding. | | `unavailable` | `own_membership_only`, `sandbox_application`, `questionnaire_rejected`, `participant_suspended`, `participant_rejected` | Nothing can send on this network for your application: TRUST and VerifyVASP are reached with your own membership only, Didit never registers a sandbox application on a network, Didit rejected your questionnaire, or the network suspended or rejected your participant. | | `error` | `provisioning_failed`, `participant_key_missing`, `participant_key_unresolved` | The network refused your registration, or the key your participant needs is missing. Requesting the network again retries. | `mode` sums the state up as `own`, `didit`, `off` or `unavailable`. Your own membership is checked first, then `disabled_networks`, then Didit's membership. Today a network reads `own_membership` once you connect your own membership. Otherwise GTR and Sygna Bridge read `didit_onboarding` (`unavailable` with `sandbox_application` on a sandbox application), and TRUST and VerifyVASP read `unavailable` with `own_membership_only`, in sandbox too. A sandbox application never sends over a network, even with your own membership connected and reading `own_membership`: its transfers go to the [Didit Test VASP](/transaction-monitoring/travel-rule-sandbox.md). `connected` means your saved membership passed local validation, not that an exchange succeeded. The first live exchange proves it against the network. ## What changes when a network goes live This page, the `networks` status and every directory route change together. Nothing changes in your integration: a transfer starts routing over the network as soon as your application has a membership on it, in the rail order described in [How Didit routes an exchange](/transaction-monitoring/travel-rule-interoperability.md#how-didit-routes-an-exchange). To ask for a network Didit does not reach yet, use its **Request access** tile in the **Marketplace**. Each request shows its status (**Open**, **Contacted**, **In progress**, **Live** or **Declined**) with Didit's latest note. When Didit changes the status or the note, it emails the teammate who made the request, while they are still in your organization. A request made with an API key gets no email, so follow it in the **Marketplace**. ## Next steps > **[Travel Rule](/transaction-monitoring/travel-rule.md)** > > The exchange lifecycle, settings, rails and the /v3/ API. > **[Test in sandbox](/transaction-monitoring/travel-rule-sandbox.md)** > > Run every outcome against the Didit Test VASP before you go live. > **[Interoperability](/transaction-monitoring/travel-rule-interoperability.md)** > > The endpoints counterparty VASPs use to reach you. > **[Directory](/transaction-monitoring/travel-rule.md#directory)** > > Find a VASP and the routes your application can use for it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.