> For the complete documentation index, see [llms.txt](https://smart-global.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://smart-global.gitbook.io/docs/smart-contracts/smart-global-pay/operational-functions.md).

# Operational Functions

## Technical Reference: Member and Owner Operational Functions

Owner Definition: A user who registers a position in the network by purchasing educational packages and interacting with the `becomeOwner` function acquires control over their node and associated on-chain rewards. The functions in this section operate based on the programmed mathematical logic of the smart contract to manage reward distribution and account settings.

### 1. Protocol Terms Acceptance Function (`agreeToStart`)

Function Signature: `function agreeToStart() external`

#### 💡 Logic and Application

Executing this function constitutes the user's formal acceptance of the protocol's rules and conditions. Calling this function is a mandatory prerequisite for registering in the ecosystem via the `becomeOwner` function.

#### 🧮 System State Change

\[ The `hasAgreed` state variable for the calling address updates from `False` to `True` ]

#### 🛡️ Execution Conditions and Restrictions

* Transaction Authenticity: The caller must be an Externally Owned Account (EOA) (`tx.origin == msg.sender`).
* No Duplicate Execution: The `hasAgreed` state variable for the caller must evaluate to `False`.

### 2. Ownership Registration and Entry Function (`becomeOwner`)

Function Signature: `function becomeOwner(address uplineAddress) external nonReentrant`

#### 💡 Logic and Application

This function serves as the entry gateway for users into the protocol. Upon execution, the calling address is registered in the binary structure under the referrer ID (`uplineAddress`). This grants access to the educational packages and allocates an official node in the contract for system reward distributions.

#### 🧮 Financial Allocation and Formula

The execution fee is exactly 100 USDT, which the contract automatically divides into two sections: \[ Total Fee: 100 USDT ] = \[ Reward Distribution Pool Share: 91 USDT ] + \[ Central Bank Treasury Share: 9 USDT ]

* Reward Pool Share (91 USDT / 91%): Retained in the `SmartGlobalPay` contract to provide liquidity for network equilibrium rewards.
* Bank Treasury Share (9 USDT / 9%): Transferred to the `SmartGlobalBank` contract to support liquidity, rank rewards, and native token (`SGT`) buybacks.

#### 🛡️ Execution Conditions and Restrictions

* Transaction Authenticity: The caller must be an EOA (`tx.origin == msg.sender`); invocation by intermediary smart contracts is blocked.
* Upline Validation: The referrer address must not be the zero address (`address(0)`) and must be an already registered owner. The user cannot enter their own address as the referrer.
* Binary Structure Constraint: The designated referrer must not possess more than 2 direct downlines.
* Node Uniqueness: The calling address must not be previously registered.
* Agreement Acceptance: The caller must have previously executed the `agreeToStart` function.
* Network Integrity: The system's starting wallet variable (`startWallet`) must be configured, and the referrer address must reside in a valid relationship chain.
* Financial Authorization: The caller must hold a minimum balance of 100 USDT and have previously granted token withdrawal approval (`Approve`) to the contract.

### 3. Reward Calculation and Distribution Function (`payReward`)

Function Signature: `function payReward() external nonReentrant`

#### 💡 Logic and Application

This function processes point values and distributes the pool profit among qualified members. It can be called by any registered owner. To cover gas costs, the caller receives a direct incentive of 1 USDT per new purchase (up to a maximum ceiling of 40 USDT).

#### 🧮 Financial Calculations and Formula

The point value and reward allocation are calculated based on the instantaneous pool balance and the number of qualified points: \[ USD Value per Point ] = ( \[ USDT Pool Balance ] - \[ Total Caller Incentive ] ) ÷ \[ Total Network Equilibrium Points for the Current Day ] \[ User Reward Share ] = \[ Number of User Equilibrium Points ] × \[ USD Value per Point ]

* 100-Level Fee Deduction Rule: Users whose historical accumulated points (`ownerAllPoint`) reach 100 or more receive 90% of their reward share. The remaining 10% is deducted: 5% is transferred to the founder's account, and 5% remains in the pool.
* Point Settlement: Following reward distribution, the matched equilibrium points from both the left and right branches of the user are zeroed out.

#### 🛡️ Execution Conditions and Restrictions

* Transaction Authenticity: The caller must be an EOA.
* Authentication: The caller must be a registered owner.
* Global Time Interval: At least 1 hour must have elapsed since the last successful network reward distribution.
* Individual Time Interval: Each owner address can execute this function strictly once every 24 hours.
* Caller Earnings Ceiling: The total rewards received by the caller for executing this function must not exceed 40 USDT.
* Network Equilibrium Existence: The total calculable points across the network must be greater than zero.

### 4. Daily Point Limit Upgrade Function (`maxPoint`)

Function Signature: `function maxPoint(address Left_100, address Right_100) external`

#### 💡 Logic and Application

The default reward ceiling for each owner is 5 points per distribution cycle. This function allows owners to permanently upgrade this ceiling to 10 points per cycle by verifying two qualified senior sellers within their downline structure (one in the left branch, one in the right branch).

#### 🧮 System State Change

This function incurs no financial cost. Upon verification: \[ The `hasMaxPoint` state variable for the calling address updates from `False` to `True` ]

#### 🛡️ Execution Conditions and Restrictions

* Authentication: The caller must be a registered owner.
* No Duplicate Execution: The caller must not have successfully executed this function previously (`hasMaxPoint == false`).
* Branch Validity: `Left_100` must reside within the caller's left branch downline; `Right_100` must reside within the right branch downline.
* Point Qualification: Both `Left_100` and `Right_100` addresses must have accumulated at least 100 points in their activity history.

### 5. New Wallet Data Migration Function (`changeWallet`)

Function Signature: `function changeWallet(address newAddress) external nonReentrant`

#### 💡 Logic and Application

This function transfers a node's data (including user ID, point history, ranks, upline address, and direct downline addresses) to a new wallet address. Execution requires a 10 USDT fee, which is deposited to the bank contract (`smartBank`).

#### 🧮 System State Change

\[ Deposit 10 USDT to Bank ] + \[ Transfer Node Data to New Address ] + \[ Delete Information from Old Address ]

#### 🛡️ Execution Conditions and Restrictions

* Transaction Authenticity: The caller must be an EOA.
* Destination Address Validation: `newAddress` must not be the zero address (`address(0)`) and must not already hold a registered node.
* Source Authentication: The caller must be a registered owner.
* Profit Distribution Time Restriction: The calling address must not be in the current day's new registrations list (`dailyNewOwners`). Migration is restricted until after the daily profit distribution is executed.
* Node Lock Absence: Wallet migration capability must not be blocked (`isWalletLocked == false`).
* Binary Structure Integrity: The upline and direct downlines of the node must be valid.
* Financial Authorization: The caller must possess a minimum balance of 10 USDT and have granted withdrawal approval (`Approve`).

### 6. Node Migration Blocking Function (`dontChangeWallet`)

Function Signature: `function dontChangeWallet() external`

#### 💡 Logic and Application

Owners can utilize this function to permanently and irreversibly disable the wallet replacement capability (`changeWallet` function) for their address.

#### 🧮 System State Change

\[ The `isWalletLocked` state variable for the calling address updates to `True` ]

#### 🛡️ Execution Conditions and Restrictions

* Authentication: The caller must be a registered owner in the protocol.

### 7. Network Point Calculation and Processing Function (`pointBroadcast`)

Function Signature: `function pointBroadcast() external nonReentrant`

#### 💡 Logic and Application

This function executes computational updates for the binary tree. It processes points from new members registered on the current day (`dailyNewOwners`) across all upline branches up to the network root, updating point variables and ranks.

#### 🧮 System State Change

\[ Calculate left and right branch points of uplines based on the daily new members list ] \[ Update ranks and reset the daily new member index variable: `newOwnerIndex = 0` ]

#### 🛡️ Execution Conditions and Restrictions

* Transaction Authenticity: The caller must be an EOA.
* Authentication: The caller must be a registered owner.
* Processing Queue Existence: The daily new member index (`newOwnerIndex`) must be greater than zero.

### 8. Delay Condition Refund Function (`payBack`)

Function Signature: `function payBack() external nonReentrant`

#### 💡 Logic and Application

This function serves as a capital protection mechanism for new owners. If the daily reward distribution (`payReward`) is delayed by more than 24 hours, this function activates. Executing it cancels unprocessed memberships from the current day and directly refunds 90 USDT to the respective new members' wallets.

#### 🧮 Financial Formula and State Change

\[ Total Refundable Volume ] = \[ Number of Unprocessed New Members (`newOwnerIndex`) ] × 90 USDT \[ Reset daily queues: `newOwnerIndex = 0` and `eligibleOwnersCount = 0` ]

#### 🛡️ Execution Conditions and Restrictions

* Caller Qualification: The historical accumulated points of the calling address must be greater than 1 point.
* Delay Time Condition: At least 24 hours must have elapsed since the last scheduled reward distribution (`block.timestamp > lastDistributionTime + 24 hours`).

##