Request form
Contracts
Protocols
Discord
Uniswap V4
Uniswap
DEX
Exchange
Token
Protocol
Info
Docs
Source
ChefGPT

Uniswap v4 Core

Lint Tests

Uniswap v4 is a new automated market maker protocol that provides extensible and customizable pools. v4-core hosts the core pool logic for creating pools and executing pool actions like swapping and providing liquidity.

The contracts in this repo are in early stages - we are releasing the draft code now so that v4 can be built in public, with open feedback and meaningful community contribution. We expect this will be a months-long process, and we appreciate any kind of contribution, no matter how small.

Contributing

If you’re interested in contributing please see our contribution guidelines!

Whitepaper

A more detailed description of Uniswap v4 Core can be found in the draft of the Uniswap v4 Core Whitepaper.

Architecture

v4-core uses a singleton-style architecture, where all pool state is managed in the PoolManager.sol contract. Pool actions can be taken by acquiring a lock on the contract and implementing the lockAcquired callback to then proceed with any of the following actions on the pools:

  • swap
  • modifyPosition
  • donate
  • take
  • settle
  • mint

Only the net balances owed to the pool (negative) or to the user (positive) are tracked throughout the duration of a lock. This is the delta field held in the lock state. Any number of actions can be run on the pools, as long as the deltas accumulated during the lock reach 0 by the lock’s release. This lock and call style architecture gives callers maximum flexibility in integrating with the core code.

Additionally, a pool may be initialized with a hook contract, that can implement any of the following callbacks in the lifecycle of pool actions:

  • {before,after}Initialize
  • {before,after}ModifyPosition
  • {before,after}Swap
  • {before,after}Donate

Hooks may also elect to specify fees on swaps, or liquidity withdrawal. Much like the actions above, fees are implemented using callback functions.

The fee values, or callback logic, may be updated by the hooks dependent on their implementation. However which callbacks are executed on a pool, including the type of fee or lack of fee, cannot change after pool initialization.

Repository Structure

All contracts are held within the v4-core/contracts folder.

Note that helper contracts used by tests are held in the v4-core/contracts/test subfolder within the contracts folder. Any new test helper contracts should be added here, but all foundry tests are in the v4-core/test/foundry-tests folder.

contracts/
----interfaces/
    | IPoolManager.sol
    | ...
----libraries/
    | Position.sol
    | Pool.sol
    | ...
----test
...
PoolManager.sol
test/
----foundry-tests/

Local deployment and Usage

To utilize the contracts and deploy to a local testnet, you can install the code in your repo with forge:

forge install https://github.com/Uniswap/v4-core

To integrate with the contracts, the interfaces are available to use:


import {IPoolManager} from 'v4-core/contracts/interfaces/IPoolManager.sol';
import {ILockCallback} from 'v4-core/contracts/interfaces/callback/ILockCallback.sol';

contract MyContract is ILockCallback {
    IPoolManager poolManager;

    function doSomethingWithPools() {
        // this function will call `lockAcquired` below
        poolManager.lock(...);
    }

    function lockAcquired(bytes calldata data) external returns (bytes memory) {
        // perform pool actions
        poolManager.swap(...)
    }
}

License

The primary license for Uniswap V4 Core is the Business Source License 1.1 (BUSL-1.1), see LICENSE. Minus the following exceptions:

Each of these files states their license type.

A fully decentralized protocol for automated liquidity provision on Ethereum. V4 -Actively under development.

IDynamicFeeManager :
note that this pool is only called if the PoolKey fee value is equal to the DYNAMIC_FEE magic value
IHookFeeManager :
This callback is only made if the Fee.HOOK_SWAP_FEE_FLAG or Fee.HOOK_WITHDRAW_FEE_FLAG in set in the pool's key.fee.
getHookSwapFee((address,address,uint24,int24,address)) :
getHookWithdrawFee((address,address,uint24,int24,address)) :
IHooks :
Should only be callable by the v4 PoolManager.
afterDonate(address,(address,address,uint24,int24,address),uint256,uint256) :
afterInitialize(address,(address,address,uint24,int24,address),uint160,int24) :
afterModifyPosition(address,(address,address,uint24,int24,address),(int24,int24,int256),int256) :
afterSwap(address,(address,address,uint24,int24,address),(bool,int256,uint160),int256) :
beforeDonate(address,(address,address,uint24,int24,address),uint256,uint256) :
beforeInitialize(address,(address,address,uint24,int24,address),uint160) :
beforeModifyPosition(address,(address,address,uint24,int24,address),(int24,int24,int256)) :
beforeSwap(address,(address,address,uint24,int24,address),(bool,int256,uint160)) :
BitMath :
This library provides functionality for computing bit properties of an unsigned integer
FixedPoint96 :
Used in SqrtPriceMath.sol
FullMath :
Handles "phantom overflow" i.e., allows multiplication and division where an intermediate value overflows 256 bits
LockDataLibrary :
This library manages a custom storage implementation for a queue that tracks current lockers. The "sentinel" storage slot for this data structure, always passed in as IPoolManager.LockData storage self, stores not just the current length of the queue but also the global count of non-zero deltas across all lockers. The values of the data structure start at OFFSET, and each value is a locker address.
Position :
Positions store additional state for tracking fees owed to the position
TickBitmap :
The mapping uses int16 for keys since ticks are represented as int24 and there are 256 (2^8) values per word.
MockContract :
allows for proxying to an implementation contract if real logic or return values are needed
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
ERC1155 :
Implementation of the basic standard multi-token. See https://eips.ethereum.org/EIPS/eip-1155 Originally based on code by Enjin: https://github.com/enjin/erc-1155 _Available since v3.1._
balanceOf(address,uint256) :
See {IERC1155-balanceOf}. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
See {IERC1155-balanceOfBatch}. Requirements: - `accounts` and `ids` must have the same length.
constructor :
See {_setURI}.
isApprovedForAll(address,address) :
See {IERC1155-isApprovedForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
See {IERC1155-safeBatchTransferFrom}.
safeTransferFrom(address,address,uint256,uint256,bytes) :
See {IERC1155-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC1155-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
uri(uint256) :
See {IERC1155MetadataURI-uri}. This implementation returns the same URI for *all* token types. It relies on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP]. Clients calling this function must replace the `\{id\}` substring with the actual token type ID.
IERC1155 :
Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
safeTransferFrom(address,address,uint256,uint256,bytes) :
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
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.
IERC1155Receiver :
_Available since v3.1._
onERC1155BatchReceived(address,address,uint256[],uint256[],bytes) :
Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. NOTE: To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector).
onERC1155Received(address,address,uint256,uint256,bytes) :
Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. NOTE: To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector).
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.
IERC1155MetadataURI :
Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
safeTransferFrom(address,address,uint256,uint256,bytes) :
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
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.
uri(uint256) :
Returns the URI for token type `id`. If the `\{id\}` substring is present in the URI, it must be replaced by clients with the actual token type ID.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
ERC165 :
Implementation of the {IERC165} interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: ```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ``` Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
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.
Fees.sol
NoDelegateCall.sol
Owned.sol
PoolManager.sol
IDynamicFeeManager.sol
IFees.sol
IHookFeeManager.sol
IHooks.sol
IPoolManager.sol
IProtocolFeeController.sol
ILockCallback.sol
IERC20Minimal.sol
BitMath.sol
FeeLibrary.sol
FixedPoint128.sol
FixedPoint96.sol
FullMath.sol
Hooks.sol
LockDataLibrary.sol
Pool.sol
Position.sol
SafeCast.sol
SqrtPriceMath.sol
SwapMath.sol
TickBitmap.sol
TickMath.sol
UnsafeMath.sol
BitMathEchidnaTest.sol
EmptyTestHooks.sol
FullMathEchidnaTest.sol
FullMathTest.sol
HooksTest.sol
MockContract.sol
MockHooks.sol
NoDelegateCallTest.sol
PoolDonateTest.sol
PoolLockTest.sol
PoolModifyPositionTest.sol
PoolSwapTest.sol
PoolTakeTest.sol
ProtocolFeeControllerTest.sol
SqrtPriceMathEchidnaTest.sol
SqrtPriceMathTest.sol
SwapMathEchidnaTest.sol
SwapMathTest.sol
TestERC20.sol
TestInvalidERC20.sol
TickBitmapEchidnaTest.sol
TickBitmapTest.sol
TickEchidnaTest.sol
TickMathEchidnaTest.sol
TickMathTest.sol
TickOverflowSafetyEchidnaTest.sol
TickTest.sol
UnsafeMathEchidnaTest.sol
BalanceDelta.sol
Currency.sol
PoolId.sol
Proxy.sol
ERC1155.sol
IERC1155.sol
IERC1155Receiver.sol
IERC1155MetadataURI.sol
Address.sol
Context.sol
ERC165.sol
IERC165.sol
New Discussion

86 downloads

Chains

Authors

Uniswap V4
Uniswap
DEX
Exchange
Token
Protocol
Info
Source
ChefGPT
Expand
Share

Uniswap v4 Core

Lint Tests

Uniswap v4 is a new automated market maker protocol that provides extensible and customizable pools. v4-core hosts the core pool logic for creating pools and executing pool actions like swapping and providing liquidity.

The contracts in this repo are in early stages - we are releasing the draft code now so that v4 can be built in public, with open feedback and meaningful community contribution. We expect this will be a months-long process, and we appreciate any kind of contribution, no matter how small.

Contributing

If you’re interested in contributing please see our contribution guidelines!

Whitepaper

A more detailed description of Uniswap v4 Core can be found in the draft of the Uniswap v4 Core Whitepaper.

Architecture

v4-core uses a singleton-style architecture, where all pool state is managed in the PoolManager.sol contract. Pool actions can be taken by acquiring a lock on the contract and implementing the lockAcquired callback to then proceed with any of the following actions on the pools:

  • swap
  • modifyPosition
  • donate
  • take
  • settle
  • mint

Only the net balances owed to the pool (negative) or to the user (positive) are tracked throughout the duration of a lock. This is the delta field held in the lock state. Any number of actions can be run on the pools, as long as the deltas accumulated during the lock reach 0 by the lock’s release. This lock and call style architecture gives callers maximum flexibility in integrating with the core code.

Additionally, a pool may be initialized with a hook contract, that can implement any of the following callbacks in the lifecycle of pool actions:

  • {before,after}Initialize
  • {before,after}ModifyPosition
  • {before,after}Swap
  • {before,after}Donate

Hooks may also elect to specify fees on swaps, or liquidity withdrawal. Much like the actions above, fees are implemented using callback functions.

The fee values, or callback logic, may be updated by the hooks dependent on their implementation. However which callbacks are executed on a pool, including the type of fee or lack of fee, cannot change after pool initialization.

Repository Structure

All contracts are held within the v4-core/contracts folder.

Note that helper contracts used by tests are held in the v4-core/contracts/test subfolder within the contracts folder. Any new test helper contracts should be added here, but all foundry tests are in the v4-core/test/foundry-tests folder.

contracts/
----interfaces/
    | IPoolManager.sol
    | ...
----libraries/
    | Position.sol
    | Pool.sol
    | ...
----test
...
PoolManager.sol
test/
----foundry-tests/

Local deployment and Usage

To utilize the contracts and deploy to a local testnet, you can install the code in your repo with forge:

forge install https://github.com/Uniswap/v4-core

To integrate with the contracts, the interfaces are available to use:


import {IPoolManager} from 'v4-core/contracts/interfaces/IPoolManager.sol';
import {ILockCallback} from 'v4-core/contracts/interfaces/callback/ILockCallback.sol';

contract MyContract is ILockCallback {
    IPoolManager poolManager;

    function doSomethingWithPools() {
        // this function will call `lockAcquired` below
        poolManager.lock(...);
    }

    function lockAcquired(bytes calldata data) external returns (bytes memory) {
        // perform pool actions
        poolManager.swap(...)
    }
}

License

The primary license for Uniswap V4 Core is the Business Source License 1.1 (BUSL-1.1), see LICENSE. Minus the following exceptions:

Each of these files states their license type.

A fully decentralized protocol for automated liquidity provision on Ethereum. V4 -Actively under development.
IDynamicFeeManager :
note that this pool is only called if the PoolKey fee value is equal to the DYNAMIC_FEE magic value
IHookFeeManager :
This callback is only made if the Fee.HOOK_SWAP_FEE_FLAG or Fee.HOOK_WITHDRAW_FEE_FLAG in set in the pool's key.fee.
getHookSwapFee((address,address,uint24,int24,address)) :
getHookWithdrawFee((address,address,uint24,int24,address)) :
IHooks :
Should only be callable by the v4 PoolManager.
afterDonate(address,(address,address,uint24,int24,address),uint256,uint256) :
afterInitialize(address,(address,address,uint24,int24,address),uint160,int24) :
afterModifyPosition(address,(address,address,uint24,int24,address),(int24,int24,int256),int256) :
afterSwap(address,(address,address,uint24,int24,address),(bool,int256,uint160),int256) :
beforeDonate(address,(address,address,uint24,int24,address),uint256,uint256) :
beforeInitialize(address,(address,address,uint24,int24,address),uint160) :
beforeModifyPosition(address,(address,address,uint24,int24,address),(int24,int24,int256)) :
beforeSwap(address,(address,address,uint24,int24,address),(bool,int256,uint160)) :
BitMath :
This library provides functionality for computing bit properties of an unsigned integer
FixedPoint96 :
Used in SqrtPriceMath.sol
FullMath :
Handles "phantom overflow" i.e., allows multiplication and division where an intermediate value overflows 256 bits
LockDataLibrary :
This library manages a custom storage implementation for a queue that tracks current lockers. The "sentinel" storage slot for this data structure, always passed in as IPoolManager.LockData storage self, stores not just the current length of the queue but also the global count of non-zero deltas across all lockers. The values of the data structure start at OFFSET, and each value is a locker address.
Position :
Positions store additional state for tracking fees owed to the position
TickBitmap :
The mapping uses int16 for keys since ticks are represented as int24 and there are 256 (2^8) values per word.
MockContract :
allows for proxying to an implementation contract if real logic or return values are needed
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
ERC1155 :
Implementation of the basic standard multi-token. See https://eips.ethereum.org/EIPS/eip-1155 Originally based on code by Enjin: https://github.com/enjin/erc-1155 _Available since v3.1._
balanceOf(address,uint256) :
See {IERC1155-balanceOf}. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
See {IERC1155-balanceOfBatch}. Requirements: - `accounts` and `ids` must have the same length.
constructor :
See {_setURI}.
isApprovedForAll(address,address) :
See {IERC1155-isApprovedForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
See {IERC1155-safeBatchTransferFrom}.
safeTransferFrom(address,address,uint256,uint256,bytes) :
See {IERC1155-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC1155-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
uri(uint256) :
See {IERC1155MetadataURI-uri}. This implementation returns the same URI for *all* token types. It relies on the token type ID substitution mechanism https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP]. Clients calling this function must replace the `\{id\}` substring with the actual token type ID.
IERC1155 :
Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
safeTransferFrom(address,address,uint256,uint256,bytes) :
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
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.
IERC1155Receiver :
_Available since v3.1._
onERC1155BatchReceived(address,address,uint256[],uint256[],bytes) :
Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. NOTE: To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector).
onERC1155Received(address,address,uint256,uint256,bytes) :
Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. NOTE: To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector).
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.
IERC1155MetadataURI :
Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
safeBatchTransferFrom(address,address,uint256[],uint256[],bytes) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
safeTransferFrom(address,address,uint256,uint256,bytes) :
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
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.
uri(uint256) :
Returns the URI for token type `id`. If the `\{id\}` substring is present in the URI, it must be replaced by clients with the actual token type ID.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
ERC165 :
Implementation of the {IERC165} interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: ```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ``` Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
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.
Fees.sol
NoDelegateCall.sol
Owned.sol
PoolManager.sol
IDynamicFeeManager.sol
IFees.sol
IHookFeeManager.sol
IHooks.sol
IPoolManager.sol
IProtocolFeeController.sol
ILockCallback.sol
IERC20Minimal.sol
BitMath.sol
FeeLibrary.sol
FixedPoint128.sol
FixedPoint96.sol
FullMath.sol
Hooks.sol
LockDataLibrary.sol
Pool.sol
Position.sol
SafeCast.sol
SqrtPriceMath.sol
SwapMath.sol
TickBitmap.sol
TickMath.sol
UnsafeMath.sol
BitMathEchidnaTest.sol
EmptyTestHooks.sol
FullMathEchidnaTest.sol
FullMathTest.sol
HooksTest.sol
MockContract.sol
MockHooks.sol
NoDelegateCallTest.sol
PoolDonateTest.sol
PoolLockTest.sol
PoolModifyPositionTest.sol
PoolSwapTest.sol
PoolTakeTest.sol
ProtocolFeeControllerTest.sol
SqrtPriceMathEchidnaTest.sol
SqrtPriceMathTest.sol
SwapMathEchidnaTest.sol
SwapMathTest.sol
TestERC20.sol
TestInvalidERC20.sol
TickBitmapEchidnaTest.sol
TickBitmapTest.sol
TickEchidnaTest.sol
TickMathEchidnaTest.sol
TickMathTest.sol
TickOverflowSafetyEchidnaTest.sol
TickTest.sol
UnsafeMathEchidnaTest.sol
BalanceDelta.sol
Currency.sol
PoolId.sol
Proxy.sol
ERC1155.sol
IERC1155.sol
IERC1155Receiver.sol
IERC1155MetadataURI.sol
Address.sol
Context.sol
ERC165.sol
IERC165.sol

Get Cookin'

copy iconOpen in VSCode
copy iconDownload Source

86 downloads

Chains

Authors