tags: WIP, documentation
# Matic Security Models
Matic’s plasma chain builds upon Plasma MoreVP with an account based implementation. In the account model, transactions are interpreted as events to the blockchain state machine and the Ethereum Virtual Machine computes the state transition result of these events based on prior blockchain state.
The two main components that differ Matic’s implementation from other Plasma implementations are:
1. State based sidechain running on EVM (account based)
2. Public checkpointing layer (running Proof of Stake)
Matic works as a three layer architecture
1. Plasma smart contract on the Root Chain
2. Heimdall (Proof of Stake checkpointing layer)
3. Bor (Block producer layer)
### Bor (Block Producer Layer)
Bor is Matic’s plasma chain block producer - the entity responsible for aggregating transactions into blocks.
### Heimdall (Checkpointing Layer)
Heimdall layer handles the aggregation of blocks produced by Bor into a merkle tree and publishing the merkle root periodically to the root chain. This periodic publishing are called ‘checkpoints’. For every few blocks on Bor, a validator (on the Heimdall layer):
1. Validates all the blocks since the last checkpoint
2. Creates a merkle tree of the block hashes
3. Publishes the merkle root to the main chain
Checkpoints are important for two reasons:
1. Providing finality on the Root Chain
2. Providing proof of burn in withdrawal of assets
A bird’s eye view of the process can be explained as:
- A subset of active validators from the pool are selected to act as block producers for a span. The Selection of each span will also be consented by at least 2/3 in power. These block producers are responsible for creating blocks and broadcasting it to the remaining of the network.
- A checkpoint includes the root of all blocks created during any given interval. All nodes validate the same and attach their signature to it.
- A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the same on the main-chain.
- The responsibility of creating blocks and also proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.
### Matic Plasma Smart Contracts (on Root Chain)
The plasma contract on ethereum records the order in which plasma blocks are committed by the operator, and prevents commitments from ever being overwritten.
## Security Models
Matic provides three types of security models for a developer to build their DApp upon:
1. Plasma security
2. Proof of Stake security
3. Hybrid (Plasma + PoS)
What follows is a description of each of these security models offered by Matic, and what would be the developer workflow for each with an example DApp.
### Plasma Security
Matic provides Plasma Guarantees with respect to various attack scenarios. Two main cases considered are:
- Chain operator (or in Matic, the Heimdall layer) is corrupt
- The user is corrupt
In either case, if a user’s assets on the plasma chain have been compromised, they’d need to start mass exiting. Matic provides constructions on the rootchain smart contract that can be leveraged. (For more details and technical specifications regarding this construction and attack vectors considered, read [here](https://ethresear.ch/t/account-based-plasma-morevp/5480.)
Effectively, security offered by Matic’s Plasma contracts piggybacks on Ethereum’s security. Users’ funds are only ever at risk if Ethereum fails. Put simply, a plasma chain is as secure as the main chain consensus mechanism. (This can be extrapolated to say that the plasma chain can use really simple consensus mechanisms and still be safe.)
#### For developers
As a DApp developer if you’d like to build on Matic with Plasma security guarantee, you are required to write custom predicates for your smart contracts. Which basically means writing the external contracts that handle the dispute conditions set in place by the Matic plasma constructs.
### Proof of Stake security
Proof of Stake security is provided by the Heimdall layer which is built on top of Tendermint. A checkpoint is committed to the root chain only when ⅔ of the validators have signed on it.
#### For developers
As a DApp developer, to build on PoS security, the procedure is as simple as taking your smart contract and deploying it on Matic. This is possible because of the account based architecture enabling an EVM-compatible sidechain.
Apart from pure Plasma security and pure Proof of Stake security that is possible in DApps deployed on Matic, there is a Hybrid approach that developers can follow - which simply means having both plasma and proof of stake guarantees on some particular workflows of the DApp.
This approach is better understood with an example:
Consider a gaming DApp with a set of smart contracts that describe the game’s logic. Let’s say the game uses its own erc20 token to reward players. Now, the smart contracts defining the game logic can be deployed on Matic sidechain directly - guaranteeing Proof of Stake security to the contracts while the erc20 token transfer can be secured with Plasma guarantees and fraud proof embedded in Matic’s root chain contracts.