On-demand credits #5990
On-demand credits #5990
Conversation
There was a problem hiding this comment.
Looks good on a first pass. I was thinking about whether we need an ED here and I think the answer is no, because the credits are non-refundable, hence you have an implicit ED based on the minimum amount an on-demand core costs. This is less than the current ED on the relay chain, but it is also not a deposit, but actual spending.
| let credits = Credits::<T>::get(&sender); | ||
| ensure!(spot_price <= credits, Error::<T>::InsufficientCredits); | ||
| Credits::<T>::insert(&sender, credits.saturating_sub(spot_price)); | ||
| }, |
There was a problem hiding this comment.
I think we might need adjustments to revenue tracking. Coretime bought with credits don't need a teleport, while coretime bought with balances does. We should also deprecate orders based on balances, to give people a heads up before later removal.
There was a problem hiding this comment.
Ok, so we want to make place_order_allow_death and place_order_keep_alive deprecated so we can remove them later. This makes sense.
Just to confirm that I interpreted the first part of your comment correctly:
When using credits, the DOT used to purchase them is already on the Coretime chain. However, when using rc balance to make an order, the relay chain must transfer this revenue to the Coretime chain. So, if I understand correctly, you are saying that we need to adjust revenue tracking to account for this teleport when using rc balance?
There was a problem hiding this comment.
Given that the RC doesn't pay for notifying revenue, is there anything we should account for? UnpaidExecution
I also thought of it, but I don't think it would be needed. |
Implementation of on-demand credits as described in RFC-1