Ledger Service Configuration

Ledger service configuration allows administrators to define the behavior, constraints, and validations associated with transactions and wallets. The configurations described here are applied at the service level, meaning they govern the core behavior of the ledger across all ledger products created within this service instance.

These settings are not specific to individual products. Instead, they act as global enforcement rules that are applied uniformly to all wallets, transactions, and accounts governed by the ledger service.

The rules are modular and can be toggled or customized (where allowed) before being saved to the service configuration.

Accessing the Ledger Product Console

To begin configuring the ledger service:

1. Log in to the admin console.

2. Navigate through Product Configuration < Services < Ledger Service.

3. Click New Version to make changes to the service rules.

This will bring up a structured view of rule groups, each representing a different class of logic applied to transactions, wallets, or balances.

Understanding Rulebooks

Each rule in the ledger configuration is part of a rulebook. A rulebook defines:

• Trigger Type: The event that activates the rule (e.g., INSTRUCTION, WALLET_CREATED).

• Script Language: The underlying logic language, typically INTRINSIC (platform native) or JS (JavaScript-based for custom logic).

• Script Source: A hashed, internal reference to the actual implementation.

• Enablement Flag: Determines whether the rule is active for the product.

• Parameters: Editable fields that fine-tune the behavior of the rule, where applicable.

Rulebooks are not editable directly in this interface but are referenced as part of the ledger product definition.

Categories of Rules

The configuration interface organizes rules into the following logical groups. Each group addresses a different operational or compliance objective:

Wallet Balance Limit Rules

These rules define constraints on how much value a wallet can hold or must maintain:

• Min Wallet Balance Limit

• Min Wallet Balance Limit Advanced

• Max Wallet Balance Limit

• Max Account Balance Limit

Advanced versions offer parameter-based customization (e.g., setting thresholds directly in the interface).

Wallet Status Enforcement Rules

These rules control behavior based on the current status of the wallet, such as pending, suspended, or closed. They help enforce lifecycle boundaries and prevent operations on invalid wallet states:

• Reject on Pending Wallet

• Reject on Suspended Wallet

• Reject on Suspended In Wallet

• Reject on Suspended Out Wallet

• Reject on Terminated Wallet

• Reject on Closed Wallet

Currency Rules

Currency rules ensure that transactions align with wallet-defined currencies or impose restrictions during wallet creation:

• Currency Match Check

• Wallet Currency Restriction

The former is usually mandatory in multi-currency environments to avoid mismatches. The latter is used to enforce product-level currency policies at wallet creation time.

Data and Control Rules

Rules in this category are designed for observability or extensibility:

• Echo Movement Data

This rule echoes transaction details under specified conditions or path-based filters and is commonly used for audit or debugging pipelines.

Using the Enablement Toggles

Each rule is independently toggleable. Toggling a rule “on” includes its logic in the runtime behavior of the product. Toggling “off” excludes it entirely. Changes are persisted upon saving and apply only to the product under configuration.

Note: Not all rules are meant to be used together. In some cases, enabling overlapping rules may lead to redundant enforcement or unintended failures.

Saving and Deploying

After rules are configured:

1. Review all toggled rules and parameter values.

2. Click Save to persist the configuration.

3. The changes will take effect upon product deployment or activation.

This ensures controlled rollout and the ability to test configurations in staging environments before going live.