Request form
GMX.io
  • Exchange
  • Leverage
  • Perpetual
  • Protocol
  • Audited
Docs
Source
ChefGPT

GMX is a decentralized spot and perpetual exchange that supports low swap fees and zero price impact trades. Trading is supported by a unique multi-asset pool that earns liquidity providers fees from market making, swap fees, leverage trading (spreads, funding fees & liquidations) and asset rebalancing.

Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ERC165 :
Implementation of the {IERC165} interface. Contracts may inherit from this and call {_registerInterface} to declare their support of an interface.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
SafeMath :
Wrappers over Solidity's arithmetic operations with added overflow checks. Arithmetic operations in Solidity wrap on overflow. This can easily result in bugs, because programmers usually assume that an overflow raises an error, which is the standard behavior in high level programming languages. `SafeMath` restores this intuition by reverting the transaction when an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always.
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
ERC721 :
see https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
baseURI() :
Returns the base URI set via {_setBaseURI}. This will be automatically added as a prefix in {tokenURI} to each token's URI, or to the token ID if no specific URI is set for that token ID.
constructor :
Initializes the contract by setting a `name` and a `symbol` to the token collection.
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Enumerable :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721.onERC721Received.selector`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
Address :
Collection of functions related to the address type
EnumerableMap :
Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type. Maps have the following properties: - Entries are added, removed, and checked for existence in constant time (O(1)). - Entries are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap; // Declare a set state variable EnumerableMap.UintToAddressMap private myMap; } ``` As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
Strings :
String operations.
FaucetToken :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
Token :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
WETH :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
Governable.sol
TokenManager.sol
IAdmin.sol
PancakeFactory.sol
PancakePair.sol
PancakeRouter.sol
UniFactory.sol
UniNftManager.sol
UniPool.sol
IPancakeFactory.sol
IPancakePair.sol
IPancakeRouter.sol
BasePositionManager.sol
GlpManager.sol
OrderBook.sol
PositionManager.sol
PositionRouter.sol
PositionUtils.sol
Router.sol
ShortsTracker.sol
Vault.sol
VaultErrorController.sol
VaultPriceFeed.sol
VaultUtils.sol
IBasePositionManager.sol
IGlpManager.sol
IOrderBook.sol
IPositionRouter.sol
IPositionRouterCallbackReceiver.sol
IRouter.sol
IShortsTracker.sol
IVault.sol
IVaultPriceFeed.sol
IVaultUtils.sol
MaliciousTraderTest.sol
PositionRouterCallbackReceiverTest.sol
ShortsTrackerTest.sol
VaultTest.sol
GMT.sol
Treasury.sol
IGMT.sol
EsGMX.sol
GLP.sol
GMX.sol
GmxFloor.sol
GmxIou.sol
GmxMigrator.sol
MigrationHandler.sol
IAmmRouter.sol
IGmxIou.sol
IGmxMigrator.sol
Context.sol
Ownable.sol
ERC165.sol
IERC165.sol
Math.sol
SafeMath.sol
UQ112x112.sol
ERC20.sol
ERC721.sol
IERC721.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721Receiver.sol
IERC20.sol
SafeERC20.sol
Address.sol
EnumerableMap.sol
EnumerableSet.sol
ReentrancyGuard.sol
Strings.sol
FastPriceEvents.sol
FastPriceFeed.sol
PriceFeed.sol
IChainlinkFlags.sol
IFastPriceEvents.sol
IFastPriceFeed.sol
IPriceFeed.sol
ISecondaryPriceFeed.sol
BalanceUpdater.sol
BatchSender.sol
EsGmxBatchSender.sol
GmxTimelock.sol
OrderBookReader.sol
PositionRouterReader.sol
PriceFeedTimelock.sol
Reader.sol
RewardReader.sol
ShortsTrackerTimelock.sol
Timelock.sol
VaultReader.sol
IGmxTimelock.sol
IHandlerTarget.sol
ITimelock.sol
ITimelockTarget.sol
ReferralReader.sol
ReferralStorage.sol
IReferralStorage.sol
BonusDistributor.sol
GlpBalance.sol
RewardDistributor.sol
RewardRouter.sol
RewardRouterV2.sol
RewardTracker.sol
StakeManager.sol
StakedGlp.sol
StakedGlpMigrator.sol
Vester.sol
IRewardDistributor.sol
IRewardRouterV2.sol
IRewardTracker.sol
IVester.sol
BaseToken.sol
Bridge.sol
FaucetToken.sol
MintableBaseToken.sol
SnapshotToken.sol
TimeDistributor.sol
Token.sol
USDG.sol
WETH.sol
YieldFarm.sol
YieldToken.sol
YieldTracker.sol
IBaseToken.sol
IBridge.sol
IDistributor.sol
IGLP.sol
IMintable.sol
IUSDG.sol
IWETH.sol
IYieldToken.sol
IYieldTracker.sol
console.sol

TVL

$541.92M

105 downloads

Chains

Authors

GMX.io
  • Exchange
  • Leverage
  • Perpetual
  • Protocol
  • Audited
Info
Docs
Source
ChefGPT
Expand
Share

Get Cookin'

105 downloads

Chains

Authors

GMX Contracts

Contracts for GMX.

Docs at https://gmxio.gitbook.io/gmx/contracts.

Install Dependencies

If npx is not installed yet: npm install -g npx

Install packages: npm i

Compile Contracts

npx hardhat compile

Run Tests

npx hardhat test

GMX is a decentralized spot and perpetual exchange that supports low swap fees and zero price impact trades. Trading is supported by a unique multi-asset pool that earns liquidity providers fees from market making, swap fees, leverage trading (spreads, funding fees & liquidations) and asset rebalancing.
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ERC165 :
Implementation of the {IERC165} interface. Contracts may inherit from this and call {_registerInterface} to declare their support of an interface.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
SafeMath :
Wrappers over Solidity's arithmetic operations with added overflow checks. Arithmetic operations in Solidity wrap on overflow. This can easily result in bugs, because programmers usually assume that an overflow raises an error, which is the standard behavior in high level programming languages. `SafeMath` restores this intuition by reverting the transaction when an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always.
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
ERC721 :
see https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
baseURI() :
Returns the base URI set via {_setBaseURI}. This will be automatically added as a prefix in {tokenURI} to each token's URI, or to the token ID if no specific URI is set for that token ID.
constructor :
Initializes the contract by setting a `name` and a `symbol` to the token collection.
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Enumerable :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Usage of this method is discouraged, use {safeTransferFrom} whenever possible. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721.onERC721Received.selector`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
Address :
Collection of functions related to the address type
EnumerableMap :
Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type. Maps have the following properties: - Entries are added, removed, and checked for existence in constant time (O(1)). - Entries are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap; // Declare a set state variable EnumerableMap.UintToAddressMap private myMap; } ``` As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
Strings :
String operations.
FaucetToken :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
Token :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
WETH :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5,05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is called. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
Governable.sol
TokenManager.sol
IAdmin.sol
PancakeFactory.sol
PancakePair.sol
PancakeRouter.sol
UniFactory.sol
UniNftManager.sol
UniPool.sol
IPancakeFactory.sol
IPancakePair.sol
IPancakeRouter.sol
BasePositionManager.sol
GlpManager.sol
OrderBook.sol
PositionManager.sol
PositionRouter.sol
PositionUtils.sol
Router.sol
ShortsTracker.sol
Vault.sol
VaultErrorController.sol
VaultPriceFeed.sol
VaultUtils.sol
IBasePositionManager.sol
IGlpManager.sol
IOrderBook.sol
IPositionRouter.sol
IPositionRouterCallbackReceiver.sol
IRouter.sol
IShortsTracker.sol
IVault.sol
IVaultPriceFeed.sol
IVaultUtils.sol
MaliciousTraderTest.sol
PositionRouterCallbackReceiverTest.sol
ShortsTrackerTest.sol
VaultTest.sol
GMT.sol
Treasury.sol
IGMT.sol
EsGMX.sol
GLP.sol
GMX.sol
GmxFloor.sol
GmxIou.sol
GmxMigrator.sol
MigrationHandler.sol
IAmmRouter.sol
IGmxIou.sol
IGmxMigrator.sol
Context.sol
Ownable.sol
ERC165.sol
IERC165.sol
Math.sol
SafeMath.sol
UQ112x112.sol
ERC20.sol
ERC721.sol
IERC721.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721Receiver.sol
IERC20.sol
SafeERC20.sol
Address.sol
EnumerableMap.sol
EnumerableSet.sol
ReentrancyGuard.sol
Strings.sol
FastPriceEvents.sol
FastPriceFeed.sol
PriceFeed.sol
IChainlinkFlags.sol
IFastPriceEvents.sol
IFastPriceFeed.sol
IPriceFeed.sol
ISecondaryPriceFeed.sol
BalanceUpdater.sol
BatchSender.sol
EsGmxBatchSender.sol
GmxTimelock.sol
OrderBookReader.sol
PositionRouterReader.sol
PriceFeedTimelock.sol
Reader.sol
RewardReader.sol
ShortsTrackerTimelock.sol
Timelock.sol
VaultReader.sol
IGmxTimelock.sol
IHandlerTarget.sol
ITimelock.sol
ITimelockTarget.sol
ReferralReader.sol
ReferralStorage.sol
IReferralStorage.sol
BonusDistributor.sol
GlpBalance.sol
RewardDistributor.sol
RewardRouter.sol
RewardRouterV2.sol
RewardTracker.sol
StakeManager.sol
StakedGlp.sol
StakedGlpMigrator.sol
Vester.sol
IRewardDistributor.sol
IRewardRouterV2.sol
IRewardTracker.sol
IVester.sol
BaseToken.sol
Bridge.sol
FaucetToken.sol
MintableBaseToken.sol
SnapshotToken.sol
TimeDistributor.sol
Token.sol
USDG.sol
WETH.sol
YieldFarm.sol
YieldToken.sol
YieldTracker.sol
IBaseToken.sol
IBridge.sol
IDistributor.sol
IGLP.sol
IMintable.sol
IUSDG.sol
IWETH.sol
IYieldToken.sol
IYieldTracker.sol
console.sol