> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/guides/governance/whitelists.md). # Whitelists How to create, read, and maintain Whitelists on Ledger Enterprise, the two kinds of Whitelist, and how to handle an urgent counterparty change. **Role: Administrators write. Operators read.** A Whitelist is a named list of permitted destination addresses. Policy Rules reference Whitelists, and Approvers see the resolved destination on their device at signing time. ## The Whitelists list Whitelists are listed most recently updated first. Each row carries the name, a truncated description, the number of entries, the networks represented, and the last change date. Sort by name, entry count, created date, or last updated. The text filter searches **both Whitelist names and the addresses inside them**. Pasting a destination address tells you which Whitelists contain it, with the matching entry highlighted when you open one. That is the fastest answer to "is this address allowed anywhere?". There is also a network filter, showing only networks actually present in your Workspace. ## Creating a Whitelist The create flow collects a name of up to **45 characters** and an optional description, then the entries. Each entry has:
FieldNotes
CurrencyEach entry binds to one currency. There are no multi-currency entries
ChainShown only where the currency exists on more than one chain, otherwise derived
AddressValidated against the currency and chain
LabelRequired, up to 50 characters. This is what Approvers and auditors read
Destination tag or memoShown only for currencies that use one, such as XRP and XLM
Submitting creates a Whitelist Request. Once approved, the Whitelist is active and selectable in Policy Rules. A closed form is not saved as a draft. > **Note:** There is no maximum number of addresses in a Whitelist. There is a practical recommendation, though: keep any single edit to around **90 address changes or fewer**. Beyond that, the change becomes slow and tiring for the people who have to review it before approving, which makes mistakes more likely. Split a larger change into several edits. > **Important:** The label is the human-readable half of the entry, and often the only part an Approver can meaningfully check against their own records. "OTC partner, BTC cold" is useful. "Address 3" is not. ## Editing a Whitelist Name, description, and entries are all editable, with the same validation as at creation. Submitting creates an edit Request; while it is pending the Whitelist is locked, in the interface and through the API alike. After approval the history shows the full difference: what was added, removed, and changed. **Renaming or editing a Whitelist does not break the Policies that use it.** Policies point at a Whitelist by identity, not by name, so a rename is safe. And when you change the addresses, every Policy using that Whitelist picks up the change as soon as the edit is approved. ## Reading a Whitelist The detail shows its description and dates, the Request that last changed it, and: * **Entries**, with currency, address and a copy action, label, and destination tag where relevant. Search by label or address, filter by currency, and see how many of the total your filter matches. * **Used by**, every Policy referencing it. Administrators only, since Operators may not have visibility on all Policies. * **History**, the full timeline of governance Requests on it. ## When a counterparty changes urgently Removing a compromised or rotated address goes through the full approval cycle. There is no emergency bypass, by design: an attacker who could bypass approval to *add* an address would own your outbound flow. What you can do to make it fast: * Sort by last updated so the Whitelist you are working on stays at the top. * Write the note on the Request so Approvers understand the urgency without a phone call. * Keep Whitelists **narrow**. A Whitelist per counterparty is quicker and safer to change than one large Whitelist shared across many Policies, where a single edit touches everything. * Know in advance who your Approvers are and when they are reachable. The constraint in a fire-drill is almost never the software. > **Note:** A whitelisted destination states that your governance permits it, not that it is safe. Whitelisting governs where funds may go; it does not screen for risk. ## What Whitelists do not do yet * **No archive or delete.** Obsolete Whitelists remain in every list and picker. * **No bulk import.** Entries are added in the form. * **No distinction on the Approver's device** between a plain address and a smart contract. If your Policies allow contract destinations, treat the Whitelist as one control among several rather than the whole story. ## Related * [**Policies**](/help-center-v2/guides/governance/policies.md) * [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md) * [**Limits**](/help-center-v2/reference/limits.md) * [**The security model**](/help-center-v2/concepts/the-security-model.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.enterprise.ledger.com/help-center-v2/guides/governance/whitelists.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.