gmx-io / gmx-contracts Goto Github PK

I'm working on an integration with GMX contracts and I keep getting an error when I try to execute increase position requests.

The transaction either reverts with error PositionRouter: request has expired" or PositionRouter: min delay not yet passed

The error appears be be coming from this block of code in the Position router contract

function _validateExecution(uint256 _positionBlockNumber, uint256 _positionBlockTime, address _account) internal view returns (bool) {
        if (_positionBlockTime.add(maxTimeDelay) <= block.timestamp) {
            revert("PositionRouter: request has expired");
        }

       ..........

        require(_positionBlockTime.add(minTimeDelayPublic) <= block.timestamp, "PositionRouter: min delay not yet passed");

        return true;
    }

I inspected the contract and minTimeDelayPublic is set as 31536000 while maxTimeDelay is 1800

When I evm_increaseTime with >=1800 seconds, the tx reverts with the error request has expired and when I evm_increaseTime with <1800 secs, the txn fails with the error PositionRouter: min delay not yet passed

Is there something wrong with the logic here?

gm,

The fee calc when selling GLP (the vault.sellUSDG() function) may have a bug.

When selling GLP, the fee for the token to sell into is calculated here:
https://github.com/gmx-io/gmx-contracts/blob/master/contracts/core/Vault.sol#L508

This underlying fee calc depends on vault.usdgAmounts(usg) for the initialAmount:
https://github.com/gmx-io/gmx-contracts/blob/master/contracts/core/VaultUtils.sol#L146

However this usdgAmount has already been updated (decreased) prior to this being called
https://github.com/gmx-io/gmx-contracts/blob/master/contracts/core/Vault.sol#L497

So it looks like the initialAmount var isn't the initial amount, it's already had the usdgDelta applied to it.

Also as far as I can tell, the UI quote is inconsistent with this contract calc - since the usdgAmount being used is the amount prior to the transaction.
https://github.com/gmx-io/gmx-interface/blob/master/src/Helpers.js#L655

Apart from potentially taking more fees than necessary, I guess if the UI quote is different from the actual calc, it may have slippage issues for users.

C:\01_web3\gmx-io\gmx-contracts>npx hardhat compile
An unexpected error occurred:

Error: Cannot find module './env.json'
Require stack:

• C:\01_web3\gmx-io\gmx-contracts\hardhat.config.js
• C:\01_web3\gmx-io\gmx-contracts\node_modules\hardhat\internal\core\config\config-loading.js
• C:\01_web3\gmx-io\gmx-contracts\node_modules\hardhat\internal\cli\cli.js
  at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
  at Function.Module._load (node:internal/modules/cjs/loader:778:27)
  at Module.require (node:internal/modules/cjs/loader:1005:19)
  at require (node:internal/modules/cjs/helpers:102:18)
  at Object. (C:\01_web3\gmx-io\gmx-contracts\hardhat.config.js:26:5)
  at Module._compile (node:internal/modules/cjs/loader:1103:14)
  at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
  at Module.load (node:internal/modules/cjs/loader:981:32)
  at Function.Module._load (node:internal/modules/cjs/loader:822:12)
  at Module.require (node:internal/modules/cjs/loader:1005:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
  'C:\01_web3\gmx-io\gmx-contracts\hardhat.config.js',
  'C:\01_web3\gmx-io\gmx-contracts\node_modules\hardhat\internal\core\config\config-loading.js',
  'C:\01_web3\gmx-io\gmx-contracts\node_modules\hardhat\internal\cli\cli.js'
  ]
  }

According to the minimum price change documentation, the 1.5% price difference requirement over the first 12 hours after opening/updating a position is to deter bots from exploiting potential Chainlink price feed delays. This makes sense and I don't disagree of the current implementation in order to protect GLP holders.

What I think should be considered is if the position is in profit at all at the time of closing/decreasing a position within the 12 hour limit and if the mark price is within the 1.5% difference of the opening price, what profit exists should be able to be used to pay for any incurred fees from closing/decreasing the position instead of forfeiting all profit and still needing to pay all fees.

Examples:

Current State

• User opens a $100 ETH long at mark price $4000
• User decides to close the position before 12 hours has passed from opening at mark price of $4040 (i.e. less than 1.5% required price difference)
• If pending profit is $10 and the user closes, user forfeits all profit, and still pays borrow fee and closing fee

Desired State

• User opens a $100 ETH long at mark price $4000
• User decides to close the position before 12 hours has passed from opening at mark price of $4040 (i.e. less than 1.5% required price difference)
• With pending profit of $10, user would use $10 towards borrow and closing fee, and either forfeits any additional pending profit beyond that or pays out of pocket any fees beyond the $10 pending profit

I saw lots of deploy scripts, lost track of all.
Which should I run when trying to deploy?

https://arbiscan.io/tx/0xe3106ea8b12903d535e105839c51b9b85f8e74fe994a3bedf633b2d70929fdee#eventlog
in arb,the marginFeeBasisPoints is 500,but in CollectMarginFees log, feeUsd is 147801980198019801978142963902,
my deltaSize is 147801980198019801978142963901550,the fee need to be
147801980198019801978142963901550 * 5%=7390099009900990098907148195078L,
but anctual the fee is
147801980198019801978142963901550 * 0.1% = 147801980198019801978142963902,
why??

function getPositionFee(uint256 _sizeDelta) public view returns (uint256) {
if (_sizeDelta == 0) { return 0; }
uint256 afterFeeUsd = _sizeDelta.mul(BASIS_POINTS_DIVISOR.sub(marginFeeBasisPoints)).div(BASIS_POINTS_DIVISOR);
return _sizeDelta.sub(afterFeeUsd);
}

i tried to use python web3 to open long position on gmx, but keep getting errors about format:
the gmx.usdc etc are the usdc address on arbitrum and i downloaded the ABIs.
gmx_position_router_contract.functions.createIncreasePosition(
_path = [gmx.usdc, gmx.weth],
_indexToken = gmx.weth,
_amountIn = 910**6,
_minOut = 0,
_sizeDelta = 181030,
_isLong = True,
_acceptablePrice = 1670*1030,
_executionFee = 1*10**14,
_referralCode = bytes(0),
_callbackTarget = '0x0').buildTransaction(....)
web3.exceptions.ValidationError:
Could not identify the intended function with name createIncreasePosition, positional argument(s) of type () and keyword argument(s) of type {'_path': <class 'list'>, '_indexToken': <class 'str'>, '_amountIn': <class 'int'>, '_minOut': <class 'int'>, '_sizeDelta': <class 'int'>, '_isLong': <class 'bool'>, '_acceptablePrice': <class 'int'>, '_executionFee': <class 'int'>, '_referralCode': <class 'bytes'>, '_callbackTarget': <class 'str'>}.
Found 1 function(s) with the name createIncreasePosition: ['createIncreasePosition(address[],address,uint256,uint256,uint256,bool,uint256,uint256,bytes32,address)']
Function invocation failed due to no matching argument types.
is there any python example to do this:
https://gmxio.gitbook.io/gmx/contracts#opening-increasing-a-position

Dear GMX team, I have a design questions. When trading, I noticed that to increase or decrease positions, two transactions are executed: a request and an execution transactions. Why it was done in this way ? other perpetuals platforms have only one transaction to do it. Also, in Avalanche, after requesting my inc/dec, the one that executes the second transaction is the https://snowtrace.io/address/0x864db9152169d68299b599331c6bfc77e3f91070 wallet. Does it mean that you have an operator listening the requests and execute for them ? If yes, may I question how this affects the decentralization level ?

thanks in advance,
hh