Plasma Debit: Arbitrary-denomination payments in Plasma Cash



Then Alice can’t make a Plasma Debit payment to Bob yet. (She could still make a Plasma Cash payment to him by transferring the entire amount of her channel to him.)

The operator could enable this transaction by depositing some of its own liquidity into Bob’s coin, so that that coin now has some operator-owned balance. (This is different from making a payment to Bob—the operator still owns their ETH, they’re just holding it in that coin, next to Bob’s ETH.) But of course, this does requires the operator to lock up some capital.

The operator is like a Lightning hub. When you open a channel with a Lightning hub, you can’t receive any payments over that channel unless either a) the hub puts some of their own liquidity into that channel, or b) you make some payments through that channel, thus reducing the portion of it that you own and increasing the amount that your counterparty owns, and thus your own receiving capacity.

So enabling Plasma Debit payments requires some liquidity commitment by the operator.

Not by default, just by assumption of the above example. When you initially deposit, you own the entire balance in your coin, until you make a Plasma Debit payment, or the operator commits some of their own capital into the coin. The above example assumed that one of those things had already happened, so Bob already had some receiving capacity.

No, there is no trust requirement.

The reason any malfeasance would hurt the operator is that in the example I was discussing, the malfeasance would basically be “incrementing Bob’s balance without decrementing Alice’s balance,” which is equivalent to “the operator paying Bob, without the operator getting paid by Alice.”

So the repercussions for this misbehavior would be that Bob still gets paid, but the operator is the one bearing the cost of the payment, rather than Alice.


How could the operator deposit liquidity into Bob’s coin if Bob has no receiving capacity and ergo could not receive from Alice?

So if the lightning hub requires liquidity on the part of the operator - the operator will need to have coin(s) as well as receiving capacity. This is fine in the case of plasma cash, because we can reassign owners, but if the operator, bob, and alice have all just started on this plasma chain, how can they free up any space to be able to receive?

Here’s what you stated in the initial post:

In Plasma Debit, each slot would track not only a public key, but a number a between 0 and v , where v is the total amount of ETH that was deposited into that account on the main chain.

Alright, so everyone has deposited and can’t exceed their deposit amount in that slot. So how do they free up any space?

tl;dr - This design starts in a deadlock and I don’t see a way for it to break out of it.


The operator can deposit into any coin from the main chain, which increments v but not a. So if Bob has a 5 ETH coin and a current balance of 5 ETH (i.e. v is 5 and a is 5), then the operator can deposit 1 ETH into the coin, making it a 6 ETH coin where Bob has a balance of 5 ETH (i.e. v is 6 and a is 5), which gives the operator an implied balance of 1 ETH.

(Apologies, I see that this mechanism wasn’t mentioned in the original post. I will edit it to add that.)

I should make clear that the operator does not need any receiving capacity to receive a Plasma Debit payment. Any coinholder can pay the operator any amount simply by signing a transaction that decrements a for their coin. This is an another way that the bootstrap problem can be avoided—when any user makes a Plasma Debit payment to the operator, their coin becomes undercapitalized, allowing them to receive Plasma Debit payments.


So everyone’s collective balance is stored in percentages of coins in slots in the merkle tree - except for the operator.

  1. Where is the operator’s running balance stored?
  2. If I send something to the operator, they can’t withdraw on the main chain?
  3. I assume the operator has to put up some stake or bond as well, no?
  4. What if I send something to the operator - how do I get it back in the case I want to withdraw from the main chain?


Well not percentages, balances. And theirs is too, it’s just inverted.

  1. Where is the operator’s running balance stored?

It’s not stored in any one place. It’s just the sum of v - a across every coin on the Plasma chain.

  1. If I send something to the operator, they can’t withdraw on the main chain?

They can. See the original post: “When a coin is withdrawn, the coinholder receives a , and the operator receives va . (The exit rules need to be altered slightly to allow either the owner or the operator to exit a coin.)”

  1. I assume the operator has to put up some stake or bond as well, no?

No, not necessarily. At least, nothing depends on that.

  1. What if I send something to the operator - how do I get it back in the case I want to withdraw from the main chain?

Could you please clarify? If you make a payment to the operator, you can’t get it back.


To all those following, we’re elected to take this discussion offline to avoid further flooding, here. :slight_smile:


We are more so referring to the cost of closing a channel in the happy case. Assuming that you are checking the signatures of state being passed into close a channel.

Ecrecover is certainly painful in dispute cases but can also be in consensus if your channel is only running very low micropayments. However this is probably why we introduced more complex off-chain systems so that transaction value is worth the eventual close out fee.

There are ways to engineer around this and use the ecrecover from the msg.sender, but this would limit the calling parties to only the participants of the channel and possible expose a griefing issue.


I don’t think you have to check any signatures, or even Merkle proofs, in the happy exit case. See Optimistic cheap multi-exit for Plasma (Cash or MVP)


I’m sorry I may have pulled this thread a bit off topic into state-channels land with the “quick” finality exit where the main-chain can require consensus from N parties in the channel by checking the signatures. So to pull off the “fast” exit in a state-channel we seem to hit this cost requirement.

If you are willing to wait then it is cool how you can aggregate the sigs under one exit and only check them if incorrect (i think that’s correct if i understand the plasma optimistic exit)


Ah, I see, right. In Plasma Debit, there is never an option for immediate exit anyway (since the “channels” are assignable, so until the challenge period is over you don’t know who has authority to sign off on the exit).


How would you check that participants want to close a channel, without using ecrecover (including the implicit ecrecover in msg.sender)?


I don’t know of a good way and see these costs as a potential issue to deal with for all layer2 systems, but using msg.sender instead of raw signatures would be like going back to using the old gnosis msig where each party called the tx independently, where state was “preloaded” and agreed to by the calls made by msig owners. This way you wouldn’t have to check the signatures with ecrecover but it’s slower.

EDIT: STK just released their channel code and use what seems to be a “cheap” channel exit doing the above description here. Again this limits exits to the parties involved in the channel.


Curious how the offline conversation went. Do you mind summarizing for us at some point?

From my point of view, the advantage of this construction being able to (eventually, I suppose after everything is thought through) accept new participants to the plasma debit chain without an on-chain transaction. It otherwise is very similar to multi party state channels.

One question for Dan (OP): how would dispute resolution work for the new parties? Say I join and Alice sent me one coin. What’s my onboarding process like – do I accept some voucher for a reserved coin from Alice, and “redeem” it with the operator by registering my on chain payout address?


I think I convinced him it worked!

Yes, correct. I think assignability is the big win. I should note that for the basic case (where the operator is the sole liquidity provider) this is equivalent to many two-party state channels, rather than one multi-party state channel.

That’s a pretty good question. There are a lot of ways for it to work, but the way I see it, Alice will submit the transaction to the operator, telling the operator your public key. The operator includes it in a block. You’ll go to the operator and prove your identity using your public key. The operator gives you a full history proof for that coin, which you can download and verify. You now know that you’ve received that coin, and you’re free to spend it.


I wonder if transactions that involve multiple coins (i.e. atomic swap {a-b, v+b} {c+b, v-b}) need to only be included in plasma blocks when the receiver is offline. If the receiver is online, they could technically create a consensus {operator, receiver} signed update on their coin slot that reflects the swap. In this case the sender can be sure the funds will be received if they witness the state update {c+b, v-b} signed by the receiver and operator rather than witness {a-b, v+b} {c+b, v-b} committed in a plasma block to the parent chain.

If the receiver is offline then the operator needs to commit the balance update {a-b, v+b},{c+b, v-b} so that the receiver may claim that state transition in a plasma exit. The offline participant may come back online and negotiate a consensus update with the operator for that slot that reflects the update to now allow for a quick exit.

To clarify, a sent TX is only considered valid if after the initiator (sender) signs the update to their slot, and the operator either includes {a-b, v+b} {c+b, v-b} in a plasma block or the set {Sender, Operator, Receiver} can sign updates in consensus that update their slots without a plasma chain checkpoint. The process for doing this would look like following.

  1. Sender initiates state update by sending sender_sig({a-b, v+b, sequence}) and intended receiver to the operator.
  2. Operator calls the receiver to create receiver_sig({c+b, v-b}, sequence}) in an attempt to get a consensus update for the transfer.
    2a. The operator does not hear from the receiver in some time delta, they will then throw away the senders (initiator) message and commit operator_sig({a-b, v+b} {c+b, v-b}) to the parent chain.
    2b. The operator receives response receiver_sig({c+b, v-b}, sequence}) within time delta, signs it with operator_sig({c+b, v-b}, sequence}) and then sends this to the transaction originator as proof that their transaction completed along with the consensus signed update of their slot operator_sig({a-b, v+b} , sequence}).
  3. Transaction considered irreversible.


Not sure if I fully understood your question, could you rephrase?

The main difference here is that each coin can be considered as a payment channel between the operator and the owner of the coin


Hi @danrobinson,
Thanks for the proposal. Just wondering if instead of having the operator provide liquidity, we have an new type of ‘empty’ deposit where a new token is created on root and plasma chain, with a=0 and v=(some defined max value). So, that we allow recipient users to potentially receive transaction in plasma, for a generalized value transfer network?


For each slot, v needs to be the total amount deposited into that slot on-chain (otherwise, if you received that token with some positive a and then tried to withdraw it, what money would you receive? The Plasma chain would be operating at a fractional reserve). So this would require the operator to deposit that amount of liquidity into that token, so it doesn’t get around the requirement that the operator provide liquidity.


This exchange was helpful for me. Another way of framing the conclusion:

The transfer of a Plasma Debit Coin requires the mutual consent of both Alice and the Operator (Alice needs to sign it, Operator needs to include it in the block). Since it requires mutual consent, we can ensure that it settles on its latest state using state channel-style logic in the case that either party withholds consent; i.e., Alice can always exit her coin and then settle with her latest state, or Operator can withdraw v-a onto the chain.


There’s another advantage Plasma Debit has over a single hub payment channel construction — in short, smaller lockup requirement for the operator:

In a payment channel hub, the total value available for all of the users to transact with can never exceed the amount of liquidity the operator has provided; this is a hefty lockup requirement.

In the extreme case for Plasma Debit, the operator can provide this same 1:1 liquidity, but they can also potentially still facilitate fungible payments between users with a smaller capital lockup; this is possible to the extent that can users make payments via full coin transfers as opposed to debit-channel payments.

Some simple optimizations can encourage the likelihood of such payments being possible. For example, we can “encourage” debit coins to be deposited in base-two denominations, i.e., a single 16 ETH coin requires a full 16 ETH of operator collateral for full fungibility, whereas if we instead have coins of values 8, 4, 2, 1, 1, this requires only 1 ETH of operator collateral (against one of the 1 ETH coins) for full fungibility (this assumes we can combine transfers of multiple coins and debit payments atomically).

As coins start moving around, if a user requires fungibility that they don’t have available, the operator, who has a global view of the network, can find opportunities to ask users for parity atomic swaps (trade a 4 ETH coin for 4 1 ETH coins, say) to help out. A more interesting (but trickier) functionality would be “involuntary parity atomic swaps”, i.e., same as above, but without either user’s permission. Not sure if this has been discussed (though involuntary defragmentation is described here: Plasma Cash defragmentation, take 2); but I can’t figure out a simple way of doing this without reintroducing mass exit vulnerabilities (basically, at any point your coin can suddenly be in-flight, so you can’t tell if some arbitrary is actually rightfully yours).