Governance
How Policies and Whitelists combine to govern what leaves an Account on Ledger Enterprise, and the order to build them in.
Two objects carry your governance:
A Whitelist is a named, governed list of permitted destination addresses.
A Policy is a named, reusable set of Rules that Accounts adopt.
Master Administrators create and change both through Requests. The Master Administrator quorum approves each of these Requests. API Administrators cannot create or change them. Operators can read them, which lets an Operator answer "is this destination allowed?" without asking anyone.
Build in this order
Whitelists, then Policies, then Accounts.
A Send Rule in a Policy points at Transaction Whitelists. A Contract Interaction Rule points at Smart Contract Whitelists. An Account points at a Policy.
You cannot create a Whitelist from inside a Policy form, or a Policy from inside an Account form. Each one has to exist and be approved before the next can point at it. That means three approval cycles when you set up a new client from scratch. Plan for it.
What each layer decides
Whitelist
Which addresses are permitted destinations
Policy Rule
Who may create an operation, within what amounts, to which whitelisted destinations, and who approves
Policy
Which Rules travel together as a reusable set
Account
Whether it uses its own Rules or adopts a shared Policy
Groups and Portfolios
Groups are named sets of Operators. Use a group in a Rule instead of naming individuals. When someone joins or leaves, you edit the group once rather than every Rule.
Portfolios group Accounts for organization and read-only visibility. They do not affect governance.
Workspace settings
Workspace settings hold the Rules that govern the Workspace itself: the Master Administrator quorum, the API admin rules, and the root Certificate Authority.
Related
Last updated