diff --git a/public/contract.html b/public/contract.html index 616467e..aa624a0 100644 --- a/public/contract.html +++ b/public/contract.html @@ -1,31 +1,31 @@ -Smart Contract Security | Crypto Team Build - - - - - -
-
-
Plain-language code review

Can the bottom fall out of this? We read the code.

Every payment in the RM Circle runs through one smart contract on the Polygon blockchain. We reviewed its complete, verified source line by line. Here's what it says — in plain language, with links so you can check every claim yourself. Nobody has to take our word for anything.

- -
NetworkPolygon Mainnet
Source verifiedExact match ↗
- -

1. The code can never change.

Some crypto projects use "upgradeable" contracts — the operator can swap in new code after you've joined, changing the rules underneath you. This contract has none of that machinery. No proxy, no delegatecall, no self-destruct — the three mechanisms that allow post-launch changes are simply absent from the code. What was deployed on May 27, 2026 is what runs today and what will run in ten years. And because the source is verified as an exact bytecode match, the code we reviewed is provably the code that's running — not a copy, not a claim.

- -

2. Member money never sits in the contract.

There is no pool, no vault, no balance an operator could run away with. When someone joins or upgrades, the contract splits and delivers every coin in the same transaction — sponsor reward, upline payment, fees — straight to member wallets. If any single transfer fails, the whole transaction reverses and nobody pays anything. You can watch this happen live on the payment proof feed: money in, money out, same block.

- -

3. The prices and payout rules are locked.

Entry and upgrade costs for all 8 levels were fixed the moment the contract deployed — there is no function to change them. The payout split is compiled into the code as constants: on entries, the sponsor receives the slot cost minus a 5% project fee (founders 1% + 1%, development 3%); on upgrades, 100% goes to the eligible upline — the project takes nothing. There's also no pause switch: nobody can freeze joins, upgrades, or payouts. The eligibility rule is public too: an upgrade payment stops at the first upline who is qualified (2 directs) and already at that level — otherwise it passes them and continues up.

- -

4. What the operator CAN do — the honest list.

A fair review reports the levers, not just the locks. The contract owner can do exactly four things:

  • Raise or lower the entry fee percentage (currently 5%, hard-capped at 50% in the code). This affects the price of future joins only — it can't touch anyone's earnings, and any change is instantly visible on the blockchain.
  • Redirect the project's own fee wallets (founder/development shares) — their revenue, never member payouts.
  • Sweep out coins accidentally sent to the contract address — member payment flows never leave a balance behind.
  • Transfer ownership of those same limited powers to someone else.

What the owner cannot do: take member funds, change payout rules, change prices, reroute earnings, block withdrawals (there's nothing to withdraw — payments are instant), or replace the code. Even a fully hostile owner is limited to that list above.

- -

5. Where "missed" payments go.

When an upgrade payment finds no eligible upline within 16 levels (or reaches the root), it goes to the project's fee wallet rather than vanishing. That's the strongest built-in reason to get your 2 directs and keep your level current — eligible positions catch payments; ineligible positions watch them pass by. The Member Dashboard shows exactly this happening in real time.

- -

Check it yourself — please.

- -
What this page is not: code security is not an income guarantee. This review says the rules can't change underneath you — it does not promise the program grows, that positions fill, or that POL holds its value. Results depend on real participation and duplication, and POL's market price moves. Never use funds you can't afford to lose.
- -

Review method: complete verified source (Sourcify exact-match, creation + runtime bytecode) read against the deployed contract on 2026-08-13; payout math cross-checked against live on-chain transactions. Reviewed independently by this team's tooling — not by the contract's developers.

-
-
- - +Smart Contract Security | Crypto Team Build + + + + + +
+
+
Plain-language code review

Can the bottom fall out of this? We read the code.

Every payment in the RM Circle runs through one smart contract on the Polygon blockchain. We reviewed its complete, verified source line by line. Here's what it says — in plain language, with links so you can check every claim yourself. Nobody has to take our word for anything.

+ +
NetworkPolygon Mainnet
Source verified (Sourcify)Exact match ↗
+ +

1. The code can never change.

Some crypto projects use "upgradeable" contracts — the operator can swap in new code after you've joined, changing the rules underneath you. This contract has none of that machinery. No proxy, no delegatecall, no self-destruct — the three mechanisms that allow post-launch changes are simply absent from the code. What was deployed on May 27, 2026 is what runs today and what will run in ten years. And because the source is verified as an exact bytecode match, the code we reviewed is provably the code that's running — not a copy, not a claim.

"But Polygonscan says it's not verified?" Sharp eye — there are two separate verification registries, and they don't share data. The source was published to Sourcify ↗, the open-source registry, which confirmed an exact match against both the deployed bytecode and the creation bytecode (Solidity 0.8.28, verified 2026-05-27). Polygonscan runs its own registry, and nobody has submitted the source there yet — so it shows raw bytecode. That's a paperwork gap, not a code gap: the bytecode Polygonscan displays is byte-for-byte the same bytecode Sourcify matched, and anyone can compare the two. Publishing the same source on Polygonscan is possible for anyone with the source file (not just the creator) — it's in progress for this contract.

+ +

2. Member money never sits in the contract.

There is no pool, no vault, no balance an operator could run away with. When someone joins or upgrades, the contract splits and delivers every coin in the same transaction — sponsor reward, upline payment, fees — straight to member wallets. If any single transfer fails, the whole transaction reverses and nobody pays anything. You can watch this happen live on the payment proof feed: money in, money out, same block.

+ +

3. The prices and payout rules are locked.

Entry and upgrade costs for all 8 levels were fixed the moment the contract deployed — there is no function to change them. The payout split is compiled into the code as constants: on entries, the sponsor receives the slot cost minus a 5% project fee (founders 1% + 1%, development 3%); on upgrades, 100% goes to the eligible upline — the project takes nothing. There's also no pause switch: nobody can freeze joins, upgrades, or payouts. The eligibility rule is public too: an upgrade payment stops at the first upline who is qualified (2 directs) and already at that level — otherwise it passes them and continues up.

+ +

4. What the operator CAN do — the honest list.

A fair review reports the levers, not just the locks. The contract owner can do exactly four things:

  • Raise or lower the entry fee percentage (currently 5%, hard-capped at 50% in the code). This affects the price of future joins only — it can't touch anyone's earnings, and any change is instantly visible on the blockchain.
  • Redirect the project's own fee wallets (founder/development shares) — their revenue, never member payouts.
  • Sweep out coins accidentally sent to the contract address — member payment flows never leave a balance behind.
  • Transfer ownership of those same limited powers to someone else.

What the owner cannot do: take member funds, change payout rules, change prices, reroute earnings, block withdrawals (there's nothing to withdraw — payments are instant), or replace the code. Even a fully hostile owner is limited to that list above.

+ +

5. Where "missed" payments go.

When an upgrade payment finds no eligible upline within 16 levels (or reaches the root), it goes to the project's fee wallet rather than vanishing. That's the strongest built-in reason to get your 2 directs and keep your level current — eligible positions catch payments; ineligible positions watch them pass by. The Member Dashboard shows exactly this happening in real time.

+ +

Check it yourself — please.

+ +
What this page is not: code security is not an income guarantee. This review says the rules can't change underneath you — it does not promise the program grows, that positions fill, or that POL holds its value. Results depend on real participation and duplication, and POL's market price moves. Never use funds you can't afford to lose.
+ +

Review method: complete verified source (Sourcify exact-match, creation + runtime bytecode) read against the deployed contract on 2026-08-13; payout math cross-checked against live on-chain transactions. Reviewed independently by this team's tooling — not by the contract's developers.

+
+
+ +