User Deposit Contract #447
Comments
|
Nice overview, no requirements I'd add. Some comments below.
The token will always be the RDN token, right?
What do you mean by that? I'd also add that the service contracts are trusted and can claim tokens for the providers.
The MS might also want to check the deposit before sending the update transaction. |
We will use it that way. From a purely technical point, another token address could be passed to the constructor.
In this ticket I meant both end users and services when I said "users". So this point really intended to say what you want to add. I worded it less specific because from a UDC point of view, we probably won't distinguish between end users and providers and just have users/addresses/balances. I'll switch to your wording, which makes the intention more clear.
Good point, added to https://github.com/raiden-network/raiden-monitoring-service/issues/68 |
No handling of trusted contracts, no testing of error cases. Should be enough to see if this is a workable approach. Implements raiden-network#447
|
Initial specs on this are here: raiden-network/spec#120. Please check if they still stand and keep the |
No handling of trusted contracts, no testing of error cases. Should be enough to see if this is a workable approach. Implements raiden-network#447
Goals of this commit: * Provide basis for more detailed service contract docs * Incorporate raiden-network#120 * Incorporate raiden-network/raiden-contracts#447 * Allow automatic generation of docs from solidity docstrings
No handling of trusted contracts, no testing of error cases. Should be enough to see if this is a workable approach. Implements #447
|
Specification from this ticket is added to the spec repo in raiden-network/spec#202. |
Goals of this commit: * Provide basis for more detailed service contract docs * Incorporate #120 * Incorporate raiden-network/raiden-contracts#447 * Allow automatic generation of docs from solidity docstrings
The Raiden services will ask for payment in RDN. The Monitoring Service and potentially the Pathfinding Service require deposits to be made in advance of service usage. These deposits will be handled by the User Deposit Contract.
Usage of the deposit for payments is not safe from double spending, but measures can be taken to reduce the likelihood to acceptable levels. This is a good trade off as long as the money lost on double spending is less than the savings in gas cost.
Requirements
Use cases
Monitoring Service rewards
The MS is promised a reward for each settlement in which it took part on behalf of the non-closing participant. Before accepting a monitor request, the MS checks if enough tokens are deposited in the UDC. The MS that has submit the latest BP upon settlement will receive the promised tokens on it's UDC balance.
1-n payments
[This is just a suggestions so far. No decision made.]
The PFS will be paid with signed IOUs, roughly a simplified uRaiden adapted to 1-n payments. The IOU contains the amount of tokens that can be claimed from the signer's UDC balance. See raiden-network/raiden-services#38 for details.
The text was updated successfully, but these errors were encountered: