Introdution

Payment Splitter Contract allows for the fair and automated splitting of payments among multiple beneficiaries on the blockchain. It provides a transparent and efficient solution for distributing funds according to pre-defined shares.

Architecture Overview

Components

• Deployer: The entity responsible for deploying the Payment Splitter contract to the blockchain network.
• Depositor: The entity making the payment to be split among the beneficiaries.
• Payee: The individuals or entities receiving a portion of the payment.
• Admin: An authorized entity with the ability to release all shares.

Payment Splitter Process

• Deployer:
  • Deploys the Payment Splitter contract to the blockchain network.
  • Sets up the contract, including specifying the beneficiaries and their respective shares.
• Depositor:
  • Initiates a payment to the Payment Splitter contract.
  • Sends the payment amount to the contract for distribution.
• Payment Splitter Contract:
  • Receives the payment from the Depositor.
  • Stores the payment details and the list of beneficiaries along with their respective shares.
  • Splits the payment among the beneficiaries based on the specified shares.
  • Tracks the payment distribution and updates the balances of each beneficiary.
  • Provides functions to withdraw the respective shares to each beneficiary's designated addresses.
  • Includes an Admin function to release all shares at once.
• Payee:
  • Each payee is a beneficiary designated in the Payment Splitter contract.
  • Has a designated address linked to their share in the contract.
  • Can withdraw their respective share of the payment by interacting with the Payment Splitter contract.
• Admin:
  • An authorized entity with the ability to release all shares.
  • Can call the Admin function in the Payment Splitter contract to release all the shares to the respective beneficiaries.
  • This function allows for the simultaneous release of all shares without individual withdrawals by the payees.

SmartContract Interaction

Splitter follows a pull payment model. This means that payments are not automatically forwarded to the accounts, but are kept in this contract. The actual transfer is triggered as a separate step by calling the release function or releaseAll for transferring to all eligible users.

Admin Related Methods

function releaseAll(address token) external adminRequired

To release the assets to all shareholders, the releaseAll function with the token address must be called. This function can only be called by the admin.

User Related Methods

function release(address payable account) public virtual

function release(IERC20 token, address account) public virtual

Triggers a transfer to account of the amount of Ether or ERC20 they are owed, according to their percentage of the total shares and their previous withdrawals.

Getter Methods

function totalShares() public view returns (uint256)

Getter for the total shares held by payees.

function totalReleased() public view returns (uint256)

Getter for the total amount of Ether already released.

function totalReleased(IERC20 token) public view returns (uint256)

Getter for the total amount of ERC20 already released.

function shares(address account) public view returns (uint256)

Getter for the amount of shares held by an account.

function payee(uint256 index) public view returns (address)

Getter for the address of the payee number index.

function released(address account) public view returns (uint256)

Getter for the amount of Ether already released to a payee.

function released(IERC20 token, address account) public view returns (uint256)

Getter for the amount of ERC20 already released to a payee.

function releasable(address account) public view returns (uint256)

Getter for the amount of payee's releasable Ether

function releasable(IERC20 token, address account) public view returns (uint256)

Getter for the amount of payee's releasable ERC20