pushPrice uses the continuing invitation pattern, which involves getting an invitation from the contract and making an offer via Zoe, when there is no exchange of assets.
Description of the Design
Add an invokeOfferResult(offerId, method, ...args) method to the smartWallet that would
look up the offer result corresponding to offerId
call E(offerResult).method(..args)
The smartWallet's method of choosing of which offerResults to retain might also need adjustment.
Security Considerations
when un-marshaling args, be sure not to create promises (cf. #5965)
Scaling Considerations
The offerId -> offerResult mapping grows without bound. Currently, we consider this manageable because it only occurs for continuing offers:
for each vault created - and there's a charge for this
To put it simply: dapps have all of the domain specific knowledge, but none of the authority, and wallets have all of the authority and none of the domain specific knowledge.
What is the Problem Being Solved?
pushPrice
uses the continuing invitation pattern, which involves getting an invitation from the contract and making an offer via Zoe, when there is no exchange of assets.Description of the Design
Add an
invokeOfferResult(offerId, method, ...args)
method to the smartWallet that wouldE(offerResult).method(..args)
The smartWallet's method of choosing of which offerResults to retain might also need adjustment.
Security Considerations
when un-marshaling args, be sure not to create promises (cf. #5965)
Scaling Considerations
The offerId -> offerResult mapping grows without bound. Currently, we consider this manageable because it only occurs for continuing offers:
Test Plan
TBD
Upgrade Considerations
This would be an upgrade to the walletFactory.