You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wallets with a low asset scale (eg: USD - scale 2) cannot process payments with a higher asset scale (eg: we cannot send $0.0001 to a wallet address that has an asset scale of 2). The rate of pay slider supports values between between $0 and $1. The default rate of pay is $0.60/hour, resulting in $0.0000167/second. Therefore, the monetization frequency (how often an outgoing payment is created) needs to be adjusted and only send the smallest possible unit of that scale (2 or 1, depending on @interledger/pay - not one of our dependencies - this is the library that is creating the +-1 issue when creating an outgoing payment, used in Rafiki).
Impact: An use-case example of this impact - To prevent overpaying each time a website gets refreshed, when a refresh happens, the extension must check the timestamp of the most recent payment for each valid wallet address on the page to calculate if, how much, and when next to pay the wallet address.
Todos
Re-calculate the monetization frequency if we cannot send the monetization amount and only send the smallest possible unit of that scale
Add a flag last_payment (saved in extension storage as a timestamp) that will represent when the last payment happened
Before creating the outgoing payment, verify the flag:
make sure that the current timestamp is greater than last_payment;
if the current timestamp is not greater than last_payment do not create the outgoing payment;
The text was updated successfully, but these errors were encountered:
Context
Wallets with a low asset scale (eg: USD - scale 2) cannot process payments with a higher asset scale (eg: we cannot send $0.0001 to a wallet address that has an asset scale of 2). The rate of pay slider supports values between between $0 and $1. The default rate of pay is $0.60/hour, resulting in $0.0000167/second. Therefore, the monetization frequency (how often an outgoing payment is created) needs to be adjusted and only send the smallest possible unit of that scale (2 or 1, depending on
@interledger/pay
- not one of our dependencies - this is the library that is creating the +-1 issue when creating an outgoing payment, used in Rafiki).Impact: An use-case example of this impact - To prevent overpaying each time a website gets refreshed, when a refresh happens, the extension must check the timestamp of the most recent payment for each valid wallet address on the page to calculate if, how much, and when next to pay the wallet address.
Todos
last_payment
(saved in extension storage as a timestamp) that will represent when the last payment happenedlast_payment
;last_payment
do not create the outgoing payment;The text was updated successfully, but these errors were encountered: