
Pegasus Bot
Smart Contract Audit Report
Audit Summary
Pegasus Bot is a new ERC-20 token on Arbitrum.
For this audit, we reviewed the project team's PegasusBot contract at 0x8933fedd98cbb482e27c41e1bd7216a4e42ebd39 and Account contract at 0x9b86b5d42CAAe045984435CdC6B7d1E70340e016 on the Arbitrum Mainnet.
Audit Findings
Informational findings were identified and the team may want to review them. In addition, some centralized aspects are present.
Date: August 22nd, 2023.Finding #1 - Account - Informational
Description: The following state variables can only be set one time in the constructor but are not declared immutable.
Recommendation: The above state variables could be declared immutable for additional gas savings on each reference.botAddress, igmxOrder, igmxPosition, igmxReader, igmxRouter
Finding #2 - Account - Informational
Description: ThecontractAddressstate variable is not used in the contract.
Recommendation: This state variable should either be removed to reduce contract size and deployment costs or utilized in a way that fits the project team's intended functionality.
Finding #3 - PegasusBot - Informational
Description: Although the SafeMath library is utilized, the contract is deployed with Solidity v0.8.9 which has built-in overflow checks.
Recommendation: SafeMath could be safely removed to reduce contract size, deployment costs, and gas costs on all transactions that utilize it.
Contracts Overview
PegasusBot Contract:Account Contract:
- The total supply of the token is currently ~9.77 million $PGS [9,769,032].
- At the time of writing this report, there are 198 total token holders. The token allocation is as follows:
- 44.52% of the total supply is in Camelot liquidity.
- Of that liquidity, 99.47% of the LP tokens are locked in a token locking contract and will unlock on February 4th, 2024.
- 35% of the total supply has been sent to the PegaClaim contract.
- 4.06% of the total supply has been sent to a GnosisSafeProxy contract.
- The next five holders own a cumulative 5.55% of the total supply.
- The contract interacts with an external Shield contract during transfers. The Shield contract was out of scope for this audit so our team is unable to provide an assessment with regard to its security.
- If the recipient of a transfer is the Plan contract, the subscription process is triggered on behalf of the sender. If the sender's newly set subscription end date exceeds the previous end date, 10% of the tokens are sent to the "Team" address sey by the owner and the remaining 90% is burned.
- The Plan contract was out of scope for this audit so our team is unable to provide an assessment with regard to its security.
- There is a Buy fee and Sell fee charged on all buys and sells via an approved DEX when fees are currently enabled by the owner.
- 50% of the tokens collected through the fee are burned to reduce the total supply.
- 30% of the tokens are sent to the "Com" address set by the owner.
- 20% of the tokens are sent to the "Team" address set by the owner.
- As the contract is deployed with Solidity v0.8.9, it is protected from overflows/underflows.
- The contract complies with the ERC-20 token standard.
- The owner can set the Buy fee and Sell fee to any percentages at any time.
- The owner can enable/disable the Buy fee and Sell fee at any time.
- The owner can set the Plan and Shield contract addresses to any addresses at any time.
- The owner can add/remove any address from the approved DEX list at any time.
- The owner can set the Team and Com fee addresses to any addresses at any time.
- The owner can set the DEX Router to any address at any time.
- The owner can use this contract to execute transactions using a specified Gnosis Safe contract.
- Each transaction will include the address of the Gnosis Safe contract that will execute the transaction, the recipient, the amount of ETH to send, data payload for the transaction, the amount of gas to be used, a base amount of gas, the gas price, the token address to be used as payment for the gas fee, an address that will receive a potential refund (in case gas used is less than the estimated gas), a signature, and a boolean flag to indicate if the transaction should transfer gas fees after execution.
- The recipient address must have been added to the "allowed" list of addresses by the owner.
- The balance returned from the Gnosis Safe address must exceed the contract's minimum value.
- The transaction is executed in the Gnosis Safe contract using the details provided by the owner.
- The Gnosis Safe contract(s) was out of scope for this audit so our team is unable to provide an assessment with regard to its security.
- If the owner specifed that gas fees should be transferred after execution, the calculated amount of gas fees are transferred to the bot address set by the deployer.
- The owner can send all of the ETH in the contract to the Bot address at any time.
- The owner can withdraw any tokens from the contract at any time.
Audit Results
| Vulnerability Category | Notes | Result |
|---|---|---|
| Arbitrary Jump/Storage Write | N/A | PASS |
| Centralization of Control | The owner can set the Buy fee and Sell fee to any percentages at any time in the PegasusBot contract. | WARNING |
| Compiler Issues | N/A | PASS |
| Delegate Call to Untrusted Contract | N/A | PASS |
| Dependence on Predictable Variables | N/A | PASS |
| Ether/Token Theft | N/A | PASS |
| Flash Loans | N/A | PASS |
| Front Running | N/A | PASS |
| Improper Events | N/A | PASS |
| Improper Authorization Scheme | N/A | PASS |
| Integer Over/Underflow | N/A | PASS |
| Logical Issues | N/A | PASS |
| Oracle Issues | N/A | PASS |
| Outdated Compiler Version | N/A | PASS |
| Race Conditions | N/A | PASS |
| Reentrancy | N/A | PASS |
| Signature Issues | N/A | PASS |
| Sybil Attack | N/A | PASS |
| Unbounded Loops | N/A | PASS |
| Unused Code | N/A | PASS |
| Overall Contract Safety | PASS |
PegasusBot Contract

($) = payable function
# = non-constant function
Int = Internal
Ext = External
Pub = Public
+ Context
- [Int] _msgSender
- [Int] _msgData
+ Ownable (Context)
- [Pub] #
- [Pub] owner
- [Pub] renounceOwnership #
- modifiers: onlyOwner
- [Pub] transferOwnership #
- modifiers: onlyOwner
+ [Lib] SafeMath
- [Pub] wad
- [Pub] ray
- [Int] add
- [Int] sub
- [Int] sub
- [Int] mul
- [Int] div
- [Int] div
- [Int] mod
- [Int] mod
- [Int] min
- [Int] max
- [Int] sqrt
- [Int] wmul
- [Int] wmulRound
- [Int] rmul
- [Int] rmulRound
- [Int] wdiv
- [Int] wdivRound
- [Int] rdiv
- [Int] rdivRound
- [Int] wpow
- [Int] rpow
+ [Int] IERC20
- [Ext] totalSupply
- [Ext] balanceOf
- [Ext] transfer #
- [Ext] allowance
- [Ext] approve #
- [Ext] transferFrom #
+ [Int] IERC20Metadata (IERC20)
- [Ext] name
- [Ext] symbol
- [Ext] decimals
+ ERC20 (Context, IERC20, IERC20Metadata)
- [Pub] #
- [Pub] name
- [Pub] symbol
- [Pub] decimals
- [Pub] totalSupply
- [Pub] balanceOf
- [Pub] transfer #
- [Pub] allowance
- [Pub] approve #
- [Pub] transferFrom #
- [Pub] increaseAllowance #
- [Pub] decreaseAllowance #
- [Int] _transfer #
- [Int] _mint #
- [Int] _burn #
- [Int] _approve #
- [Int] _beforeTokenTransfer #
+ ERC20Burnable (Context, ERC20)
- [Pub] burn #
- [Pub] burnFrom #
+ [Int] IShield
- [Ext] useNet #
- [Ext] useShield #
- [Ext] startTrade #
- [Ext] isTradeOpen
- [Ext] into
+ [Int] IPlan
- [Ext] addNewPlan #
- [Ext] getSubscription
- [Ext] getOption
- [Ext] getOptionCount
+ PegasusBot (Ownable, ERC20)
- [Pub] #
- modifiers: ERC20
- [Int] _transfer #
- [Prv] subscribe #
- [Ext] setIsTaxActivated #
- modifiers: onlyOwner
- [Ext] setRouter #
- modifiers: onlyOwner
- [Ext] setPlanContract #
- modifiers: onlyOwner
- [Ext] setStorageContract #
- modifiers: onlyOwner
- [Ext] setUniswapPair #
- modifiers: onlyOwner
- [Ext] setTax #
- modifiers: onlyOwner
- [Ext] setDest #
- modifiers: onlyOwner
- [Pub] getTax
- [Prv] isUniswapAddress
Account Contract


($) = payable function
# = non-constant function
Int = Internal
Ext = External
Pub = Public
+ Context
- [Int] _msgSender
- [Int] _msgData
+ Ownable (Context)
- [Pub] #
- [Pub] owner
- [Pub] renounceOwnership #
- modifiers: onlyOwner
- [Pub] transferOwnership #
- modifiers: onlyOwner
+ [Lib] SafeMath
- [Pub] wad
- [Pub] ray
- [Int] add
- [Int] sub
- [Int] sub
- [Int] mul
- [Int] div
- [Int] div
- [Int] mod
- [Int] mod
- [Int] min
- [Int] max
- [Int] sqrt
- [Int] wmul
- [Int] wmulRound
- [Int] rmul
- [Int] rmulRound
- [Int] wdiv
- [Int] wdivRound
- [Int] rdiv
- [Int] rdivRound
- [Int] wpow
- [Int] rpow
+ [Int] IERC20
- [Ext] totalSupply
- [Ext] balanceOf
- [Ext] transfer #
- [Ext] allowance
- [Ext] approve #
- [Ext] transferFrom #
+ [Int] IGMXRouter
- [Ext] approvePlugin #
+ [Int] IGMXReader
- [Ext] getPositions
+ [Int] IGMXPosition
- [Ext] createIncreasePositionETH ($)
- [Ext] createDecreasePosition ($)
+ Enum
+ [Int] IGnosisSafeSetup
- [Ext] setup #
+ [Int] ISafeFactory
- [Ext] createProxyWithNonce #
+ [Int] ISafe
- [Ext] execTransaction ($)
+ Account (Ownable)
- [Pub] #
- [Ext] withdrawETH #
- modifiers: onlyOwner
- [Ext] withdrawToken #
- modifiers: onlyOwner
- [Pub] _exec ($)
- modifiers: onlyOwner,onlyAllowedAddress
- [Prv] _transferGasFees #
- [Ext] ($)
About SourceHat
SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!
Contact us today to get a free quote for a smart contract audit of your project!
What is a SourceHat Audit?
Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.
How Do I Interpret the Findings?
Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:
- High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
- Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
- Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
- Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.