Unified Indexer Service

The Unified Indexer Service is the blockchain indexing architecture used by Ripple Custody for ledger-specific indexing, event processing, and ledger APIs. It has two versions: UIS v1 and its rewrite, UIS v2. UIS v2 runs one indexer for each network, plus a processor, a Blockchain API, and a configuration service (Cockpit) that all networks share.

For a complete and up-to-date list of which ledgers are supported, please refer to the Supported blockchain ledgers page.

UIS v2 indexes blockchain data and exposes it to Ripple Custody through a small set of services:

For on-premises deployments, each indexer connects to a blockchain node that you provision — see On-premises node requirements below.

The following table lists the chains that each indexer serves:

Starting in version 1.43, EVM, Solana, Stellar, TRON, and XRPL networks are served by UIS v2 only, as part of ledger accounting refactor phase 2. On-premises deployments migrate to UIS v2 on version 1.43.

UIS v2 is available as follows:

For an on-premises deployment of UIS v2, you are responsible for provisioning and maintaining your own blockchain nodes. The service must be able to connect to these nodes to index transactions. The following table lists minimum node requirements for on-premises UIS v2 deployments. Check the configuration packaged with your release for release-specific changes.

For SaaS deployments, Ripple runs UIS v2 for supported chains, and Ripple runs the migration to UIS v2.

For on-premises deployments, configure each EVM, Solana, Stellar, TRON, and XRPL network in the ledger-accounting values with type: "uis-v2", and set the URL of the node that you provisioned under indexer.values.node:

ledgers:
  <chain>:
    networks:
      - name: <network>
        type: "uis-v2"
        indexer:
          values:
            node:
              url: "https://<your-node-url>"

Keep your existing chain keys and network names, and change only type.

If a network uses raw_config, also declare ledger.<name>.indexer-network-name in it. For other networks, the ledger-accounting chart generates this value automatically. Without it, chart rendering fails, and the error message shows the exact line to add.

To move an existing deployment to UIS v2, follow the Ledger accounting phase 2 migration guide. For any questions about the deployment process, contact your Customer Partner Engineer (CPE) or the Support team.

If a blockchain node requires a login, add an authentication block next to node.url. It takes either a static header or a customJwt token fetched from a token server:

ledgers:
  <chain>:
    networks:
      - name: <network>
        type: "uis-v2"
        indexer:
          values:
            node:
              url: "https://<private-node>"
              authentication:
                # A static header. For Basic authentication, use the key Authorization
                # and the value "Basic <base64 of user:password>".
                header:
                  key: x-api-key
                  value: <api-key>
                # Or a token fetched from a token server:
                # customJwt:
                #   tokenUrl: https://<token-server>/token
                #   apiKeyHeader: x-api-key
                #   apiKeyValue: <api-key>
                #   requestBody:           # optional
                #     signature: <signature>
                #   tokenJsonPath: data    # optional; the reply field that holds the token (default: data)

When at least one network has an authentication block, the chart deploys a node gateway (uis-v2-node-gateway) with a Service and a Secret. The gateway adds the login to each call and forwards it to node.url.

• Networks without an authentication block call their node directly. If no network has one, the chart doesn't deploy the gateway.
• authentication accepts only header and customJwt. Any other key fails the installation. OAuth2 isn't supported.
• Credentials (header.value, customJwt.apiKeyValue, customJwt.requestBody, and httpProxy.password) are stored in the uis-v2-node-gateway Secret, so the pod specification shows only the Secret name.
• If your nodes are reachable only through an outbound proxy, set nodeGateway.httpProxy (url, and optionally username, password, and noProxy). The gateway doesn't send customJwt token requests through the proxy, so the token server must be reachable directly.
• The gateway runs at least two replicas (nodeGateway.replicas), and a PodDisruptionBudget keeps one gateway pod running during node drains.
• To allow only the UIS v2 pods of the release to call the gateway, set nodeGateway.networkPolicy.enabled to true. This setting takes effect only if your cluster's network plugin enforces NetworkPolicy.