Endpoints are address book entries for ledger addresses and smart contract addresses.
- Endpoints associate an address with a ledger, alias, trust score, and governance metadata.
- Transaction orders can use an endpoint ID as the destination. Ripple Custody resolves the endpoint to its underlying address during transaction preparation.
- Policies can evaluate endpoint details, such as trust score, smart contract parameters, custom properties, or lock state.
- Locked endpoints cannot be used until an unlock intent executes.
Endpoints help operators use known destinations consistently. They also give policy authors a governed record to evaluate before a transaction order executes. Use endpoints when you want Ripple Custody to resolve a destination by ID and apply policy logic to that destination.
An endpoint is not an API endpoint. It belongs in accounts and assets because it describes a destination for asset movements. Endpoints can represent regular ledger addresses or, when the ledger supports it, smart contract addresses with application binary interface (ABI) data.
Ripple Custody supports several destination types for transaction orders:
| Destination type | What you provide | Use when |
|---|---|---|
| Address | A ledger address. | You want to send to a one-time or unmanaged destination. |
| Account | A Ripple Custody account ID. | You want Ripple Custody to resolve the destination from another custody account. |
| Endpoint | An endpoint ID. | You want to use a governed address book entry and let policies evaluate endpoint details. |
| Field or concept | Why it matters |
|---|---|
| Address | Identifies the ledger address or smart contract address. |
| Ledger | Scopes the address to the relevant blockchain network. |
| Domain | Owns the endpoint record and controls where users can view or manage it. |
| Alias and description | Give operators a recognizable name and context. |
| Trust score | Gives policies a numeric value, from 0 to 100, for destination-specific workflows. |
| Ledger parameters | Store EVM ABI data for smart contract endpoints, or a destination tag or memo on ledgers that route funds by tag (XRPL, Stellar, and Hedera). |
| Custom properties | Store customer-defined metadata that policies or integrations can use. |
| Lock state | Lets operators disable endpoint use without removing the record. |
On XRPL, Stellar, and Hedera, many institutions receive funds at one shared address and route each payment by a destination tag or memo. Endpoints on these ledgers can store that tag in their parameters field, so deposit instructions live on the endpoint rather than in a manual step at transfer time. When a transfer uses a tagged endpoint as its destination, Ripple Custody reads the tag from the endpoint automatically. The endpoint is the source of truth, and you can't override the tag on the transfer. For formats and examples, see Manage endpoints.
Endpoints are unique per domain, address, ledger, and destination tag. Two endpoints can share an address only if their tags differ, and only one endpoint without a tag can exist per domain, address, and ledger. Ripple Custody attributes incoming transactions to an endpoint by its ID using this full key, so the transaction history for an endpoint stays stable even when another endpoint shares its address. Ripple Custody doesn't remove duplicate endpoints that predate the uniqueness rule; when more than one matches an incoming transaction, it consistently uses the most recently created endpoint.
Policies can use endpoint information when evaluating an intent. For example, a transaction policy can require a different approval workflow when a transaction order uses an endpoint destination with a low trust score, a high trust score, or smart contract parameters.
An endpoint does not approve a transaction by itself. The policy that matches the transaction order decides whether the workflow auto-approves, requires approvals, rejects, or escalates.
Common endpoint policy inputs include:
| Policy input | Example use |
|---|---|
| Destination type | Apply a different workflow when a transaction order uses an endpoint destination instead of a raw address. |
| Trust score | Allow a simpler workflow for higher-scoring endpoints, or require extra approvals for lower-scoring endpoints. |
| Smart contract parameters | Escalate endpoint creation or transaction orders that involve smart contract addresses. |
| Custom properties | Route workflows based on customer-defined endpoint metadata. |
| Lock state | Prevent use of an endpoint until operators unlock it. |
Endpoint-management policies usually cover these intent types:
| Operation | Intent type |
|---|---|
| Register endpoint | v0_CreateEndpoint |
| Update endpoint | v0_UpdateEndpoint |
| Lock endpoint | v0_LockEndpoint |
| Unlock endpoint | v0_UnlockEndpoint |
Use endpoint trust scores and smart contract metadata deliberately. They can change how transaction and endpoint-management policies apply.
Endpoints do not:
- Create custody accounts or prove ownership of an address.
- Make a destination safe by themselves.
- Bypass transaction-order policies.
- Replace token allowlisting or UTXO change address allowlisting controls.
For operations, see Manage endpoints. For policy examples that use endpoints, see Policy examples.