Send and Receive NajmBahar Transfers

NajmBahar distinguishes an internal account movement from a true economic Transfer between independent owners. The current transaction core routes different ownership and account cases through explicit executors so monetary state cannot be bypassed by choosing a different account type.

Bahar state and transferability

Bahar is the monetary unit and Gol is the subunit of Bahar (1 Bahar = 100 Gol).

For monetary state:

Active Bahar may be transferred between valid independent owners when the applicable authorization and policy gates permit it.
Dim Bahar is not transferable between independent people or entities. It must first satisfy a lawful Activation route.
Movement between eligible accounts of the same owner can preserve the existing state and is not itself Activation.

Do not use a sub-account or other child account as a way to bypass the Dim rule. The current transaction core resolves effective ownership and applies the cross-owner restriction to the real owner relationship.

Canonical routing

Different movements require different canonical paths. The current implementation distinguishes, among other cases:

Main ↔ Sub movement for the same owner;
eligible Sub ↔ Sub movement under the same parent account;
cross-owner Active sub-account movement;
eligible user/legal-entity → system movement;
sub-account → system movement;
other explicitly authorized system operations.

The public generic fallback for arbitrary sub-account-to-sub-account movement is not the governing contract. A movement must reach the executor that understands its ownership, money state and system context.

Policy and rollout gates

Having sufficient Active Bahar does not guarantee that every cross-member transfer is open at every stage of EarthCoop's rollout. The transaction layer can enforce the current cross-member threshold/policy gate. System operations and same-owner internal movements may follow separate rules.

A rejected transfer is therefore not evidence that the balance disappeared or that the money was retired; it means the requested operation did not satisfy the current execution rules.

Transaction safety

Valid monetary movement is expected to preserve core execution guarantees:

atomicity — a transfer should not leave only one side of a money movement applied;
idempotency — retried requests should not duplicate the same intended movement;
explicit money state — Active and Dim must not be silently substituted for one another;
authorization and ownership checks — account identifiers alone do not establish authority;
reconciliation — account mirrors and derived balances must remain consistent with ledger truth;
audit context — the operation should retain the information needed to reconstruct what happened.

Same-owner movement

When you move value between your own eligible Main and Sub accounts, that is an internal allocation of an existing balance. It does not create new Bahar, does not retire Bahar, and does not turn Dim into Active merely because the destination account changed.

Cross-owner Transfer

A true cross-owner transfer moves existing Active Bahar from a valid source to a valid destination through the applicable canonical executor. Where current policy permits the transfer, the ledger operation — not a UI status label — is the evidence that the value moved.

If another product workflow such as an investment, project payment, fee, treasury operation, or repayment causes a Transfer, that domain still has to use a valid monetary path. The domain record and the money-transfer record are related but distinct facts.

Current product boundary

Immediate canonical transfer behavior and its safety restrictions are supported by the current transaction core. This guide intentionally does not claim additional transfer modes unless they are separately proven in the current product contract.

For account partition rules see Sub-Accounts. For the distinction between Creation, Activation, Transfer and Retirement see NajmBahar Overview.