The rules of the Oort Cloud Bull (OCB) contract are based on its code, which follows the standard practices of an ERC20 token with some added features from OpenZeppelin’s Own-able module and custom error handling from ERC-6093. Below is a breakdown of the main rules and functionalities:

1. Token Supply and Ownership:

• Fixed Total Supply: Upon deployment, 500 million tokens are minted and assigned to the owner. This means there will be no more tokens created (no minting function after deployment).

• Ownership: The contract is ownable, meaning that only the owner (the address specified at deployment) has control over administrative functions, such as transferring ownership to another address.

2. Basic ERC20 Functionality:

• Transfers: Tokens can be transferred between addresses, as long as the sender has enough tokens in their balance.

• Approvals and Allowances: Users can approve a third party (like a smart contract or another user) to spend a specified amount of their tokens.

• Balance Queries: Any user can check their token balance or the total supply of tokens in circulation.

3. Custom Errors (ERC-6093):

• The contract uses custom errors to provide more detailed feedback in cases where transactions fail. For example:

• ERC20InsufficientBalance: The sender doesn’t have enough tokens to complete the transfer.

• ERC20InvalidSender: The address attempting the transfer is invalid (e.g., address(0)).

• ERC20InsufficientAllowance: The spender doesn’t have enough approval from the owner to transfer tokens on their behalf.

4. Ownership Transfer Rules:

• TransferOwnership: The owner has the ability to transfer ownership to another address, but the new owner cannot be a null address (address(0)).

• Renouncing Ownership: The owner can renounce ownership, which leaves the contract without an owner. This disables functions that require an owner and decentralizes control.

5. No Token Burning or Additional Minting:

• The contract does not have a function to burn tokens (reduce the total supply), nor does it allow minting new tokens after deployment.

6. Security Measures:

• Transactions involving invalid sender or receiver addresses (like address(0)) are blocked, protecting against errors or malicious activities.

• Allowance adjustments are carefully handled to prevent the “allowance double-spend” issue, a common risk in ERC20 implementations.

In summary, this contract ensures basic ERC20 rules with enhanced security and ownership management. The owner has full control over the initial supply, and ownership can be transferred but not further minted or burned, maintaining supply integrity.