SA: Provision, Circulation and Treasury

8.1 Introduction

SA is a serial-numbered MICROBA programme unit connected to eligible commercial activity.

SA is designed to circulate.

A member may receive eligible SA, hold it, transfer it, gift it, donate it, use it toward an eligible purchase, or redeem it according to programme rules.

When SA returns to Treasury, it does not need to disappear. It can be recycled into future valid SA entitlement.

The core system principle is:

Recycle existing SA before generating new SA.

This allows MICROBA to preserve the identity and history of each SA while preventing unnecessary growth in the total number of SA units.

8.2 Current Economic Reference

The current system reference is:

1 SA = Rp30,000

The current SA provision reference is:

3% of eligible sales

Therefore:

Rp1,000,000 eligible sales
x 3%
= Rp30,000 provision
= 1 whole-SA entitlement

The Rp30,000 value is a programme purchasing/redemption reference value.

Final public, legal, tax, and accounting terminology may be refined separately.

8.3 SA Is a Whole Serial-Numbered Unit

SA is not represented to the member as an arbitrary fractional token.

Each issued SA has a unique serial identity.

Example:

SA-000001
SA-000002
SA-000003

A serial remains associated with the same SA throughout its circulation.

When an existing SA is recycled, its serial number is preserved.

8.4 Provision Is Not Yet SA

Small eligible sales may create provision without immediately creating a whole SA.

Example:

Eligible Purchase: Rp10,000
3% Provision:      Rp300

Rp300 is backend provision.

It does not mean the member owns:

0.01 SA

Instead, valid provision accumulates according to the applicable entitlement rules.

When the whole-SA threshold is reached:

Accumulated Provision
Rp30,000
    |
1 Whole-SA Entitlement

8.5 Why Provision Exists

Provision allows the system to keep SA as whole serial-numbered units while still maintaining a constant economic relationship with eligible sales.

Example:

Purchase 1: Rp10,000 -> Rp300 provision
Purchase 2: Rp10,000 -> Rp300 provision
Purchase 3: Rp10,000 -> Rp300 provision
...

The backend can accumulate valid provision until a whole entitlement exists.

This avoids creating fractional serial numbers.

8.6 SA Entitlement

An SA entitlement means that the applicable provision has reached the threshold required for one or more whole SA.

Example:

Valid Provision: Rp60,000

Reference:
1 SA = Rp30,000

Entitlement:
2 SA

Entitlement does not automatically mean two new SA must be minted.

The system first checks Treasury.

8.7 Treasury

Treasury is the balancing reservoir for SA circulation.

Treasury holds SA that has returned from eligible member activity and is available for future recycling.

Conceptually:

Members
   |
Use / Redeem SA
   |
Treasury
   |
Future Entitlement
   |
Recycle SA
   |
Members

Treasury is therefore not merely a storage screen.

It is an active balancing mechanism in the SA lifecycle.

8.8 Pool and Treasury

For the current architecture, the public or operational SA Pool is treated as a view of Treasury-available SA.

It is not a separate owner of SA stock.

Conceptually:

Treasury
   |
Available SA
   |
Pool View

This avoids double-counting the same SA as both Treasury stock and Pool stock.

8.9 Recycle Before Mint

Whenever a valid whole-SA entitlement must be fulfilled, the system follows this sequence:

Entitlement
    |
Check Treasury
    |
Available SA?
  /       \
YES       NO
 |         |
Recycle    Mint shortage

Example:

Entitlement:       5 SA
Treasury:          3 SA

Recycle:           3 SA
Newly Generate:    2 SA

Only the shortage receives new serial numbers.

8.10 Recycling Preserves the Serial Number

Suppose Treasury contains:

SA-000125
SA-000402
SA-000550

A new entitlement requires 2 SA.

The system may release:

SA-000125
SA-000402

to the entitled member.

Those SA are not newly generated.

Their historical serial identity remains unchanged.

The ledger records a new movement in their history.

8.11 Minting New SA

New SA is generated only when Treasury does not contain enough recyclable SA to satisfy valid entitlement.

Example:

Entitlement: 3 SA
Treasury:    0 SA

New:
SA-001001
SA-001002
SA-001003

Minting must be distinguishable from recycling in the ledger.

This prevents the system from counting recycled SA as newly created supply.

8.12 Total SA Minted

The total number of SA ever minted should be distinguishable from current Treasury inventory and current member holdings.

At a current-state level:

Total Active SA Supply
=
SA held by Members
+
SA held by Treasury

Treasury recycling moves existing SA between holders.

It does not increase total minted supply.

New minting increases the total minted supply.

8.13 Example of Supply Conservation

Assume:

Total SA Minted:   100
Members Hold:       80
Treasury Holds:     20

Then:

80 + 20 = 100

If Treasury recycles 5 SA to members:

Members Hold:       85
Treasury Holds:     15
Total Minted:      100

No new SA was created.

8.14 SA Ownership and Platform Accounting View

At system level, MICROBA must distinguish:

total SA supply;
current holder;
Treasury availability;
member holdings;
provision;
entitlement;
sponsorship/counter value; and
commercial sales.

An SA may be held by a member or Treasury while remaining part of the overall MICROBA SA system.

The system should not count the same SA twice merely because it appears in multiple dashboard views.

8.15 Member SA Holdings

A member may hold one or more SA.

Example:

Member MID-000850

SA Holdings
SA-000125
SA-000402
SA-000903

The SA Registry should be able to identify the current holder and complete transaction history of each serial.

8.16 SA Registry

The SA Registry is the authoritative record of SA identity and state.

For every SA, the Registry should be able to answer:

What is the serial number?
When was it first generated?
Was it newly minted or recycled into the current holder?
Who currently holds it?
Has it been transferred?
Has it been used?
Has it been redeemed?
Is it currently in Treasury?
What transactions affected it?

The Registry monitors the supply without becoming Commerce.

8.17 SA Transaction History

Every meaningful SA movement should create a transaction record.

Examples include:

MINT
ALLOCATE
RECYCLE
TRANSFER
GIFT
DONATE
PURCHASE_USE
CASH_REDEEM
RETURN_TO_TREASURY
REVERSAL
ADJUSTMENT

The exact technical event names belong in the contracts documentation.

The important rule is that movement is recorded rather than silently changing a balance.

8.18 Transfer

A member may transfer eligible SA to another member according to programme rules.

Example:

Member A
   |
SA-000125
   |
Transfer
   |
Member B

The serial remains:

SA-000125

Only the holder changes.

8.19 Gift

A member may gift SA where permitted.

At system level, gifting is a form of authorized SA transfer with appropriate transaction context.

Example:

A gifts SA-000125 to B

The ledger records the movement.

Gifting does not mint new SA.

8.20 Donation

A member may donate SA according to programme rules.

The receiving destination must be a valid authorized destination.

Donation is recorded as an SA movement.

It does not create new SA merely because the transaction is charitable or voluntary.

8.21 SA Transfer Does Not Create Sales

Moving SA between members is not itself a Product sale.

Therefore:

SA Transfer
!=
Commerce Sale

A transfer should not automatically create:

new eligible sales;
new SA provision;
HIVE commission; or
newly minted SA.

This prevents circular value generation.

8.22 Using SA for a Purchase

Eligible SA may be used toward a Commerce purchase.

Example:

Product Value: Rp300,000
SA Used:       2
Reference:     Rp30,000 each

SA Benefit:    Rp60,000
Other Payment: Rp240,000

Commerce records the commercial transaction.

The SA system records the movement of the specific serial-numbered SA.

8.23 100% SA Purchase

The current architecture allows an eligible purchase to be funded entirely with SA.

Example:

Product Value: Rp300,000
SA Used:       10
SA Value:      Rp300,000
Cash Due:      Rp0

The Order remains a real Commerce transaction.

The SA used returns to Treasury according to the approved circulation rule.

8.24 SA Used in Commerce Returns to Treasury

When SA is used toward an eligible purchase, the corresponding SA serials move from the member to Treasury.

Example:

Before Purchase

Member:
SA-001
SA-002

Treasury:
SA-010

Member uses SA-001 and SA-002

After Purchase

Member:
-

Treasury:
SA-010
SA-001
SA-002

The serials can later be recycled to satisfy future entitlement.

8.25 Cash Redemption

Where cash redemption is permitted, a member may redeem eligible SA according to programme rules.

Conceptually:

Member
   |
1 SA
   |
Cash Redemption
   |
Reference Value Rp30,000
   |
SA returns to Treasury

The redemption creates two important effects:

the member receives the approved redemption value; and
the SA serial returns to Treasury.

The SA is not destroyed merely because cash was paid out.

8.26 Cash Redemption and Treasury

Suppose:

Member holds:
SA-000125

The member redeems it for the current reference amount.

After successful redemption:

Member:
receives Rp30,000

Treasury:
receives SA-000125

Treasury can later recycle SA-000125 into a new valid entitlement.

This avoids permanent accumulation of unusable redeemed SA.

8.27 Treasury Does Not Automatically Receive New SA From Every Sale

Eligible sales create provision and entitlement.

Treasury does not simply receive a newly generated SA every time the sales threshold is reached.

Instead:

Eligible Sales
   |
Provision
   |
Entitlement
   |
Check Treasury
   |
Recycle existing SA first
   |
Mint shortage only

Treasury receives SA when SA returns through approved circulation such as purchase use or redemption.

8.28 Sponsorship / Counter Ledger

The current system model includes an internal sponsorship or counter ledger that moves in tandem with Treasury SA.

At system level:

Treasury SA increases
        |
Counter / Sponsorship value increases

Treasury SA decreases through recycling
        |
Counter / Sponsorship value decreases

Using the current reference:

1 SA <-> Rp30,000 counter value

This provides a simple balancing view of Treasury circulation.

Final public wording for this ledger can be determined later.

8.29 Example Treasury Counter

Initial state:

Treasury SA:      0
Counter Value:    Rp0

One SA returns to Treasury:

Treasury SA:      1
Counter Value:    Rp30,000

Another SA returns:

Treasury SA:      2
Counter Value:    Rp60,000

Treasury recycles one SA:

Treasury SA:      1
Counter Value:    Rp30,000

The dashboard can therefore remain understandable without exposing formal accounting terminology.

8.30 SA + Sponsorship Balancing View

The system may internally present the SA side and sponsorship/counter side as opposing balancing entries.

Conceptually:

SA Movement
      |
Balancing Sponsorship / Counter Movement

The intended system relationship is:

SA + Sponsorship = 0

This is an internal balancing model, not necessarily the final legal or financial-statement presentation.

Formal accounting treatment should be determined separately.

8.31 Treasury Dashboard

The Treasury dashboard itself can remain very simple.

For example:

TREASURY

Available SA
1,250

The detailed counter/sponsorship and transaction records can exist in supporting ledgers.

The objective is to avoid requiring ordinary users to interpret accounting terminology.

8.32 SA Dashboard

A broader SA dashboard may show:

SA

Total SA Minted
5,000

Held by Members
3,750

Available in Treasury
1,250

Provision Pending
Rp18,600

The exact public metrics may be refined later.

The dashboard should never add Treasury and Pool as separate stock owners if Pool is merely the Treasury-available view.

8.33 Member Dashboard

A member-facing SA view should be simpler.

Example:

MY SA

Available
12 SA

Reference Value
Rp360,000

Pending Provision
Rp6,300

The member may also access transaction history.

The interface should explain clearly that pending provision is not yet a whole serial-numbered SA.

8.34 SA Transaction Example

A member's history might show:

SA-000125
Received        +1 SA
Transferred     -1 SA

SA-000402
Received        +1 SA
Purchase Use    -1 SA

A detailed view can show dates, references, counterparties where permitted, and transaction status.

8.35 Treasury Transaction Example

Treasury may record:

SA-000402
Received from Purchase Use     +1 SA

SA-000125
Received from Cash Redemption  +1 SA

SA-000550
Recycled to Entitlement        -1 SA

The corresponding internal counter ledger moves according to the current SA reference value.

8.36 Commerce and SA

Commerce is the authoritative source of eligible commercial activity.

The SA system should not invent sales.

Canonical relationship:

Commerce
   |
Eligible Sales Event
   |
SA Provision
   |
Whole Entitlement
   |
Treasury Check
   |
Recycle / Mint

For SA-funded purchases, Commerce also coordinates validation and movement of SA used in settlement.

8.37 Sales and SA Monitoring

The system should be able to monitor the relationship among:

Eligible Sales
SA Provision
Whole-SA Entitlement
Newly Minted SA
Recycled SA
Member-Held SA
Treasury-Held SA

This provides automatic check-and-balance.

The purpose is not to force all numbers into one simplistic equation.

The purpose is to make every movement explainable.

8.38 New SA vs Recycled SA

The ledger must explicitly distinguish:

NEW SA

from:

RECYCLED SA

Example:

Entitlement: 10 SA

Treasury supplied:
8 recycled SA

Newly minted:
2 SA

The system must report:

Entitlement Fulfilled: 10
Recycled:               8
Newly Minted:           2

It must not report 10 newly generated SA.

8.39 Why This Distinction Matters

Without separating new and recycled SA, the system could falsely conclude that every entitlement increases total SA supply.

That would cause total supply to grow even when existing SA is simply circulating.

Correct model:

Entitlement
!=
Minting

Entitlement creates a requirement.

Treasury recycling may satisfy that requirement without increasing supply.

8.40 Current Supply Equation

For current circulating SA:

Total SA Supply
=
Member-Held SA
+
Treasury-Held SA

Pending provision is not included because it is not yet a whole SA.

Recycled SA is already included because it is an existing unit.

8.41 Provision Equation

The conceptual provision relationship is:

Provision Value
=
Eligible Sales
x
3%

Example:

Eligible Sales: Rp300,000,000
3% Provision:   Rp9,000,000

At the current reference:

Rp9,000,000 / Rp30,000
= 300 whole-SA equivalent entitlement

Whether those 300 entitlements are fulfilled through recycled or newly minted SA depends on Treasury inventory.

8.42 Example — Rp300 Million Sales

Assume:

Eligible Sales: Rp300,000,000
SA Provision:   3%
Reference:      Rp30,000 / SA

Then:

Provision Value:
Rp9,000,000

Whole-SA Equivalent:
300 SA

If Treasury has:

200 SA

then:

Recycled:
200 SA

Newly Minted:
100 SA

The entitlement is 300 SA, but only 100 new SA enter total supply.

8.43 Example — Treasury Has Enough SA

New Entitlement:
100 SA

Treasury Available:
1,000 SA

Result:

Recycled:
100 SA

Newly Minted:
0 SA

Treasury Remaining:
900 SA

Total SA supply does not increase.

8.44 Example — Treasury Is Empty

New Entitlement:
100 SA

Treasury:
0 SA

Result:

Recycled:
0

Newly Minted:
100 SA

Total minted supply increases by 100.

8.45 Example — SA Purchase and Recycling

Initial state:

Member A:
10 SA

Treasury:
0 SA

Member A purchases a Product worth Rp300,000 using 10 SA.

After successful Commerce settlement:

Member A:
0 SA

Treasury:
10 SA

Later, another valid entitlement requires 3 SA.

The system releases 3 Treasury SA:

Treasury:
7 SA

New Entitled Member:
3 recycled SA

No new SA needs to be minted for that entitlement.

8.46 Example — Cash Redemption and Recycling

Initial state:

Member:
2 SA

Treasury:
5 SA

Member cash-redeems 1 SA.

After successful redemption:

Member:
1 SA

Treasury:
6 SA

Later one valid SA entitlement occurs:

Treasury recycles:
1 SA

Treasury remaining:
5 SA

The same circulating unit can continue through future valid transactions while preserving its serial history.

8.47 SA and HIVE Are Separate

SA provision and HIVE sponsorship may both originate from an eligible Commerce sale, but they are separate mechanisms.

Current references:

Eligible Direct Sponsored Sale
        |
        +---- HIVE: 9%
        |
        +---- SA Provision: 3%

A person may receive applicable SA without being an affiliate.

A member may also receive HIVE sponsorship without the HIVE transaction itself creating SA.

8.48 Personal Purchase and SA

An eligible personal purchase may contribute to the purchaser's applicable SA provision.

This is separate from HIVE.

Example:

Member A purchases
Rp1,000,000

Self-HIVE Commission:
Rp0

SA Provision:
3% = Rp30,000

Subject to the final eligible-sales rule, this corresponds to one whole-SA entitlement at the current reference.

8.49 SA and Sponsorship Transfer Are Different

Transferring SA to another person does not transfer a HIVE sponsor relationship.

Example:

A transfers SA to B

This means B becomes the holder of that SA.

It does not mean:

A becomes B's sponsor

or:

B becomes A's sponsor

The two systems remain independent.

8.50 SA and Knowledge

Holding SA does not automatically prove Knowledge completion.

Reading Articles does not automatically create SA unless an explicit future programme rule says so.

SA and Knowledge remain separate capabilities.

8.51 SA and Launch

Creating or attending a Launch event does not automatically create SA.

If a future approved programme creates an SA entitlement connected to a specific event activity, that rule must be explicit.

8.52 SA and Profile

My MICROBA may display:

SA holdings;
pending provision;
transaction history;
transfer;
gift;
donation;
purchasing use;
redemption; and
related member actions.

Profile does not own the SA ledger.

The SA Registry remains authoritative.

8.53 Transfer Authorization

A member may transfer only SA they are authorized to control.

The system should validate:

current holder;
SA status;
recipient;
transaction eligibility;
duplicate request protection; and
applicable programme restrictions.

Knowing a serial number does not grant ownership of the SA.

8.54 Atomic SA Movement

A serial-numbered SA should not be held by two owners at the same time.

A successful transfer changes the authoritative holder atomically within the SA aggregate.

Example:

Before:
SA-001 -> Member A

Transfer Commit

After:
SA-001 -> Member B

There must not be a valid state where both A and B simultaneously own the same serial.

8.55 Idempotency

SA operations must be idempotent where retries are possible.

A repeated transfer request must not move two SA.

A repeated Commerce event must not create two entitlements.

A repeated redemption callback must not pay cash twice.

Transaction IDs and deduplication are therefore essential.

8.56 Reservation

For complex Commerce transactions, SA may need to be temporarily reserved before final commit.

Example:

Member selects 10 SA
       |
Reserve SA
       |
Complete remaining payment
       |
Payment succeeds
       |
Commit SA movement to Treasury

If the transaction fails:

Release Reservation

This prevents the same SA from being used in two simultaneous purchases.

8.57 Reversal

If a transaction using SA is reversed, the SA system should perform an explicit compensating action according to the applicable rules.

The original movement remains in history.

Example:

PURCHASE_USE
Member -> Treasury

Order reversed

REVERSAL
Treasury -> Member

The system must verify that the reversal is still valid and account for any subsequent SA state changes.

8.58 No Silent Deletion

SA history should never be silently deleted to make balances appear correct.

Corrections use explicit records such as:

reversal;
adjustment;
invalidation;
restoration; or
another approved compensating transaction.

The history of the serial remains traceable.

8.59 Cash Redemption Controls

Cash redemption moves real economic value.

It therefore requires stronger controls than simply displaying an SA balance.

The system should verify:

member identity;
SA ownership;
SA eligibility;
redemption amount;
duplicate redemption protection;
settlement status; and
final movement to Treasury.

Additional approval or security controls may be applied according to programme policy.

8.60 Redemption Is Not Complete Until Settlement Is Confirmed

A redemption request should not immediately move into a final completed state merely because the member clicked Redeem.

Conceptually:

Requested
   |
Validated
   |
Processing
   |
Settlement Confirmed
   |
SA Returned to Treasury
   |
Completed

If settlement fails, the system should preserve or restore the correct SA state.

8.61 Treasury Recycling Transaction

When Treasury fulfills an entitlement, the system records a recycle transaction.

Example:

SA-000125

From:
Treasury

To:
MID-000850

Reason:
SA Entitlement

Type:
RECYCLE

This differs from MINT.

8.62 Mint Transaction

When a shortage requires new SA:

SA-001501

Origin:
New Generation

To:
MID-000850

Reason:
SA Entitlement Shortage

Type:
MINT

The Registry now includes a new serial.

8.63 Lineage

Every SA should preserve lineage.

A serial's history may conceptually look like:

SA-000125

Minted
  |
Member A
  |
Transferred
  |
Member B
  |
Used for Purchase
  |
Treasury
  |
Recycled
  |
Member C
  |
Cash Redeemed
  |
Treasury

This is a Living Architecture example of preserving meaning rather than merely storing a numeric balance.

8.64 SA Is More Than a Balance

A simple balance such as:

12 SA

is useful for the member interface.

But the backend must know which twelve SA they are.

This enables:

provenance;
audit;
transfer;
recycling;
redemption;
fraud detection;
reconciliation; and
historical explanation.

Therefore:

**The dashboard may show a balance, but the system preserves

identity.**

8.65 Treasury Is More Than a Number

Likewise:

Treasury: 1,250 SA

is a useful dashboard number.

But the backend should know the exact 1,250 serials currently held by Treasury.

This makes recycling deterministic and auditable.

8.66 Human-Readable Monitoring

The operational system should present SA in terms understandable to non-accountants.

Example:

SA SYSTEM

Total SA
5,000

With Members
3,750

In Treasury
1,250

Pending Provision
Rp18,600

Recycled Today
42 SA

Newly Generated Today
7 SA

A user should be able to understand the state without reading debit/credit journals.

8.67 Detailed Ledger Behind the Dashboard

The simple dashboard can be backed by detailed records.

Conceptually:

Simple View
   |
5,000 Total SA
   |
Detailed Registry + Transactions
   |
Every Serial + Every Movement

The simple number must be derivable from the detailed ledger.

It should not be a manually maintained independent figure.

8.68 Reconciliation

The SA system should automatically reconcile:

Total SA Supply
=
Member-Held SA
+
Treasury-Held SA

It should also reconcile:

pending provision;
whole entitlement;
recycled fulfillment;
newly minted fulfillment;
purchase-use returns;
cash-redemption returns;
transfers;
reversals; and
counter/sponsorship movements.

A mismatch should be detectable.

8.69 Commerce Reconciliation

Commerce and SA should be able to compare their related records.

Example:

Commerce says:
10 SA used on ORD-10025

SA Registry says:
10 serials moved Member -> Treasury
Reference:
ORD-10025

If Commerce says 10 but the SA Registry records only 9, the system should raise a reconciliation issue.

8.70 Treasury Counter Reconciliation

Where the internal sponsorship/counter ledger is used, Treasury SA movement should correspond to the current reference value.

Example:

Treasury receives:
10 SA

Reference:
Rp30,000 each

Counter increase:
Rp300,000

If 4 SA are recycled:

Treasury decrease:
4 SA

Counter decrease:
Rp120,000

The system can detect a mismatch between SA inventory movement and its balancing counter.

8.71 Important Open Rule: Eligible Sales for SA-Funded Purchases

The architecture permits SA-funded and fully SA-funded purchases.

However, one financial rule must be explicitly finalized:

**What sales value should create new SA provision when existing SA is

used to fund a purchase?**

Example:

Product Value: Rp300,000
SA Used:       Rp60,000
Other Payment: Rp240,000

Possible bases include:

gross Product value;
net external payment; or
another explicitly defined programme eligible-sales value.

The system must not allow developers or AI to infer this rule independently.

It must be formally locked because the choice affects SA generation, recycling, HIVE calculation, and long-term economic balance.

8.72 Preventing Circular Generation

SA movement must not accidentally generate unlimited new SA from the same value circulating repeatedly.

For example:

SA Transfer
-> no new sales
-> no new provision

Treasury Recycle
-> no new sales
-> no new provision

For SA-funded Product purchases, the final eligible-sales rule must explicitly control whether and how provision is created.

This is necessary to preserve economic integrity.

8.73 SA Status

A serial may require controlled states such as:

AVAILABLE
RESERVED
IN_TRANSFER
IN_REDEMPTION
TREASURY
RESTRICTED

Exact technical statuses belong to the SA architecture.

The system should prevent incompatible simultaneous states.

8.74 Administrative Controls

Authorized Admins may need capabilities such as:

inspect SA serial;
inspect transaction history;
inspect Treasury inventory;
investigate reconciliation mismatch;
place SA under controlled restriction;
approve exceptional redemption;
perform governed adjustment; and
reverse an invalid transaction.

Admins should not casually edit balances.

Corrections should preserve audit history.

8.75 Audit Trail

Important SA actions should be auditable.

Examples include:

mint;
recycle;
allocate;
transfer;
gift;
donate;
reserve;
release reservation;
purchase use;
redemption request;
redemption settlement;
return to Treasury;
reversal;
restriction; and
administrative adjustment.

The audit trail should preserve actor, serial, reference, timestamp, and reason where appropriate.

8.76 Example — Small Personal Purchases

A member buys one set at:

Rp10,000

Eligible provision:

Rp300

No fractional SA serial is issued.

The provision remains pending.

As valid provision accumulates to:

Rp30,000

one whole-SA entitlement is created.

Treasury is checked first.

8.77 Example — Group/System Sales

Suppose total applicable eligible sales under the relevant entitlement scope reach:

Rp300,000,000

At 3%:

Provision:
Rp9,000,000

At Rp30,000 per SA:

Whole-SA Equivalent:
300 SA

If Treasury contains 1,000 SA, the system can recycle 300.

Newly minted SA:

Treasury remaining:

700 SA

8.78 Example — Treasury Shortage

Entitlement:
300 SA

Treasury:
100 SA

Result:

Recycled:
100 SA

Newly Minted:
200 SA

The system records both sources separately.

8.79 Example — Transfer and Donation

Member A:
5 SA

Transfers 1 SA to Member B
Donates 1 SA to approved destination

After successful transactions:

Member A:
3 SA

No new sales, HIVE commission, or SA provision is created merely by these movements.

8.80 Example — Treasury Counter

Starting state:

Treasury:
0 SA

Counter:
Rp0

Three SA return through eligible purchase use/redemption:

Treasury:
3 SA

Counter:
Rp90,000

Treasury recycles two SA:

Treasury:
1 SA

Counter:
Rp30,000

This provides a simple operational check.

8.81 Frequently Asked Questions

What is SA?

SA is a serial-numbered MICROBA programme unit connected to eligible commercial activity and capable of circulating through members and Treasury.

What is the current reference value of 1 SA?

Rp30,000.

What is the current SA provision rate?

3% of eligible sales.

Does a Rp10,000 eligible purchase give me a fractional SA?

No. It creates Rp300 of backend provision under the current reference.

When do I receive a whole SA?

When valid accumulated provision reaches the whole-SA entitlement threshold and the entitlement is fulfilled.

Does every entitlement create a newly minted SA?

No.

What happens first?

Treasury is checked for recyclable SA.

When is new SA minted?

Only when Treasury cannot fully satisfy the valid entitlement.

Does recycled SA get a new serial number?

No.

What happens to its old serial?

It remains unchanged.

Can I see an SA balance?

Yes. The member interface can show a simple balance while the backend preserves each serial.

Can I transfer SA?

Yes, according to programme rules.

Can I gift SA?

Yes, where permitted.

Can I donate SA?

Yes, where permitted.

Does transferring SA create HIVE commission?

No.

Does transferring SA create new SA provision?

No.

Can I use SA to buy a Product?

Yes, for eligible purchases.

Can I use SA for 100% of a purchase?

The current architecture permits eligible fully SA-funded purchases.

What happens to SA after I use it for a purchase?

The serial moves to Treasury according to the current circulation model.

Does the SA disappear?

No.

Can Treasury use it again?

Yes. It may be recycled into a future valid entitlement.

Can I redeem SA for cash?

The current system model allows cash redemption according to programme rules.

What happens to the SA when I redeem it?

After successful redemption settlement, it returns to Treasury.

Can the same SA circulate many times?

Yes. Its serial history is preserved through every valid movement.

Does recycling increase total SA supply?

No.

What increases total SA supply?

New minting.

What is the Pool?

The Pool is treated as a view of Treasury-available SA, not a separate stock owner.

Is Pool SA added on top of Treasury SA when calculating total supply?

No.

What is total SA supply?

At current-state level, member-held SA plus Treasury-held SA.

Is pending provision included in total SA supply?

No. Pending provision is not yet a whole serial-numbered SA.

Why distinguish new SA and recycled SA?

To prevent double counting and to understand whether total supply actually increased.

What is the Treasury counter or sponsorship ledger?

It is an internal balancing ledger that moves with Treasury SA at the current reference value. Final public terminology will be determined later.

Does Treasury automatically receive a new SA every time sales occur?

No. Sales create provision/entitlement. Treasury receives SA when existing SA returns through approved circulation.

Does Commerce own SA?

No.

What does Commerce do?

Commerce supplies authoritative sales and transaction facts and coordinates SA usage in commercial transactions.

Who owns SA serial identity?

The SA Registry.

Can an Admin simply change my SA balance?

Administrative corrections should use controlled, auditable transactions rather than casual balance editing.

Can one SA belong to two members simultaneously?

No.

What happens if I try to spend the same SA twice?

Reservation, ownership validation, and atomic state changes should prevent double use.

What happens if an SA transaction is reversed?

An explicit compensating transaction is recorded. The original history is preserved.

Is the SA-funded eligible-sales formula final?

Not yet. The architecture supports SA-funded purchases, but the precise basis for generating new provision from those purchases must be explicitly locked before financial implementation.

8.82 Chapter Summary

SA is a circulating, serial-numbered MICROBA programme unit.

The core rules are:

the current reference value is Rp30,000 per SA;
the current provision reference is 3% of eligible sales;
small eligible sales create backend provision rather than fractional

SA;

SA is issued as whole serial-numbered units;
valid provision creates whole-SA entitlement;
entitlement does not automatically mean minting;
Treasury is checked first;
existing Treasury SA is recycled before new SA is minted;
recycled SA preserves its serial number;
only shortages create newly minted SA;
Pool is a view of Treasury-available inventory, not a separate stock

owner;

total current SA supply equals member-held SA plus Treasury-held SA;
members may hold, transfer, gift, donate, use, and redeem eligible

SA according to programme rules;

SA used for purchases returns to Treasury;
cash-redeemed SA returns to Treasury after successful settlement;
transfers and recycling do not create new sales, HIVE commission, or

SA provision;

the SA Registry preserves identity, lineage, ownership, and

transaction history;

Treasury may use an internal sponsorship/counter ledger that moves

with SA inventory at the reference value;

member and operational dashboards should show simple understandable

numbers;

detailed ledgers remain behind those numbers for audit and

reconciliation;

Commerce provides authoritative commercial facts;
HIVE and SA remain separate mechanisms;
SA operations require idempotency, ownership validation, reservation

where needed, reversals, and auditability; and

the exact eligible-sales basis for partly or fully SA-funded

purchases remains an explicit rule that must be finalized before financial implementation.

8.83 Source-of-Truth Note

This chapter is the general source of truth for the current MICROBA SA system model.

SA owns provision interpretation, whole-SA entitlement, serial identity, member holdings, transfers, gifts, donations, purchase-use movement, redemption movement, Treasury circulation, recycling, minting, lineage, and SA reconciliation.

Commerce owns Orders, payment lifecycle, commercial transactions, and authoritative sales facts. HIVE owns Direct Sponsor relationships and sponsorship commission. Profile may display SA information but does not own the SA ledger.

The current economic references are 3% of eligible sales and Rp30,000 per SA. Treasury is the balancing reservoir, Pool is a view of Treasury-available SA, and recycled SA must be used before new SA is generated.

The precise eligible-sales basis for new SA provision on partly or fully SA-funded purchases remains intentionally open and must be formally locked before financial implementation. Public wording, legal terminology, tax treatment, accounting presentation, redemption controls, and dashboard labels may be refined separately without silently changing the underlying circulation architecture.