Apply the Academy to Stable Circle, a participation-based reward platform managed by an immutable smart contract: understand SC5, token and gas requirements, registration, FIFO placement, automatic upgrades, verification and safety controls.
1Lesson 1
Stable Circle: the Academy product and the on-chain system
Stable Circle combines an educational product with a participation-based reward platform managed by an immutable smart contract. Learners should understand the difference between those layers.
The Crypto Safety & Web3 Academy is the educational product: it teaches wallets, networks, transactions, scams, smart contracts, tax awareness and digital safety. Its value should stand on its own even if a learner never uses the Stable Circle contract.
Stable Circle is a participation-based reward platform managed by an immutable smart contract. The checked-in contracts/StableCircle.sol implementation is the fixed SC5 design: it implements a deterministic four-level placement matrix using one configured token on BNB Smart Chain.
That source file does not contain an SC15 entry schedule or a constructor parameter that can change the four level amounts. Any SC15 product or deployment must be documented and verified against its own deployed bytecode and source rather than inferred from the SC5 contract.
A website can make the experience easier to use, but the website and smart contract are not the same thing. The contract's recorded state and events can be independently checked on-chain.
💡 Why this mattersSeparating product, interface and contract prevents confusion about what is educational content and what is an irreversible blockchain transaction.
🧪 Practical exerciseWrite down the three layers: Academy product, Stable Circle website/interface, Stable Circle smart contract. For each, identify what it does and what happens if that layer is temporarily unavailable.
✅ Key takeaways- The Academy is the education product.
- StableCircle.sol currently implements fixed SC5 amounts, not SC15.
- The website is an interface, not the blockchain itself.
2Lesson 2
The configured payment token, BNB gas and exact-token verification
Stable Circle accepts the exact token contract configured at deployment; the ticker alone is not enough.
The current contract stores one immutable ERC20-compatible payment-token address and accepts tokens using either 6 or 18 decimals. Users must therefore verify the exact BNB Smart Chain token specified by the official Stable Circle interface and contract information.
BNB is separate from the Stable Circle payment token. BNB pays BNB Smart Chain gas for approvals, registration and other state-changing transactions.
A wallet can display many tokens with similar names. The correct asset is identified by network and contract address, not by logo or ticker alone.
💡 Why this mattersSending or approving the wrong token can fail or place funds somewhere the intended contract cannot use.
🧪 Practical exerciseBefore registration, verify three things independently: BNB Smart Chain is selected, the payment-token contract matches the official reference, and the wallet has enough BNB for gas.
⚠️
Security warningNever import a Stable Circle payment token from an address sent by an unknown person in a private message.
✅ Key takeaways- Verify network and exact token contract.
- BNB pays gas; it is not the Stable Circle payment token.
- The contract accepts one configured token address.
3Lesson 3
Registration: approval first, then the register transaction
Token approval and Stable Circle registration are two separate blockchain actions with different purposes.
The contract must first be initialised with two unique, non-paying top positions beneath the root. After that one-time setup, the register function takes a referrer account; the caller must not already be registered, cannot refer themselves and must use an already registered referrer.
Before the contract can collect the Level 1 entry amount, the token contract must allow Stable Circle to spend the required amount from the user's wallet. That approval is a token permission; the subsequent register transaction executes the Stable Circle registration logic.
The current SC5 Level 1 entry is 5 payment-token units. The contract collects the exact amount and rejects transfers that do not match the required token amount.
💡 Why this mattersUnderstanding the two-step flow helps users recognise suspicious requests for excessive allowances or unrelated contract calls.
🧪 Practical exerciseAt the wallet preview, identify which transaction is the token approval and which is the Stable Circle register call. Confirm the spender and amount before approving.
✅ Key takeaways- Approval and registration are separate actions.
- Registration opens only after the two top positions are initialised.
- The referrer must already be registered.
- SC5 Level 1 is 5 units of the configured payment token.
4Lesson 4
Referral and placement: direct slots first, then FIFO spillover
Stable Circle records both who referred a member and where that member is placed in the matrix.
Each member can have two direct child positions in the placement tree. If the chosen referrer still has an open direct slot, the new member is placed directly under that referrer.
Once both direct slots are occupied, the contract uses a global FIFO queue of members with open child positions and places the new member at the earliest open position. The referrer relationship is still recorded separately.
This distinction means referral and physical placement are not always the same relationship after spillover begins.
💡 Why this mattersMany matrix misunderstandings come from assuming that every referral must appear directly underneath the referrer in the physical tree.
🧪 Practical exerciseDraw a small two-child tree and simulate five registrations. Fill the referrer's two direct slots, then place later registrations into the earliest open FIFO positions.
✅ Key takeaways- Each placement parent has two child slots.
- Direct slots are used first.
- Spillover uses FIFO placement while the original referrer is still recorded.
5Lesson 5
Four levels, cycle sizes and automatic upgrades
SC5 uses four levels with fixed entry amounts and fixed position counts; completed cycles trigger programmed distributions and upgrades.
The current contract defines Level 1 at 5 units with 2 positions, Level 2 at 10 with 4 positions, Level 3 at 30 with 8 positions and Level 4 at 75 with 16 positions. Gross cycle amounts are therefore 10, 40, 240 and 1,200 respectively.
When a Level 1 cycle completes, the 10-unit gross is used for the automatic Level 2 upgrade. When Level 2 completes, 30 is used for Level 3, 5 is paid to the member and 5 is paid as the admin fee. When Level 3 completes, 75 is used for Level 4 and 165 is paid to the member. When Level 4 completes, 1,200 is paid to the member.
Automatic upgrades credit the placement ancestor at the depth of the new level. If no such ancestor exists, the contract routes that ancestorless upgrade payment to the admin wallet according to the programmed rules.
💡 Why this mattersThe amounts are contract rules, not an earnings guarantee. A cycle only completes when the required qualifying positions are actually credited.
🧪 Practical exerciseCalculate each gross cycle: entry amount × positions required. Then compare the gross with the programmed upgrade, member-payout and admin-fee distribution.
⚠️
Security warningDo not describe the cycle values as guaranteed income. Actual results depend on future registrations, placement activity and the contract continuing to operate as intended.
✅ Key takeaways- SC5 has four fixed levels.
- L2 pays 5 to the member and 5 admin while reserving 30 for upgrade.
- L3 pays 165 to the member and uses 75 for the L4 upgrade.
- L4 pays the 1,200 completed-cycle amount to the member.
6Lesson 6
How to verify Stable Circle activity on-chain
Stable Circle emits events and exposes public state that can be checked without relying only on the dashboard.
The contract records member registrations, placements, spillover placements, top-position initialisation, level activations, cycle credits, cycle completion, upgrades, member payouts, admin-fee payments and delayed recovery actions as on-chain events.
A transaction hash can be searched on the correct BNB Smart Chain explorer. Learners can inspect status, contract address, token movements and emitted logs to confirm what the network recorded.
The contract also exposes read functions and public accounting totals. These are useful evidence, but users should remember that public data shows what the contract did, not whether participation will produce a future financial result.
💡 Why this mattersIndependent verification reduces dependence on screenshots, group messages and support claims.
🧪 Practical exerciseFor a known Stable Circle transaction, verify the network, contract address, transaction status and relevant event or token transfer on the explorer before trusting a screenshot.
✅ Key takeaways- Use transaction hashes and the correct explorer.
- Events provide evidence of contract actions.
- On-chain transparency does not guarantee future outcomes.
7Lesson 7
Stable Circle contract safety controls and their limits
The current contract includes several technical safeguards, but safeguards reduce specific risks rather than eliminating all risk.
The contract uses role-based access control, an emergency pause mechanism, reentrancy protection and safe token-transfer utilities. The admin-wallet change process includes a minimum 48-hour delay before an approved change can execute.
Emergency recovery is restricted to explicitly recorded upgrade reserves, can only execute while the contract is paused and also uses a minimum 48-hour delay. The recovery destination is fixed when the contract is deployed.
The contract tracks received funds, pending cycle funds, upgrade reserves, member payouts, admin fees, ancestorless payments and emergency recoveries, and checks accounting invariants and solvency after key operations.
💡 Why this mattersGood security design is worth understanding, but no contract control can protect a user who gives away a recovery phrase, connects to a cloned website or approves the wrong contract.
🧪 Practical exerciseReview the contract's public roles and pause status on the official explorer. Then list which risks are controlled on-chain and which remain with the user's wallet and device.
✅ Key takeaways- The contract includes pause, access-control and reentrancy safeguards.
- Sensitive admin/recovery changes use delayed execution.
- User-side phishing and wallet security remain separate risks.
8Lesson 8
What Stable Circle code can and cannot control
Code can enforce programmed rules when transactions occur; it cannot control future participation, token stability, website availability or personal security.
The smart contract can deterministically apply placement, level, upgrade and smart contract commission rules to valid transactions submitted to it. That is different from enough future participation occurring to complete a cycle.
The contract does not control the value or issuer of the payment token, BNB gas prices, wallet-provider availability, the user's device, tax obligations, regulatory changes or whether a malicious third party creates a fake Stable Circle link.
The Academy's purpose is therefore to help members understand and verify the technology rather than promise financial outcomes. Participation remains a personal decision.
💡 Why this mattersThe most important lesson is the difference between deterministic contract logic and uncertain real-world outcomes.
🧪 Practical exerciseMake two columns: 'The contract can enforce' and 'Outside the contract's control'. Put placement and smart contract commission rules in the first column; put future participation, personal outcomes and wallet security in the second.
⚠️
Security warningNever treat 'the contract is on-chain' as proof of a particular financial outcome.
✅ Key takeaways- Deterministic logic does not create a certain outcome.
- External services and user security remain outside the contract.
- Education and independent verification are core Stable Circle safety principles.