Request form
Royalty Splitter
  • Utility
  • Finance
  • Audited
  • No-Code Deploy
Docs
Source
ChefGPT

Royalty Splitter

This contract allows payments to be split among a group of accounts. The split can be in equal parts or set in percentages. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned. The distribution of shares is set when you deploy the contract and can't be updated afterwards. Payments must be claimed from the contract by each user. NOTE: This contract assumes that ERC20 tokens will behave similarly to native tokens (Ether). Rebasing tokens, and tokens that apply fees during transfers, are likely to not be supported as expected. If in doubt, we encourage you to run tests before sending real value to this contract.

PaymentSplitter :
This contract allows payments to be split among a group of accounts. The split can be in equal parts or set in percentages. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned. The distribution of shares is set when you deploy the contract and can't be updated afterwards. Payments must be claimed from the contract by each user. NOTE: This contract assumes that ERC20 tokens will behave similarly to native tokens (Ether). Rebasing tokens, and tokens that apply fees during transfers, are likely to not be supported as expected. If in doubt, we encourage you to run tests before sending real value to this contract.
constructor :
Creates an instance of `PaymentSplitter` where each account in `payees` is assigned the number of shares at the matching position in the `shares` array. All addresses in `payees` must be non-zero. Both arrays must have the same non-zero length, and there must be no duplicates in `payees`.
payee(uint256) :
Getter for the address of the payee number `index`.
releasable(address) :
Getter for the amount of payee's releasable Ether.
releasable(address,address) :
Getter for the amount of payee's releasable `token` tokens. `token` should be the address of an IERC20 contract.
release(address) :
Triggers a transfer to `account` of the amount of Ether they are owed, according to their percentage of the total shares and their previous withdrawals.
release(address,address) :
Triggers a transfer to `account` of the amount of `token` tokens they are owed, according to their percentage of the total shares and their previous withdrawals. `token` must be the address of an IERC20 contract.
released(address) :
Getter for the amount of Ether already released to a payee.
released(address,address) :
Getter for the amount of `token` tokens already released to a payee. `token` should be the address of an IERC20 contract.
shares(address) :
Getter for the amount of shares held by an account.
totalReleased() :
Getter for the total amount of Ether already released.
totalReleased(address) :
Getter for the total amount of `token` already released. `token` should be the address of an IERC20 contract.
totalShares() :
Getter for the total shares held by payees.
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
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.
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 `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
royalty-splitter.sol
SafeERC20.sol
Address.sol
Context.sol
IERC20.sol
draft-IERC20Permit.sol

272 downloads

Solidity Version

0.8.12
OpenZeppelin / Royalty Splitter
  • Utility
  • Finance
  • Audited
  • No-Code Deploy
Docs
Source
ChefGPT
Expand
Share

Get Cookin'
star icon272

272 downloads

Solidity Version

0.8.12

Royalty Splitter

This contract allows payments to be split among a group of accounts. The split can be in equal parts or set in percentages. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned. The distribution of shares is set when you deploy the contract and can't be updated afterwards. Payments must be claimed from the contract by each user. NOTE: This contract assumes that ERC20 tokens will behave similarly to native tokens (Ether). Rebasing tokens, and tokens that apply fees during transfers, are likely to not be supported as expected. If in doubt, we encourage you to run tests before sending real value to this contract.

PaymentSplitter :
This contract allows payments to be split among a group of accounts. The split can be in equal parts or set in percentages. The way this is specified is by assigning each account to a number of shares. Of all the Ether that this contract receives, each account will then be able to claim an amount proportional to the percentage of total shares they were assigned. The distribution of shares is set when you deploy the contract and can't be updated afterwards. Payments must be claimed from the contract by each user. NOTE: This contract assumes that ERC20 tokens will behave similarly to native tokens (Ether). Rebasing tokens, and tokens that apply fees during transfers, are likely to not be supported as expected. If in doubt, we encourage you to run tests before sending real value to this contract.
constructor :
Creates an instance of `PaymentSplitter` where each account in `payees` is assigned the number of shares at the matching position in the `shares` array. All addresses in `payees` must be non-zero. Both arrays must have the same non-zero length, and there must be no duplicates in `payees`.
payee(uint256) :
Getter for the address of the payee number `index`.
releasable(address) :
Getter for the amount of payee's releasable Ether.
releasable(address,address) :
Getter for the amount of payee's releasable `token` tokens. `token` should be the address of an IERC20 contract.
release(address) :
Triggers a transfer to `account` of the amount of Ether they are owed, according to their percentage of the total shares and their previous withdrawals.
release(address,address) :
Triggers a transfer to `account` of the amount of `token` tokens they are owed, according to their percentage of the total shares and their previous withdrawals. `token` must be the address of an IERC20 contract.
released(address) :
Getter for the amount of Ether already released to a payee.
released(address,address) :
Getter for the amount of `token` tokens already released to a payee. `token` should be the address of an IERC20 contract.
shares(address) :
Getter for the amount of shares held by an account.
totalReleased() :
Getter for the total amount of Ether already released.
totalReleased(address) :
Getter for the total amount of `token` already released. `token` should be the address of an IERC20 contract.
totalShares() :
Getter for the total shares held by payees.
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
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.
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 `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` 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.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
royalty-splitter.sol
SafeERC20.sol
Address.sol
Context.sol
IERC20.sol
draft-IERC20Permit.sol