The ledger
Ownership is a state machine, not a database promise. Every balance is the result of valid transitions applied in order.
What stops a token from being created out of thin air, or spent twice?
A QLYP balance is not a number someone typed in. It is what you get when you take the chain's history from a fixed starting point and apply every valid operation, in order, under published rules. Run it again tomorrow, on another machine, and you get the same ledger.
Units never multiply
For every asset, one equation holds after every block:
Conservation
Available + reserved = minted ≤ maximum supply
Minting raises the supply and a holder's balance together. A transfer debits one balance and credits another. An offer moves units from available into a reservation; a sale moves them to the buyer, a release returns them to the seller. None of these paths creates a unit.
- 01 / 05
Alice mints 1,000
A mint raises the issued supply and Alice’s available balance together. Nothing else can create units: there is no administrator who can edit a balance.
- 02 / 05
She offers 400 to Bob
Creating a valid offer moves 400 units out of her available balance into a reservation. They still exist, and still count toward the supply, but she can no longer spend them.
- 03 / 05
She tries to send 700
Only 600 are available, so the transfer is rejected. The journal records the verdict, and nothing moves: no partial transfer, no sequence advance. Reserved units cannot be spent twice.
- 04 / 05
Bob buys the offer
Bob’s canonical purchase settles the reservation: the 400 units go to him. Delivery is a rule applied to the chain history, not a server deciding to send them.
- 05 / 05
Cleanup changes nothing
A later cleanup of the used proposal cannot credit Alice again, because the ticket is already settled. At every step, available plus reserved equals the 1,000 minted.
What the state remembers
| Part | What it records |
|---|---|
| Assets | Creator, the immutable definition and the supply minted so far |
| Balances | The spendable quantity for each account and asset |
| Sequences | The next accepted QLYP sequence for each account |
| Reservations | Every offer's lot, from creation to sale, cancellation or expiry |
| Symbols | The first valid token that claimed each symbol |
| Journal | Every operation's verdict, accepted or rejected, for inspection |
Beyond the equation above, the rules check that balances are never negative, that every symbol points to its asset, and that the parts agree with each other. These checks catch more than overspending: they catch any internal disagreement about the same ledger.
Replayed in order, committed only when valid
Each finalized block is applied to a copy of the previous state. A rejected operation adds a verdict to the journal and nothing else: no partial transfer, no sequence advance. Only when the whole block has been applied, and every check still holds, does the new state replace the old one.
A malformed or unauthorized operation is simply rejected. A broken chain link, an inconsistent receipt or an unknown runtime is different: that is an integrity problem, and the indexer stops rather than invent a plausible ledger.
No administrator
The rules define no balance editor, no mutable issuance policy and no automatic bridge. An implementation that inserts a balance outside an accepted transition is not computing the QLYP ledger.