---
# System prepended metadata

title: Account based plasma attack vectors

---

# Account based plasma attack vectors

#### Matic is using MVP for burn style exits and MoreVp for in-flight exit and both are sharing same Priority Queue, we should store utxoPos seperatly but use same PQ.
should we store utxoPos(exitId mappings) seperatly - to identify duplicate exits in both BE & ME ?

### Possible Attacks

-   Operator makes out-of-nowhere(deposits or changes in tx receipts) and withholds block for x checkpoints and then starts mass for n amount with refrences to checkpointed transactions, since other user don't have data for checkpointed blocks they can't challange.

- Operator creates false deposits.

-  For ME how does contracts knows about competing transactions, same reference tx ? A sends to be and A send to C as well.

-  For the same amount can users do BE and ME both and get away with it ?

-  In UTXO MoreVp utxo's are signed by users, in case of Matic users sign raw tx and UTXO style logs are generated by operator, So in case of malicious operator he can temper with utxo logs is this going to make any impact on our MoreVp exits ? 


#### :laughing: 
 what if someone runs the same node and fabricates false data with bunch of private keys, even in the case of operator once they unstaked those keys can be bought cheaply.


## Things to check/think
- Deposits can't be reference tx, for moreVp exits since technically deposits are out-of-nowhere transactions.(basically moreVp exits for should refer to deposit on chain rather then matic chain's deposits)!?
-
- How are we going to identify canonical and competing tx on client side for challange purposes.










## Glossary 
 BE- Burn exit
 ME - moreVp exits
 Canonical tx - amount is not spent already
 competing transactions - tx which are spending same input
 
 
 references 
 - https://ethresear.ch/t/more-viable-plasma/2160
 - https://ethresear.ch/t/minimal-viable-plasma/426