Boosted GMX assets from your favorite liquid token wrapper, Pirex - brought to you by Redacted Cartel.
Platform: Code4rena
Start Date: 21/11/2022
End Date: 28/11/2022
Period: 7 days
Status: Completed
Pot Size: $90,500 USDC
Participants: 101
Reporter: itsmetechjay
Judge: Picodes
Id: 183
League: ETH
xiaoming90 | 1/101 | $18,760.33 | 9 | 5 | 1 | 3 | 0 | Grade B | 0 | 0 |
bin2chen | 2/101 | $6,166.83 | 4 | 2 | 0 | 2 | 1 | 0 | 0 | 0 |
unforgiven | 3/101 | $5,985.19 | 10 | 3 | 0 | 5 | 0 | Grade B | Grade B | 0 |
HE1M | 4/101 | $4,504.86 | 3 | 2 | 0 | 1 | 1 | 0 | 0 | 0 |
__141345__ | 5/101 | $4,323.79 | 4 | 2 | 0 | 1 | 0 | 0 | Grade B | 0 |
0x52 | 6/101 | $4,209.73 | 5 | 2 | 0 | 3 | 0 | 0 | 0 | 0 |
aphak5010 | 7/101 | $3,824.26 | 5 | 0 | 0 | 3 | 1 | Grade B | Grade B | 0 |
ladboy233 | 8/101 | $2,791.95 | 6 | 3 | 0 | 3 | 0 | 0 | 0 | 0 |
rvierdiiev | 9/101 | $2,188.94 | 7 | 3 | 0 | 3 | 0 | Grade B | 0 | 0 |
gzeon | 10/101 | $2,093.64 | 4 | 0 | 0 | 2 | 0 | Grade B | Grade A | 0 |
Auditor per page
The C4audit output for the contest can be found here.
Note for C4 wardens: Anything included in the C4udit output is considered a publicly known issue and is ineligible for awards.
Pirex provides GMX token holders with a streamlined and convenient solution for maximizing the productivity of their GMX and GLP tokens. As a user of Pirex, you can benefit in the following ways:
And more. We're continuously improving our products and adding value to our users, and will make announcements as additional utility is available for our tokens. Please follow us on Twitter (@redactedcartel) to stay in the loop ❤️.
Tokens
pxGMX: The Pirex-wrapped version of staked GMX and *esGMX, handled in a way to maximize yield for the protocol's users (e.g. continuous, automatic, socialized multiplier point compounding). pxGMX token holders will be able to claim rewards and vote in GMX governance proposals (coming soon, after launch), just as they would with staked GMX. pxGMX cannot be redeemed for the underlying assets (those assets are essentially "blackholed" and will never resurface on the market), but can be sold for GMX, via a liquidity pool which we will seed (i.e. add initial pxGMX and GMX liquidity).
*esGMX rewards are distributed as pxGMX, which are minted at the time of an individual user's reward claim. When unclaimed/unminted, the rewards earned by esGMX-backed pxGMX will be distributed amongst existing pxGMX token holders, boosting their rewards even further!
pxGLP: The Pirex-wrapped version of staked GLP, handled in the same way as pxGMX to maximize yield. pxGLP token holders can claim rewards, just as they would with staked GLP, and also redeem them for any GLP constituent asset (check the GMX app for a complete list).
Modes
Easy Mode: Sit back, relax, and we will autocompound the pxGMX and pxGLP rewards into more of those assets for you.
Standard Mode: Manually handle your pxGMX or pxGLP by claiming rewards and other actions (e.g. vote in GMX governance with pxGMX), while still enjoying the benefits of Pirex-GMX's multiplier point auto-compounding.
Hard Mode (Coming Soon): Stake your pxGMX or pxGLP and mint tokens representing their future rewards (e.g. you can stake pxGMX for 1 year and receive the equivalent of 1 year's worth of rewards - after 1 year, you can unstake your pxGMX), and sell it on our decentralized futures marketplace.
PirexGmx.sol
PirexRewards.sol
PirexFees.sol
PxERC20.sol
PxGmx.sol
burn
method of PxERC20 (pxGMX cannot be redeemed for GMX or esGMX)AutoPxGmx.sol
*NOTE: GMX is converted into pxGMX.
AutoPxGlp.sol
Below are visualizations of how Pirex-GMX contracts interact with one another as well as with external contracts (e.g. GMX's contracts) as a result of different user interactions. Please note that the diagrams do not cover every single user action for the purpose of avoiding redundancy (e.g. the diagram for depositing GMX and acquiring pxGMX is more or less the same as depositing GLP or GLP constituent assets and acquiring pxGLP).
Contract | SLOC | Purpose | Libraries used |
---|---|---|---|
src/Common.sol | 11 | Shared struct types | None |
src/PirexFees.sol | 67 | Distributes protocol fees to treasury and contributors | solmate/* |
src/PirexGmx.sol | 645 | Handles and custodies GMX assets on behalf of users | solmate/* , openzeppelin-contracts/* |
src/PirexRewards.sol | 303 | Maintains Pirex-GMX tokens' reward-related state | solmate/* , openzeppelin-contracts-upgradeable/* |
src/PxERC20.sol | 76 | Pirex-GMX token with hooks for reward accounting upon supply and balance changes | solmate/* , openzeppelin-contracts/* |
src/PxGmx.sol | 12 | PxERC20 but with the fixed pxGMX-related values and the burn method overriden | solmate/* , openzeppelin-contracts/* |
src/interfaces/IAutoPxGlp.sol | 18 | AutoPxGlp interface | None |
src/interfaces/IPirexRewards.sol | 11 | PirexRewards interface | None |
src/interfaces/IProducer.sol | 16 | Producer/PirexGmx interface | None |
src/vaults/AutoPxGlp.sol | 302 | pxGLP auto-compounding vault | solmate/* |
src/vaults/AutoPxGmx.sol | 250 | pxGMX auto-compounding vault | solmate/* |
src/vaults/PirexERC4626.sol | 190 | Modified Solmate ERC-4626 contract | solmate/* |
src/vaults/PxGmxReward.sol | 80 | Maintains esGMX-backed pxGMX reward state for AutoPxGlp | solmate/* |
Please note that we will not be acknowledging nor awarding "centralization risk" findings related to the contract owner (a Redacted-Pirex multisig) being able to call certain permissioned methods - some of which may jeopardize user funds safety if called with malicious intent. While we do recognize the risk, we also believe that certain privileges need to be retained by our team in order to safeguard user funds and maintain the protocol's continued operations - for example, should our contracts become incompatible with GMX's at any point (as a result of them updating their contracts), we would need to perform a full account transfer of the GMX assets to an updated version of our contract that is compatible. That said, we are taking steps to mitigate risks to users, the first of which is the utilization of a Gnosis Safe multisig in conjunction with Metropolis (previously, known as Orca), which provides us with more granular control over signature thresholds and signers (this would enable us to carry out precautionary measures such as requiring a greater # of trustworthy signers for executing higher risk, privileged actions).
Thank you for understanding!
N/A
- If you have a public code repo, please share it here: https://github.com/redacted-cartel/pirex-gmx - How many contracts are in scope? 13 - Total SLoC for these contracts? 1981 - How many external imports are there? 17 - How many separate interfaces and struct definitions are there for the contracts within scope? 3 interfaces, 3 structs - Does most of your code generally use composition or inheritance? Inheritance to keep code lean and for security purposes (i.e. use code that has been previously audited and broadly casted) - How many external calls? Strictly only calls to contracts that are *not* ours (e.g. `asset.balanceOf(address)` calls in ERC-4626 vaults are not included, since those are all px assets): 54 - What is the overall line coverage percentage provided by your tests? Using Forge's coverage command (for these contracts only: PirexFees.sol, PirexGmx.sol, PirexRewards.sol, PxERC20.sol, PxGmx.sol, AutoPxGlp.sol, AutoPxGmx.sol, PxGmxReward.sol): 98.26875% - Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol? Yes - Please describe required context: https://gist.github.com/kphed/27920e52ef59ecb88516fefa4bd2337b - Does it use an oracle? No - Does the token conform to the ERC20 standard? Yes - Are there any novel or unique curve logic or mathematical models? No - Does it use a timelock function? No - Is it an NFT? No - Does it have an AMM? No - Is it a fork or alternate implementation of another project? Yes - If yes, please describe your customisations: This protocol is a variant of our Pirex-Convex protocol which can be viewed here: https://pirex.io - Does it use rollups? Yes - Is it multi-chain? Yes - Does it use a side-chain? Yes - If yes, is the sidechain evm-compatible? Yes, Avalanche
IDE: VSCode 1.73.0 (Universal)
Forge: 0.2.0
From inside the project directory:
forge i
forge build
FORK_URL
variable within the scripts/loadEnv.sh file with your Arbitrum RPC endpoint - the other two variables are prepopulated for you with values for tests ran on Arbitrumforge test
arguments, flags, options, etc.)*NOTE: Please use either an Arbitrum or Avalanche RPC endpoint. If using the latter, exclude tests for the AutoPxGmx contract with this appended when running the test helper script: --no-match-contract AutoPxGmx
- the pxGMX vault needs to be updated to support WAVAX => GMX swaps on TraderJoe.
Please use our fork of Slither here: https://github.com/redacted-cartel/slither.
Run the command below from within the project directory to set up the project from a fresh start:
rm -Rf 2022-11-redactedcartel || true && git clone https://github.com/code-423n4/2022-11-redactedcartel.git --recurse-submodules -j8 && cd 2022-11-redactedcartel && foundryup && forge i && scripts/forgeTest.sh --gas-report