Ensuring the security of the Sablier Protocol is our utmost priority. We have dedicated significant efforts towards the design and testing of the protocol to guarantee its safety and reliability. However, we are aware that security is a continuous process. If you believe you have found a security vulnerability, please read the Bug Bounty Program, and share a report privately with us.

Sablier Lockup has been developed with a number of technical assumptions in mind. For a disclosure to qualify as a vulnerability, it must adhere to these assumptions as well:

• The number of segments/tranches should be such that creating a stream should not lead to an overflow of the block gas limit.
• The total supply of any ERC-20 token remains below 2¹²⁸ - 1, i.e., type(uint128).max.
• The transfer and transferFrom methods of any ERC-20 token strictly reduce the sender's balance by the transfer amount and increase the recipient's balance by the same amount. In other words, tokens that charge fees on transfers are not supported.
• An address' ERC-20 balance can only change as a result of a transfer call by the sender or a transferFrom call by an approved address. This excludes rebase tokens, interest-bearing tokens, and permissioned tokens where the admin can arbitrarily change balances.
• The token contract is not an ERC-20 representation of the native token of the chain. For example, the $POL token on Polygon is not supported.
• The token contract has only one entry point.
• The token contract does not allow callbacks (e.g. ERC-777 is not supported).
• There is no need for exponents greater than ~18.44 in LockupDynamic segments.
• Recipient contracts on the hook allowlist have gone through due diligence and are assumed to expose no risk to the Sablier protocol.
• When withdrawing from multiple streams either using batch or withdrawMultiple function, the minimum fee required to execute the transaction is equal to the minimum fee required to withdraw from a single stream. This is intentional and expected behavior.