Manage NajmBahar Sub-Accounts for Groups and Projects

NajmBahar sub-accounts help separate balances by purpose under an owner/account structure. They are accounting partitions, not independent sources of money. Creating a sub-account does not create Bahar, activate Dim, or grant a new economic right.

Monetary state stays explicit

A sub-account can participate in operations involving Dim or Active Bahar, but those states must not be silently mixed.

Dim is not spendable between independent economic actors.
Active Bahar can be transferred between valid independent owners subject to policy, authorization and current system gates.
Movement between an owner's own eligible accounts may preserve the existing money state. Such movement is not Creation and is not automatically Activation.

Moving Dim from a main account into one of the same owner's sub-accounts does not make it Active. Dim can become Active only through an authorized Activation route.

Same-owner account movement

The current transaction core has explicit canonical handling for eligible Main ↔ Sub movements under the same owner. These internal movements are designed to preserve account invariants and the requested money state.

The important accounting rule is:

same-owner account movement ≠ Creation
same-owner account movement ≠ Activation

It changes where an owner's balance is represented, not how much Bahar exists.

Sub-account to sub-account movement

The generic idea that any sub-account can freely send any state of money to any other sub-account is not the current contract.

Same-parent sub-account movement must use the applicable internal canonical executor.
Cross-owner sub-account movement requires Active Bahar and a dedicated canonical executor.
Dim cross-owner movement is rejected; it must first satisfy an authorized Activation route.

This distinction protects the ECON rule that a technical child account cannot be used to bypass monetary-state or ownership restrictions.

Groups, projects, and system accounts

Group, project, treasury, system, user and legal-entity money flows can require different executors and permissions. A visible account code alone is not proof that the sender is authorized to move value or that the receiving path is legally valid.

For collective accounts, role/responsibility and audit context matter in addition to balance sufficiency.

Balance and history

Where the current UI exposes sub-account details, use it to review the purpose of the account, its monetary-state balances and recorded movements. Ledger and reconciliation records are authoritative for monetary history; a sub-account's displayed balance should be treated as a derived/reconciled view of valid operations.

Current product boundary

Core sub-account and internal-transfer behavior exists in the current product. Some advanced account-management workflows and stable client/API contracts remain In development. This guide therefore documents the verified ownership and money-state invariants instead of promising UI actions that have not been independently confirmed.

See Transfers for cross-owner Transfer rules and Membership Fees for the annual fee route.