P L A S M A   C O N T R A C T S

August 8, 2019

This technical design and architecture for contracts on Plasma is the product of the Plasma community conducting research on enforcement of contracts between ledgers, with the technical goal being inter-chain trust minimization (with speed/data/fullnode-validation trade-offs). This document does not assert any endorsement of any particular project or effort. However, implementation efforts in Plasma Cash have been helpful in creating sufficient understanding in producing this (with sufficient peer-review, conceptually complete, but further optimizable) design and architecture for Plasma.


Let's presume thousands of participants want to participate in a contract. The contract takes in input from thousands of participants spread over an hour, with external value bonded (e.g. the Plasma chain interacting with ETH). The bonded value has conditional payments set contingent upon the output state. All inputs and bonds are fed into the contract and compact settlement data is published. The participant then take that settlement data, apply it to their bonded outputs, then funds flow between the participants.

While Plasma currently allows for synchronization and net-settlement of inter-chain payments with many participants, there are currently two issues to be resolved to make inter-chainstate contracts useful with minimized trust in the Plasma chain:

  1. Data Availability. If each step in a smart contract is viewed as a single atomic round spread over many blocks, transactions get pushed into the contract state similar to a linked list or array of transactions. A problem arises as there is no guarantees around availability and correctness of the state AFTER the transaction is published. The most obvious example of this is a user sees 200 transactions, publishes their transaction interacting with the contract, then subsequent transactions by others do not get relayed to the user. In the worst case, the data published is actively bad (e.g. invalid UTXOs used as bonds). Since the contract execution occurs in a single step after all participants publish their transactions, a user in the middle must have assurance of correct future committed bonds. How would a user be able to redeem funds from the contract unless it knows exactly which UTXO it is redeeming?
  2. Large Amount of Data. Enforcing state is expensive if the computation needs to be kicked back to the underlying chain (root chain). Plasma is therefore only useful if the contract output state is compactly enforceable on the root chain (e.g. summing, average, netting/crossing, etc.). Most smart contracts can be redesigned in this way to be decomposed into an order book, oracle, or assurance contract. However, how can hundreds of megabytes of summed data be enforced, without earlier participants having data availability upon contract execution?

Many Participants Significantly Increase Complexity

If one wants to do OTC transactions in an inter-chainstate interaction, one can use a cross-chain atomic swap (and can be made inside a Lightning channel). However, channels and atomic swaps cannot inherently compute contracts on many parties in an enforceable manner, e.g. hundreds of participants which could disconnect and go offline at any time within a single state machine.

For state channels, all participants (usually two-party) are presumed to be live (online) at all times. This assures that all participants have data as they only sign off on subsequent states if and only if all necessary enforcement data is given to the other participant. This is a relatively straightforward situation compared to many-party interactions as the state only moves forward with the agreement of all parties. If one took this approach for 100 participants, this would mean that all parties would need to sign off on the new state before the contract moves forward. This lacks viability as if even one out of the hundred participants fails or refuses to sign off on the state, then the entire system halts.

This construction optimizes for minimal state and computation for the underlying asset with increased throughput requirements for the Plasma chain, with higher liveness assumptions.

Inter-Chainstate Contract Approaches

Plasma is an inter-chain enforcement construction. As a design principle, there are different levels of trust minimization of inter-blockchain state (some may be used in combination or complimentary):

  1. Federated-Peg Sidechain: No guarantees provided (only mitigations) for state at rest (e.g. deposits) or state transitions outside of the honesty of the federation. Invalid state transitions for payments are possible, therefore any state at rest can be stolen by the federation if so desired. However, it is possible to design checkpointed exits in the event of the federation halting, but it does not prevent malicious federation collusion/theft. Plasma is not a federated peg sidechain. Parachains as currently designed are sidechains with fraud proofs ("sovereign over state transitions"). Statechains, similar to fedpeg sidechains but with more enforcement properties, does not enforce historically invalid state transitions in the event of a faulty federation. The incentives are often aligned for funds/tokens rooted in the sidechain, but for the federation holding funds outside the sidechain, great care must be made for game theoretic economic security as the federation may collude to steal funds (this works because if the sidechain breaks, the external funds being stolen are still valuable). Increased flexibility and assurance, but with trust in the federation.
  2. Multiple chains with full validation: Examples include merged-mining and extension blocks. Many chain projects which have heterogeneous non-Plasma child chains operate in this space, with its associated validation trade-offs. Sharded chains are often randomized/probabilistic enforcement/validation of chainstates to decrease miner/validator computation and I/O requirements.
  3. Plasma Contracts: Economically enforced state transition for many contract application types. Uses the fact that Settlement Agent(s) are trust-minimized underwriting the state transition. The Settlement Agent is not a trusted entity, nor is the Settlement Agent exposing themselves to counterparty risk in the same way that clearing facilities are in traditional financial systems. This works because contract state is locally enforced based on minimally shared global data. It's presumed that the principal inter-chain state needed for contracts involving many participants are states which could otherwise not be computed local to the output (high amount of data, netting and assurance contracts). All plasma constructions require and presume synchrony, liveness, a lack of long-range equivocation and non-censorship of the root chain(s). Contract execution, as with all inter-chain designs, may not execute in the event of either chain halting (but in some instances can be mitigated by setting halting conditions in the exit game).

These possibilities are not exclusive, they may be a chain which operates under Sidechain assumptions for certain types of problems, and others which are enforceable Plasma contract state transitions. For example, many can delegate computation to a federated peg sidechain to compute on funds which have "no owner", in reality, as with all sidechains the federation has authority to control the state transition. In other words, one could exclusively do Plasma Payments where users delegate funds directly to the federation/validators during computational state transitions and after computation the funds are transferred back to users -- only the state before and after computation is enforceable. This document specifies moving from that construction from Plasma Payments to one where the global state transition itself is enforced.

There is another design consideration not listed in the three examples above, which is interactive computation of cross-chain state (Truebit), as well as computational proofs of cross-chain state (ZK-SNARKS/STARKS). This is presumed to be orthogonal to the problem of cross-chain state as the principal problems are around data unavailability risks (and possibly large datasets for availability proofs) for this particular problem.

The Plasma Contracts construction also presumes an underwriter ("Settlement Agent") as in prior efforts around providing capital (e.g. "Plasma Debit" constructions), but does not require the entity to be the same as the chain operators, nor does it require persistent capital lockup by a single operator, the capital is only locked up during the commitment/computation process itself and can have many ephemeral participants.

Design Overview

The key aspect of this design for netting high-volume many-to-many transactions which require globally synchronized computation in Plasma is that by binding conditional statements which are locally enforced, global enforcement can be inferred if a third party/parties are willing to provide a backstop on the computation. In other words, if a transaction sets a condition, then in order for all conditions to resolve correctly, then any inaccurate computation on the global state results in a loss for the participant(s) signing off on the state. Therefore if a set of participants provide a backstop on the computation by providing fully-collateralized settlement, then it would be the Settlement Agents which lose as a result of improper computation. The Settlement Agent therefore underwrites the state transition and only does so after fully validating the state transition themselves.

One is able to transact between many participants and share a global state transition without significant computational complexity in enforcement on the root chain by having third parties underwrite the state transition after it has occurred (we call these participants "Settlement Agents"). The Settlement Agents are not similar to traditional clearing houses or entities, as they are trust minimized -- traditional roles of being entrusted with correct settlement is not inherent to this construction.

Individual actors are only willing to continue transacting on the Plasma chain if they can have full data availability of the Plasma chain. If there is halting or data unavailability of any part of the chain state, it is presumed that all participants will exit and not continue transacting. UTXOs are spendable according to the current valid state and all state transitions are chains of valid conditional spends/circuits from an output. All UTXOs are presumed to be a specific indivisible denomination.

When a user submits a transaction on the Plasma chain to participate in a contract with many participants, they encode in the transaction rules on acceptance of the state transition. For example, if a contract exchange 1 ABC for at least 1 XYZ upon some triggered condition, the globally published batch exchange rate after computation of committed bids must be at least 1:1. For the individual user, their condition has been met, so they don't actually care whether any other participant has correct execution! Every user has these conditions attached, and thereby the transaction transitions can become globally enforceable. These conditions, as well as all possible dispute circuits/codepaths, are encoded and committed to the output itself. Imagine thousands of conditions, each condition is a restriction on the possible collective end-state. This restriction binds the Settlement Agent to deliver on that end state if they agree that it is correct, therefore a Settlement Agent will only sign if they receive at least an equal amount, and the only way to guarantee this is by only signing if the specific correct state transition has occurred.

These problems described above are two classes of interrelated problems which must be solved (data availability and global enforcement of state transitions). For the user, the data availability problem is that if one was exchanging 1 ABC for 1 XYZ, then one does not know which XYZ they will receive or whether they are even receiving a valid XYZ output. If the computation of the globally published data is invalid (e.g. the exchange rate isn't the correct cross price), then some people may be owed more XYZ than can be delivered.

These two problems may be resolved via non-custodial Settlement Agents by requiring them to use their capital to attest on correct execution to achieve summing/netting.

Enforceable Protocol Flow

An overview of the flow:

  1. Before users submit transactions, Settlement Agents commit UTXOs to be available for settlement. Ideally, this covers all values and types for all possible state transitions.
  2. Users submit transactions. They are committing that they have seen all UTXOs in step 1 and fully validated the chainstate up to step 1.
  3. When the transaction is included, the user provides a commitment that they have seen the transaction and provide a commitment to the resulting state execution.
  4. The user revokes prior output states, they are committed to the contract
  5. The transaction window closes. The final output state is computed.
  6. Settlement Agents sign off on the state transition. They MUST have full data available up to step 5. If they cannot, they do not participate in the contract execution and are refunded after a delay.
  7. If an insufficient amount of UTXOs are available, Settlement Agents may deposit on the root chain the remaining collateral necessary. They are signing off on seeing up to step 5 and the correct execution of the contract.
  8. The validators publish on the root chain a bitfield of Settlement Agents who signed off (in step 6)
  9. When sufficient UTXOs are signed off to be able to execute, then the contract state transition is finalized, ownership has effectively transferred.
  10. If the user has not revoked their prior state (step 4), provided that a transfer of ownership has occurred, then an on-chain state update is necessary before that particular output can be spent. The user may bear a small penalty to pay for this as a result.

While the image below may look complex, the root chain only needs to use the content in green, all other aspects are effectively node/client-side only and they continue participating only if the execution is correct.


The result is that the Settlement Agents are minimizing computational risk, as they are explicitly signing off on the computation in step 6 (and possibly 7).

As much of the computation is deferred to user validation and the Settlement Agent, the root chain contract/script only needs to primarily deal with interaction of root state commitments, Confirm/Revoke User UTXO Tx, (post-trade) Confirm On-chain Funds Commitments Txes, Finalize Settlement commitment / SA Commit Bitfield Txes, and Confirm Force Revoke UTXO Tx. All other output paths are inherent to the Plasma chain itself and do not need to be analyzed by the root chain. The watcher of any disputes can provide any sufficient and necessary data as each of those transactions have committed to the state at time of transaction creation. All transaction data must be committed to the state when creating the transaction to assist in this activity. In the event the committed state is invalid, the Plasma validators must not include it in the block. Similarly, if the users and validators have inserted invalid data into the block, the Settlement Agents will refuse to underwrite the chainstate.

In the most extreme designs (likely out of scope for many implementations), it is even possible to have full disassociation of chain validation between chainstates, meaning that a Plasma chain can transact without validating the external chain as a consensus rule (with some additional work, such as the user committing to which Settlement Agents it agrees with in step 2, with some other trade-offs). This means that while a Plasma chain may likely be primarily rooted in one chain, the chain itself can support other chains without requiring yet another blockchain to watch. This is possible because it is the users who are validating the external chains and committing to outputs which they have validated themselves. Each alternate root chain state would have wholly different contracts (and therefore different participants/transactions) as transactions would be committing to different sets of data. The alternate root chain still needs to support the Plasma design, however.

Pre-Commitment of Capital

Every output being updated is merkelized and committed to a specific contract round.

The prior individual outputs are spent in the Plasma chain and converted to a bound state conditional upon the current owner (Settlement Agent) signing off on it. If the Settlement Agent refuses to sign off, their funds are returned in the event a signature is not produced. In the event of it being returned due to non-signature or invalid chain state, it can either be withdrawn on-chain or updated inside the Plasma chain back to the original owner.

To set the capital as committed, the output is updated to be spendable conditionally upon an output which is either a dispute which cancels the withdrawal (via a proof it has already been spent, with no locktime), a timeout withdrawal (with a locktime), or an output which commits to the contract conditions defined by all parties which is spendable with witness data provided at a later date (signature by SA, recipient, total amount consumed by all participants, proof of a valid finalization transaction occurring at the correct time). These three possible conditions set up the path for the settlement capital. Note that the third condition is entirely opt-in, but once signed off on then becomes non-revocable (unless a finalization transaction is not published, then it times out and the funds become again spendable by the SA).

The SA's possible codepaths have either them getting their money back, or them signing off on giving it conditionally upon them receiving the same amount atomically (presuming correct root chain non-reorganization and non-censorship).

Output Computation in Trades

There is a problem of how to compactly compute the UTXO ownership on the state transition on a globally released state (e.g. an exchange rate or oracle result).

It is absolutely necessary for global consensus on the transfer of the UTXO ownership; one must know which UTXO one owns provided a certain result is published.

The complexity is when one puts in an order, one must be able to reserve a certain amount of outputs and claim them upon a particular price.

This requires being able to transfer funds at the exact condition for all state transitions, as well as knowledge of which UTXOs one will receive. There are multiple possible ways to solve this.

A simple solution would be to require all commitments to produce outputs which can execute at all possible returned values. For example, if a transaction will be executed based on a clearing price, then all possible clearing prices should be able to be made. This can simply be done by requiring transaction deposits to include all powers of two up to the total amount being transacted. If a user doesn't have outputs for all powers of two, then one can trade for those outputs before issuing one's order.

Each Settlement Agent commitment must have a standard amount of outputs of each type. This is to ensure ease of calculation when the validators commit that a sufficient value and number of outputs are available. Settlement Agents can provide multiple commitments (with multiple bitfield slots) if they are providing a significant amount of capital.

For the second problem of knowing UTXO state claims, the User Confirm/Revoke Tx commits to:

  1. The Settlement Agent UTXOs committed into a tree ordered by asset type, then by Settlement Agent, then by amount (all Users' Tx should commit to the same hash)
  2. The relative UTXO positions of each amount being claimed. This is necessary as one does not yet know which SA will be signing off.

While there are more capital efficient methods consuming less liquidity, it increases complexity, e.g. committing to all possible contract output states in a merkle tree.

Note that the Settlement Agent has not yet committed to the total settlement UTXO set (as they had not yet known the entire committed UTXO set when they did the Allocate UTXO Tx).

Contract conditions

It's required to define conditions for successful execution of transaction state as these are locally computed. The theory is that one sort of doesn't care what everyone else does in the future as long as these conditions hold. One cannot rely on correct execution of anything in the future, therefore, these are the conditions which are held as inviolable. When multiple participants have transactions using the same output conditions, execution of participants' states thereby become bound and constrained to a single possible correct output state. This constraint limits the Settlement Agents to only want to sign off on the correct state.

After Settlement

The ability to withdraw on the root chain implies the transfer of ownership.

As with other withdrawal mechanisms, it's presumed that proofs of spentness cancels the withdrawal (the current UTXO state is not the state attested to by the withdrawer) and is not described here for succinctness. Note that witnesses may be necessary for proofs of spentness when the withdrawer is responding to a withdrawal challenge and therefore the challenge bonds should be sufficiently high to account for this.

All parties compute the state transition with all transactions (and other associated data) as an input.

The Settlement Agent then signs a commitment to:

  1. Total funds being exchanged by all parties (ordered by denomination)
  2. Merkle root containing UTXO root of all committed UTXOs for settlement (irrespective of whether they have signed commitments approving the state transition)
  3. Commitment to state transition result

After sufficient Settlement Agent signatures, the validators publish on the root chain a bitfield of all Settlement Agents which have signed, with a commitment to the state transition result, merkle root of all Settlement Agents, and the total funds being exchanged by all parties (ordered by denomination).

There is a dispute period whereby any Settlement Agent can disagree with this finalization transaction published by the validators. In the event of successful dispute, the finalization transaction is cancelled. Possible disputes include (but not limited to):

  1. Invalid inclusion (challenge/response dispute)
  2. Disagreement on merkle root of committed UTXOs for settlement
  3. Disagreement on total funds being exchanged
  4. Disagreement on commitment to state transition result

After the dispute period, in the event of no disputes, the state transition is locked in and the contract state transition or trades are finalized.

To claim/withdraw, it is most likely more efficient to do a payment on the Plasma chain which results in a simple output. In the event the Plasma chain has halted, the SA can withdraw from the users' output by providing:

  1. Proof their bit was included in the bitfield (with proof of the finalization transaction), and proof of the state transition result used in the User Commit Tx
  2. Relevant parts of the User Commit Tx claiming a specific position and conditions for execution (conditions output can result in different set of UTXOs being claimed), with proof of inclusion of the User Commit Tx. The conditions are a share commitment to identify transacting on the same contract conditions.
  3. Offset position of the output (to assist in the contract finding the position)

What is being made here is a proof ensuring that the User's output condition has been fulfilled, as well as that the SA has sufficient authorization for the User's output. If the SA has not signed off on the state transition or their funds were not used, they can claim their original locked funds in the Plasma chain (with a simple spend) or the root chain (by providing proof that they were not in the bitfield OR a time delay for a dispute by a user with a User Commit Tx to prove they were the rightful owner).

When the withdrawal is initiated and proven, there is a subsequent delay to prove there has been no subsequent spends.

The offset position is an optimization needed to calculate which output is being claimed. As each bit in the bitfield are providing a specific number of UTXO denominations, the transaction asserts which SA's bit is being used for settlement, since we don't want to manually count bits. It's faster to provide the offset and verify it by doing a log2 of an array of bits to count the number of bits enabled (and therefore it verifies the offset being asserted). This now verifies that the SA has signed off on the Finalization Tx.

In essence, the SA as provided proof that they can claim a UTXO from a User Commit Tx output since they have provided an equally valued UTXO for the contract.

In the other side, the User can claim a different UTXO from a SA. The user must provide:

  1. Their User Commit Tx which provides claims on a specific position and conditions for execution (conditions output can result in different set of UTXOs being claimed), with proof of inclusion
  2. Relevant parts of the Finalization Tx, including state transition used to compute output and bitfield
  3. Offset

This lets the User claim a specific output from the SA. Note that in this case the User is claiming the SA's funds locked up from the Allocate UTXOs step. When the SA is claiming from the Users' funds, it is the funds locked up in the User Commit Tx.

When the withdrawal is initiated and proven, there is a subsequent delay to prove there has been no subsequent spends.

In the event the User has not seen the User Commit Tx due to data unavailability, and the user has not seen proof of inclusion for the User Commit Tx, the user may not know whether their transaction/order has executed. Consequently, the user may attempt to withdraw from the User Allocate Tx. If this is invalid, the SA who is the rightful owner can submit proof of inclusion for the User Commit Tx (which the user may use later) in the root chain. The Plasma chain can penalize the user with any reserve funds (does not need to be consensus enforceable on the root chain in simple designs). It's presumed that the user is keeping some funds for transaction fees and penalty deposits in a sidechain construction on the Plasma chain in de minimis amounts (fees entrusted in a federation, all other value is in a Plasma construction, this can be further decentralized but requires more code in the exit game).

These interactive exits are only necessary in the event of large long-term directional fund flows, the Plasma chain halting, or the system going byzantine. It's presumed that transacting inside the Plasma chain makes the need for elaborate exits unnecessary in most cases. However, note that any fee economics presumptions should consider that these spentness proofs may need to be provided if someone attempts to withdraw a spent output which has been locked in this transaction -- this requires a larger proof to be broadcast in the future by a 3rd party (the current owner of the UTXO, which may not be the prior user which participated in the contract).

Relevant Contract Types

With research on the constructions which is possible to minimize trust, it's clear that game theoretic summation via Settlement Agents (the above construction), as well as assurance contracts may be a primary construction necessary for inter-blockchain state. Nearly all other constructions can compose those constructions as well as UTXO conditions to create enforcement. Most other contracts either rely upon oracles or can be minimized to an output condition. Plasma Cash and Plasma Contracts as a design consideration aggressively pushes the state construction to be removed from consensus validation (the source of where the benefits arise in Plasma), consequently it takes the position of ensuring data availability and inter-blockchain assurances with the trade-off of higher client-side validation and partial liveness (and non-reorg) requirements of the root chain. Unlike Counterparty-like constructions of client-side validation, however, this construction supports smart contracting with both deposits and withdrawals which consequently supports true value exchange.

These roles of ensuring correct computation of summed transacted values and assurance contracts reflect the roles that clearing corporations/agencies have provided in the traditional financial systems.

UTXO Change

It's presumed that there will be open pre-signed offers to exchange Plasma Cash UTXOs for a microscopic fee by participants who want to increase/decrease their denominations. Settlement Agents will likely also serve this role as they will be holding many UTXOs as well. Users submitting transactions committing capital should include units of all powers of two up to the value being transacted to ensure exact precision of post-execution state.

Nested Child Chains

Further research is possible to construct the ordering of the Confirm Tx, but it is possible by requiring all users in the child chain to create transactions and to have a single Settlement Agent issue transactions on behalf of the user. The SA would still consume a bit on the root chain bitfield specific to that child chain. As only the deltas between child chains are transacted, this would result in a significant storage savings in Plasma chain validation (one would monitor the child chains in which they hold UTXOs, as well as the Plasma Chain and root chains holding funds). The SA would be only transacting the netted value in the top level Plasma chain. Censorship risks may be higher in nested chains. Again, this requires greater research but would be a source of client-side validation improvements but not necessary unless there is extremely high volume.

When Plasma Contracts is Most Relevant

This class of problem is limited to many-to-many state transitions, as most other use cases are resolvable with Plasma already or aren't relevant. While Plasma had a design goal of scalability in smart contract execution, guarantees about using this for long-term UTXO entry scalability is undefined; it should be obvious that root-chain storage of funds is the most robust (one can rapidly move money in and out of the Plasma chain by doing a cross-chain swap). We can classify different types/levels of state transitions with many parties:

  1. Data-only, no financial value: Doesn't affect inter-blockchain interaction therefore this Plasma construction isn't relevant. Generated states usable elsewhere can be provided by merkelized proofs of existence with some kind of dispute functionality (however, this increases data storage/availability requirements for certain use cases, e.g. NFT breeding inside the Plasma chain). For external states which are pushed (e.g. data feed), one can treat the problem as an Oracle problem.
  2. State transition for financial value inside a single chain (e.g. token which is rooted in the Plasma chain): Doesn't affect inter-blockchain state therefore no exit game is necessary (e.g. one issues a stablecoin inside a sidechain; issuing tokens inside the Plasma chain instead of an ERC20). State transitions and exchanges are possible without Plasma at all, as Plasma deals with inter-chain interaction. Most fiat, loyalty points e-wallet or payment proposals may limit use of Plasma to only inter-chain state as there is no external state/chain needed.
  3. Over-the-counter state transition with inter-blockchain collateral: One-to-one state transition (e.g. a payment or trading an NFT for some kind of value). The NFT/payment with external collateral use case is already enabled with regards to the Plasma Cash construction, or if one wants speed can use a Lightning Network construction (trading off liquidity for speed, which Plasma is not designed to solve). Additional conditions can be attached as a part of an enforceable exit game. For example, an NFT auction can sell to the highest bidder and if one wants to enforce on-chain, the highest bidder can redeem with a dispute period for anyone else to publish a committed bid of a higher value.
  4. Many-to-many state transition with inter-blockchain collateral: This is what this document specifically attempts to resolve. Examples include fully-collateralized decentralized exchanges, futures contracts, exotic crowdfunding assurance contracts, or any type of transaction involving value whose underlying asset is not rooted within the Plasma chain itself. Note that any limitations on transaction approval is the responsibility of the chain's consensus rules in the Plasma chain itself. Currently, many people do issued assets with trusted custodians ("gateways" / "fedpeg sidechains") to achieve many-to-many state transitions, but Plasma allows for gateway-free interaction without fully trusted custodians.


Special thanks for the engineers working on implementations of Plasma, their leadership allows for research to have materialized and hopefully assist in implementation efforts.

This post depends upon the following (alphabetical non-exclusive list of) people who have participated in the Plasma Cash design, in addition to the many people in the community (apologies for not being sufficiently exhaustive): Ben Jones, Dan Robinson, Georgios Konstantopoulos, Joseph Poon, Karl Floersch, Kelvin Fichter, Vitalik Buterin, Xuanji Li.

Relevant documents (please contact to add more relevant historical references):

Dan Robinson - Plasma Debit: Arbitrary-denomination payments in Plasma Cash

Kelvin Fichter - Simple Fast Withdrawals

Vitalik Buterin - Minimum Viable Plasma

Gregory Maxwell - CoinWitness

Dan Robinson - Plasma with client-side validation (Plasma Cash)

Vitalik Buterin - Plasma with much less per-user data checking (Plasma Cash)

Georgios Konstantopoulos - Paper summarizing the community's Plasma Cash research

Vitalik Buterin - RSA Accumulators for Plasma Cash history reduction

Karl Floersch - PoS Plasma Cash with Sharded Validation

Kelvin Fichter - Plasma XT: Plasma Cash with much less per-user data checking (checkpointing)

Sourabh Niyogi - Plasma Cash with Sparse Merkle Trees, Bloom filters, and Probabilistic Transfers

Xuanji Li - One proposal for plasma cash with coin splitting and merging

Josojo - Plasma snapp - fully verified plasma chain

Xuanji Li - State Channels and Plasma Cash