A pack rips when creator fees push the vault past pack cost. Five cards, one transaction, every draw recomputable from the chain.
The program never rips on a schedule. It rips inside the same transaction that moved the vault across 2 SOL, which is always a trade. The entropy comes from the pool's reserves at that instant, the signature of the fill that crossed the line, and the hash of the slot. Anyone can take those three inputs, hash them, and see the same five draws the program saw.
| RARITY | DRAW RANGE | SHARE | BAND WIDTH | WEIGHT |
|---|---|---|---|---|
| common | 0 to 39321 | 60.00% | ±40% | 1 |
| rare | 39322 to 55705 | 25.00% | ±20% | 2 |
| holo | 55706 to 63569 | 12.00% | ±10% | 4 |
| gem | 63570 to 65273 | 2.60% | ±4% | 8 |
| shiny | 65274 to 65535 | 0.40% | ±10% | 4 |
The draw is a 16 bit number. The range it lands in sets the rarity, and the rarity sets everything the card is: how wide its band is, how much of the pack's 2 SOL it receives, and whether its fees compound or burn. Weight is the card's share of the pack: a pack's 2 SOL is split in proportion to the weights of its five cards, half kept as SOL and half swapped to the token in the rip transaction.
Reserves are read from the pool account, not reported by anyone. The fill signature is the signature of the transaction doing the rip. The slot hash is read from the slot hashes sysvar. The three are concatenated in that order and hashed once with sha256.
| RIP | SLOT | ENTROPY | VAULT BEFORE | VAULT AFTER | DRAWS | CARDS |
|---|
A rip's vault after is its vault before minus 2 SOL. If they ever differ by anything else the program is wrong and the chain will show it.