Replies: 2 comments
-
Indeed, option 1 seems like the way to go for the time being. It feels easier to start with option 1 because if we ever change our minds and wish to switch, it should be easier to go from 1 to 2 than vice-versa. Technical side comment for @andreivladbrg: after you rename the current repo to |
Beta Was this translation helpful? Give feedback.
0 replies
-
Closing in favor of #11. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
During a recent face-2-face discussion (@PaulRBerg @andreivladbrg) we've touched upon allowances and which contracts the user will direct their transactions to.
Option 1: Direct-to-contract
Users will have to call the
linear
,pro
andperiphery
contracts and grant allowances individually, for each contract. While this may raise the gas cost (at least on mainnet) and friction for Sablier users, it provides more security and a cleaner debugging experience (block explorers can decode data better). Moreover, the app is already engineer with this flow in mind, so there's no refactoring cost involved.Options 2: Through a proxy contract
Users will bundle their transaction calldata and send it to a (PRB)Proxy contract. In turn, this contract will direct each transaction to the correct target contract. Allowance will have to be granted only once, to the proxy, which will become the "msg.sender" for all created streams. A proxy will make sense only in the case when every call to the protocol is done through this proxy, such that allowance and interaction costs are minimal. It does however enforce worse DX/UX as transactions will be harder to decode (both visually and technically).
The soft consensus for this is to keep working with Option 1.
Beta Was this translation helpful? Give feedback.
All reactions