> 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/accounts/creating-and-editing-accounts.md).

# Creating and editing Accounts

How to create an Account on Ledger Enterprise, set the Rules that govern it, and edit it later.

**Role: Administrators.**

Creating an Account is a Request. Your fellow Administrators approve it, each signing with their own key. Nothing exists until that approval completes.

## Start

From the Accounts list, use the create action. To change an existing Account, use **Edit** on its row or on the Account page.

Throughout the flow everything you have chosen stays visible and editable until you submit.

## Choose the asset

Search the available coins by name or ticker. Only coins your Workspace supports appear, each with its name, ticker, and logo.

* A coin on **one** network is added directly.
* A coin on **several** networks prompts you to choose the network.

> **Warning:** Removing the asset after configuring Rules clears the Rule sections and the data in them. Settle the asset first, then build the Rules.

## Name the Account

Names can be up to **45 characters**, must be unique in the Workspace, and cannot contain special characters. If a name is rejected, the form says why.

The Account name appears in the Operators' navigation and on approval screens. A name carrying only the asset does not distinguish two Accounts that hold it.

## Set the Rules

An Account is governed either by **its own Rules**, used nowhere else, or by a **shared Policy** that other Accounts also use.

<table><thead><tr><th width="163.14453125">Choice</th><th>When to use it</th></tr></thead><tbody><tr><td>Its own Rules</td><td>The governance is genuinely specific to this Account</td></tr><tr><td>A shared Policy</td><td>The governance is a pattern you apply across many Accounts</td></tr></tbody></table>

A shared Policy must already exist and be approved before you can reference it. You cannot create one from this form, so provision it first: see [**Policies**](/help-center-v2/guides/governance/policies.md).

> **Note:** Linking a shared Policy makes this Account's Rules read-only. The Account names the Policy governing it, and changes are made on the Policy, where they apply to every adopting Account at once.

### Which Rules an Account can have

Rules are set per operation type. **A Send Rule is always required.** The others appear only where the asset supports them.

<table><thead><tr><th>Operation</th><th width="145.515625">Available on</th><th width="140.98828125">Required</th><th>Max Rules</th><th>Amount thresholds</th><th>Whitelists</th></tr></thead><tbody><tr><td>Send</td><td>All assets</td><td>Yes</td><td>4</td><td>Yes</td><td>Yes</td></tr><tr><td>Receive</td><td>Canton only</td><td>Yes, on Canton</td><td>1</td><td>No</td><td>No</td></tr><tr><td>Stake</td><td>Assets that support staking</td><td>No</td><td>1</td><td>No</td><td>No</td></tr><tr><td>Sign message</td><td>Assets that support it</td><td>No</td><td>1</td><td>No</td><td>No</td></tr><tr><td>Contract interaction</td><td>EVM networks</td><td>No</td><td>1</td><td>Yes</td><td>Yes</td></tr><tr><td>Contract deployment</td><td>EVM networks</td><td>No</td><td>1</td><td>Yes</td><td>No</td></tr><tr><td>Token activation</td><td>No supported asset today</td><td>No</td><td>1</td><td>No</td><td>No</td></tr></tbody></table>

> **Note:** A Receive Rule appears on Canton Accounts only. Canton is the only network where receiving is an action somebody has to approve. See [**Canton**](/help-center-v2/reference/networks/canton.md).

### Send Rules

A send Rule answers four questions.

1. **Creators.** Who may create a transfer. Required. Pick users, groups, or both; the picker distinguishes them.
2. **Whitelist.** Which destinations are permitted. Optional, and you can select several, in which case the Rule allows the combined set of their addresses. The picker shows how many addresses in each Whitelist match this Account's asset, and searches by Whitelist name or by an address inside one. Selecting a Whitelist with no matching address today is allowed.
3. **Threshold.** The amount range the Rule covers. Optional: set a minimum, a maximum, or one of the two. Amounts are entered in the asset, with the current countervalue shown. A minimum above the maximum is rejected.
4. **Approvers.** Who must approve, in ordered steps, each with its own quorum. **A person in several selected groups counts once**, so check each step's quorum is reachable by the distinct people in it.

Up to **four** send Rules per Account, evaluated in order. The first Rule whose threshold matches is the one that applies.

**Duplicate** a Rule set to pre-fill a new one.

> **Important:** Order and thresholds together decide who approves a given transfer. A Rule set can be valid and still route a common amount to the wrong Approvers.

### Contract interaction Rules

Where the asset supports smart contracts, contract interaction takes its own Rule, with its own thresholds and its own Whitelists. See [**Whitelists**](/help-center-v2/guides/governance/whitelists.md).

### Staking Rules

Where the asset supports staking, staking Rules are separate and off until you enable them. They take **Creators** and **Approvers**, with no Whitelists or thresholds.

You can copy your send Rules into an optional Rule set as a starting point; fields that do not apply are dropped.

An Account with no staking Rules cannot be staked from, and Operators are told to ask you. See [**Staking**](/help-center-v2/guides/staking.md).

## Add a note

Optional, up to 1,000 characters in the interface, shown to the Administrators who approve the Account. Say why the Account exists and, if the Rules are unusual, why.

## Submit

Submit becomes available once every required field is filled and no conflicts remain. While it is unavailable, hovering explains what is outstanding, one message per section.

Submit takes you straight to the review. After you confirm, the Request goes to the Administrator quorum.

## Editing an Account

Edit changes everything **except the asset and the network**, which are fixed for the Account's life. A different asset means a new Account.

The form opens pre-filled as a summary; use the edit action on a section to change it. Submitting creates an Account edit Request for the Administrator quorum.

### When editing is blocked

If the Account has unresolved Requests, you cannot edit it. The message lists every blocking Request and lets you open each one to see what it is, though not to act on it. Wait for them to complete, expire, or be rejected.

This prevents a dangerous race: approving a transfer under Rules that changed while it was in flight.

## Related

* [**Policies**](/help-center-v2/guides/governance/policies.md)
* [**Whitelists**](/help-center-v2/guides/governance/whitelists.md)
* [**How governance works**](/help-center-v2/concepts/how-governance-works.md)
* [**Limits**](/help-center-v2/reference/limits.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/accounts/creating-and-editing-accounts.md?ask=<question>&goal=<endgoal>
```

`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.
