> 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-token/operational-functions.md).

# Operational Functions

## Technical Reference: Token Operational Functions

The functions in this section represent the interface for user interactions with the `SmartGlobalToken` smart contract. Users invoke these functions to transfer `SGT` tokens, issue spending approvals (`Approve`), and manage token balances. These functions implement the ERC-20 standard, integrated with trading tax logic and transaction limits.

### 1. Direct Token Transfer Function (`transfer`)

Function Signature: `function transfer(address to, uint256 amount) public virtual override returns (bool)`

#### 💡 Logic and Application

This function transfers `SGT` tokens from the caller's wallet to a target address (`to`). During execution, the system evaluates trading status, maximum transfer limits, and tax deductions.

#### 🧮 Computational Logic, Tax, and State Change

Across all token transfers, control parameters are evaluated:

* Standard Transfer Mode (Wallet-to-Wallet): Transfers between standard personal wallets (excluding the PancakeSwap exchange pool) incur a 0% tax. 100% of the volume is delivered to the recipient.
* Exchange Trading Mode (Buy / Sell): If the sender or recipient is the exchange liquidity pool (`pancakePair`), a 5% tax (`taxFee`) is deducted from the transaction amount and routed to the ecosystem tax treasury (`taxWallet`).
* Final Settlement Calculation During Trades: \[ Tax Treasury Share ] = (Total Transfer Amount × 5) ÷ 100 \[ Payout to Buyer / Seller ] = Total Transfer Amount - Tax Treasury Share

#### 🛡️ Execution Conditions and Restrictions

* Destination Address Validation: The recipient address must not evaluate to the zero address (`address(0)`).
* Sufficient Balance: The sender's balance must be greater than or equal to the transfer amount (`amount`).
* Trading Enablement Control: If public trading is not activated (`!tradingEnabled`), transfers are blocked unless the sender or recipient is registered in the fee exclusion list (`_isExcludedFromFees`).
* Transaction Limit: During buy or sell transactions on the PancakeSwap pool, the transfer amount must not exceed the maximum transaction ceiling (`maxTxAmount`) (`require(amount <= maxTxAmount)`).

### 2. Token Spending Approval Function (`approve`)

Function Signature: `function approve(address spender, uint256 amount) public virtual override returns (bool)`

#### 💡 Logic and Application

This function grants spending allowances to an intermediary smart contract or decentralized exchange (e.g., PancakeSwap Router, payment contract, or central bank). The user specifies the maximum token limit the `spender` is authorized to withdraw from their wallet.

#### 🧮 System State Change

\[ The spending allowance for the `spender` in the `allowances` mapping updates to `amount` ] \[ An `Approval` event is emitted onto the blockchain ]

#### 🛡️ Execution Conditions and Restrictions

* Address Validation: Neither the token owner nor the `spender` may evaluate to the zero address.

### 3. Third-Party Intermediary Transfer Function (`transferFrom`)

Function Signature: `function transferFrom(address from, address to, uint256 amount) public virtual override returns (bool)`

#### 💡 Logic and Application

Executed by intermediary smart contracts to transfer tokens from a user wallet (`from`) to a target destination (`to`). Execution requires that the user has previously granted a sufficient spending allowance to that contract via the `approve` function.

#### 🧮 System State Change and Calculations

\[ Deduct `amount` from the intermediary's spending allowance ] \[ Deduct tokens from the source balance and apply the 5% tax logic if trading via the exchange pool ] \[ Deposit the net token volume to the destination address ]

#### 🛡️ Execution Conditions and Restrictions

* Allowance Ceiling: The invoking intermediary must hold a sufficient spending allowance (`require(currentAllowance >= amount)`).
* Trading Restrictions: Conditions regarding trading enablement, transaction ceilings (`maxTxAmount`), and the 5% exchange trading tax apply.

### 4. Allowance Management Functions (`increaseAllowance` / `decreaseAllowance`)

Function Signatures: `function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool)` `function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool)`

#### 💡 Logic and Application

These functions provide alternatives to the standard `approve` function to adjust spending allowances. A user can increase (`increaseAllowance`) or decrease (`decreaseAllowance`) an intermediary's allowance by a precise numerical value without resetting the allowance to zero first.

#### 🧮 System State Change

* For Increase: Replaced with current allowance + `addedValue`.
* For Decrease: Replaced with current allowance - `subtractedValue`.

#### 🛡️ Execution Conditions and Restrictions

* Underflow Prevention: In the decrease function, the subtracted value must not exceed the current total allowance held by the intermediary (`require(currentAllowance >= subtractedValue)`).