B3 Proposal #15
B3 Proposal #15
Conversation
| Called by the owner of the smart wallet. | ||
|
|
||
| * @param planAgent - it is the address of a smart contract (possibly a core account too) | ||
| * @param recurrency - limits the number of times a planAgent can call ‘pull’ in a given period |
There was a problem hiding this comment.
This is somewhat limiting, at least from the user perspective, the provider can pull every 5min if he wants (the due amount for the period).
Given the allowance pattern (user allows up to some amount, but can also spend the allowance) might be beneficial to capture the payment as often as needed.
| * @return asset - address of an ERC token - 0x0 if ether | ||
|
|
||
| ``` | ||
| function authorizePlan( |
There was a problem hiding this comment.
I guess should be getPullRequest
|
|
||
| ### Ether | ||
|
|
||
|  |
There was a problem hiding this comment.
Links don't seem to work. Would be very useful to see them in graphical form.
| This standard defines an interface to pre-authorize payments in order to allow parties to fulfill the payment at a later date via a pull request. The approval/pull request mechanism is purposefully generalized so that it can be used for both recurring pull requests (subscriptions) and one-off pull requests. This standard allows for payment to occur in Ether, ERC20, ERC223 tokens. This should be integrated into future versions of smart wallets, allowing for a more seamless process. | ||
|
|
||
| ### Our Thoughts | ||
| The ability to support all types of pull requests, not only subscriptions, is of utmost importance. Subscription is just one subset of an abundance of use cases for pull requests. Therefore, because we cannot now predict all of the unique uses for pull requests, it is important to create a standard that is general, yet secure enough to allow creative developers to build upon without the need for creating a new standard. |
There was a problem hiding this comment.
This is well thought and described. I think in general most of the proposal are using the same idea (in general subscriptions payment is solving the problem of transition from push to pull) but without explicitly naming that.
No description provided.