@emo-eth/immutable-splits
v0.1.1
Published
ImmutableSplits are a set of lightweight, immutable, gas-efficient payout split contracts. They are designed to be deployed to a deterministic address by a factory contract, which tracks if a particular payout split has already been deployed.
Downloads
10
Maintainers
Readme
ImmutableSplits
ImmutableSplits are a set of lightweight, immutable, gas-efficient payout split contracts. They are designed to be deployed to a deterministic address by a factory contract, which tracks if a particular payout split has already been deployed.
ImmutableSplits
interface IImmutableSplit {
function getRecipients() external view returns (Recipient[] memory);
function splitErc20(address token) external;
function proxyCall(address target, bytes calldata callData) external returns (bytes memory);
function receiveHook() external payable;
receive() external payable;
}
- Automatically splits Ether/native-token payments to a predetermined set of recipients.
- Recipients and their respective shares are set at deployment time and, for gas-efficiency, cannot be changed
- Disburses ERC20 splits when the
splitErc20
function is called Recipient
addresses included on anImmutableSplit
may call theproxyCall
function to execute a transaction on behalf of theImmutableSplit
. This is useful for allowing withdrawal of non-fungible tokens accidentally sent to a smart contract, or to execute a withdrawal directly to the split contract.
ImmutableSplitFactory
interface IImmutableSplitFactory {
function createImmutableSplit(Recipient[] calldata recipients) external returns (address payable);
function getDeployedImmutableSplitAddress(Recipient[] calldata recipients) external returns (address);
}
- Deploys
ImmutableSplit
s to deterministic addresses - Tracks which
ImmutableSplit
s have already been deployed, and will revert if attempting to re-deploy anImmutableSplit
for a given set of recipients + shares - When creating a new
ImmutableSplit
, an array ofRecipient
s must be passed. The following validation is applied:- A
Recipient
may not have abps
value of0
or10_000
. - The
bps
values of allRecipient
s must sum to10_000
.
- A
- To ensure duplicates are not created, the following rules are enforced:
- The
Recipient
s must be sorted bybps
in ascending order. - If two or more
Recipient
s have the samerecipient
, theRecipient
s with the numerically "lower" addresses must come first.