# Table of Contents - [Overview | Plasma Docs](#overview-plasma-docs) - [Use Cases | Plasma Docs](#use-cases-plasma-docs) - [Roadmap | Plasma Docs](#roadmap-plasma-docs) - [Why Bitcoin | Plasma Docs](#why-bitcoin-plasma-docs) - [System Overview | Plasma Docs](#system-overview-plasma-docs) - [Core Features | Plasma Docs](#core-features-plasma-docs) - [Consensus | Plasma Docs](#consensus-plasma-docs) - [HotStuff | Plasma Docs](#hotstuff-plasma-docs) - [PlasmaBFT | Plasma Docs](#plasmabft-plasma-docs) - [Committee Formation | Plasma Docs](#committee-formation-plasma-docs) - [RPC-API | Plasma Docs](#rpc-api-plasma-docs) - [References | Plasma Docs](#references-plasma-docs) - [Hardware Requirements | Plasma Docs](#hardware-requirements-plasma-docs) - [Bitcoin Bridge | Plasma Docs](#bitcoin-bridge-plasma-docs) - [Execution | Plasma Docs](#execution-plasma-docs) - [EVM Details | Plasma Docs](#evm-details-plasma-docs) - [Official Links | Plasma Docs](#official-links-plasma-docs) --- # Overview | Plasma Docs ### [](#what-is-plasma) What is Plasma? Plasma is a high-performance, scalable, and secure blockchain purpose-built for stablecoins. Traditional blockchains were designed long before stablecoins existed or gained traction. Today, stablecoins have over $225 billion in supply and see trillions of dollars transferred monthly, making them one of crypto’s most critical use cases. However, current blockchains face significant obstacles for stablecoins, such as high transaction fees, centralization issues, high transaction failure rates, and a lack of specialized features required to support stablecoins from first principles. With backing from Bitfinex/USDT0, Plasma is engineered from the ground up to meet the unique needs of stablecoins. Our team brings together expertise in software engineering at Apple and Microsoft, high-frequency trading at Goldman Sachs, distributed systems research at Imperial College London and Los Alamos National Lab, and hands-on experience building some of the largest stablecoins and blockchains. ### [](#technical-overview) Technical Overview At its core, Plasma leverages **PlasmaBFT**, a custom consensus protocol inspired by Fast HotStuff, to achieve rapid finality and low-latency transaction processing. The consensus and networking layers are optimized for the demands of high-frequency, global stablecoin transfers. Our execution layer is built on **Reth**, a high-performance, modular, Ethereum-compatible execution engine written in Rust. Plasma introduces several performance and usability enhancements at the execution layer while remaining fully compliant with the EVM specification. In practical terms, any smart contract deployable on Ethereum can be deployed on Plasma without requiring any code modifications. Plasma also integrates a native, trust-minimized **Bitcoin Bridge** that periodically anchors state differences on Bitcoin. Although Plasma is technically a Layer 1 blockchain with its own consensus mechanism, the native Bitcoin Bridge and design philosophy align it with the Bitcoin ecosystem—making it what's considered to be a Bitcoin sidechain. Furthermore, Plasma introduces unique stablecoin-centric features: * **Custom Gas Tokens:** Allow fees to be paid in popular assets like USDT or BTC via an automated swap mechanism. * **Zero-Fee USDT Transfers:** Enable fee-free transfers for simple transactions with adaptive prioritization. * **Confidential Transactions:** Protect users’ transaction details through confidential transactions without sacrificing compliance (currently under active research). Together, these technical components create a robust blockchain optimized for stablecoins, delivering rapid performance, high security, and cost efficiency. ### [](#roadmap) Roadmap Our focus on stablecoins drives us to prioritize direct integration with stablecoin issuers, onramps, liquidity providers, banking-as-a-service platforms, fintechs, and related institutions. We plan to launch an initial mainnet beta built on a robust, secure foundation to begin these integrations early. For our initial mainnet beta, Plasma will deploy its core components: the PlasmaBFT consensus protocol, rigorously optimized for high throughput and low latency, and a fully EVM-compatible execution layer built on Reth. This configuration forms the essential foundation for future core feature enhancements and performance improvements. [NextUse Cases](/introduction/use-cases) Last updated 1 month ago --- # Use Cases | Plasma Docs [PreviousOverview](/) [NextWhy Bitcoin](/introduction/why-bitcoin) Last updated 1 month ago ### [](#market-landscape) Market Landscape Stablecoins have emerged as one of crypto’s most critical use cases, fundamentally reshaping global finance. With a current supply exceeding $225 billion, stablecoins provide 24/7, near-instant, composable, and programmable money that is far more efficient than legacy financial systems. Their inherent advantages—global accessibility, reduced settlement times, and seamless programmability—position them as the future of global finance. Stablecoins now account for approximately 1.08% of the USD M2 money supply. As regulatory frameworks evolve and support for digital assets strengthens, it is only a matter of time before stablecoin supply reaches the trillions. This represents a unique opportunity not only for crypto but also for the broader financial industry. Despite their growing importance, no general-purpose blockchain is currently equipped to handle the unique demands of stablecoins. Traditional blockchains were designed long before stablecoins existed, and as a result, they face significant challenges such as high transaction fees, centralization issues, high transaction failure rates, and a lack of specialized features that stablecoins require. These challenges are limiting the rate of stablecoin adoption. Historically, stablecoins were primarily used as instruments to facilitate easier trading against Bitcoin on exchanges—serving as tools for crypto-to-crypto trading pairs. Over time, two additional primary use cases have emerged: yield rehypothecation and settlement. Today, a significant portion of stablecoin supply is concentrated on just two chains: Ethereum, with roughly $132 billion, and Tron, with approximately $63 billion. Ethereum has become the leading blockchain for yield generation, while Tron has positioned itself as the dominant settlement layer. However, both blockchains have inherent shortcomings: Ethereum struggles with high fees, and Tron faces both high fees and extreme centralization. Moreover, neither was originally designed with stablecoins in mind, nor do they include specialized features tailored to their unique requirements. ### [](#purpose-built-blockchain-for-stablecoins) Purpose-built Blockchain for Stablecoins Our primary focus is on capturing the market for stablecoin yield and global settlement. By building a blockchain from the ground up that is optimized for stablecoins, we aim to provide a platform that not only supports but enhances these use cases and addresses the challenges present in general-purpose blockchains. This requires solving unique technical challenges—such as throughput, latency, and specialized feature development—as well as achieving deep integrations with stablecoin issuers, onramp providers, liquidity providers, banking-as-a-service platforms, DeFi applications, fintechs, and other financial institutions. We believe this represents not only the largest opportunity in crypto but also one of the most significant opportunities in the world—a focus we are committed to pursuing over the next decade. ![](https://docs.plasma.to/~gitbook/image?url=https%3A%2F%2F30806345-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FnO2kf3iLnk3p5wnpui1z%252Fuploads%252FBfixhRSF8jTZvRhDrygn%252FPlasma%2520Overview.png%3Falt%3Dmedia%26token%3D55cc2300-3394-4ddc-ae40-4deee6949350&width=768&dpr=4&quality=100&sign=17340c8b&sv=2) --- # Roadmap | Plasma Docs This roadmap is subject to change as we refine our approach based on integration feedback and evolving market demands. Plasma’s development follows a phased rollout strategy that prioritizes rapid deployment and integration with key stablecoin infrastructure, applications, and stakeholders. This approach ensures that while the initial mainnet beta may not be feature complete, it establishes a robust and secure foundation to begin critical integrations and allows for continuous, real-world improvements. **Phase 1 – Mainnet Beta:** For the initial launch, Plasma will deploy its core components: the PlasmaBFT Consensus Protocol, rigorously optimized for high throughput and low latency, and a fully EVM-compatible execution layer that supports existing smart contracts. This phase establishes a stable foundation for early integration with stablecoin issuers, onramp providers, liquidity providers, banking-as-a-service platforms, fintechs, and other key partners. **Phase 2 – Bitcoin Bridge and Settlement:** Following the mainnet beta, we will implement the Plasma native, trust-minimized Bitcoin Bridge and settlement mechanism. This phase will deploy a bridge that anchors Plasma state differences to Bitcoin, ensuring seamless access to Bitcoin liquidity and robust interoperability between Plasma and Bitcoin. **Phase 3 – Core Feature Enhancements and Performance Improvements:** Once the fundamental components are stable, our focus will shift to shipping Plasma’s core stablecoin features—including custom gas tokens, zero-fee USDT transfers, and confidential transactions—while optimizing performance, usability, and network efficiency. This phase will address the technical challenges of stablecoin payments, such as throughput, latency, and specialized feature development. **Phase 4 – Native Tooling and Infrastructure:** Next, we will build and release native developer tooling and infrastructure specifically for stablecoins. This phase will deliver comprehensive APIs, SDKs, and management tools that facilitate seamless wallet and onramp integration, empowering developers and financial institutions to fully utilize Plasma’s stablecoin-first architecture. Rather than spending years in research and development to achieve a fully feature-complete product, our phased rollout approach allows us to engage with real-world integrations from the outset. This strategy enables us to bootstrap applications, infrastructure, and liquidity while continuously prioritizing subsequent features based on market demand and developer feedback. [PreviousWhy Bitcoin](/introduction/why-bitcoin) [NextSystem Overview](/architecture/system-overview) Last updated 1 month ago --- # Why Bitcoin | Plasma Docs Plasma is built on Bitcoin because its unmatched security and decentralization provide the ideal foundation for global stablecoin settlement, while Bitcoin itself stands as the premier store-of-value asset. Bitcoin’s robust, trustless network provides an immutable, tamper-resistant layer of security that anchors our system, ensuring that Plasma is built on the most resilient foundation. While stablecoins represent tokenized fiat money, Bitcoin embodies key monetary properties—scarcity, decentralization, and global acceptance—that position it as the apex saving asset. Unlike fiat currencies, which are subject to inflation and centralization, Bitcoin is a non-sovereign, trustless asset whose value proposition grows stronger over time. As traditional payment infrastructures evolve, stablecoins will serve as the preferred medium for everyday transactions, while Bitcoin will increasingly be used as a store of value. This intersection of onchain stablecoin and Bitcoin liquidity will enable novel financial applications and use cases that were previously limited. Plasma periodically checkpoints its state diffs on Bitcoin because anchoring on Bitcoin delivers permissionless finality, stronger censorship resistance, and a universally verifiable source of truth. By embedding cryptographic summaries of Plasma’s state into the Bitcoin L1, any participant (including SPV‑style light clients) can independently verify the entire Plasma history without trusting Plasma validators. Reversing a checkpointed state would require reorganizing Bitcoin itself—making tampering computationally impractical given Bitcoin’s Proof‑of‑Work security. By building Plasma as a Bitcoin sidechain, we merge the security and decentralization of Bitcoin with purpose-built stablecoin functionality. This creates a platform where the best elements of both worlds converge: a settlement layer anchored by the most secure blockchain and an execution environment optimized for high-throughput, low-latency stablecoin payments. We at Plasma, along with our partners at Bitfinex, have long been advocates for Bitcoin. Building on Bitcoin was a conscious, long-term design decision. Stablecoins will be incredibly beneficial for Bitcoin as an asset, and we’re committed to contributing to that future. In the words of Paolo Ardoino, CTO at Bitfinex: “With strong growth in both supply and users, we are entering a new phase of mainstream adoption for stablecoins. To meet this challenge, it’s more important than ever to have secure, decentralized, and scalable infrastructure in place. Plasma is designed to provide these essential rails by leveraging Bitcoin as its security layer.” [PreviousUse Cases](/introduction/use-cases) [NextRoadmap](/introduction/roadmap) Last updated 1 month ago --- # System Overview | Plasma Docs [PreviousRoadmap](/introduction/roadmap) [NextCore Features](/architecture/core-features) Last updated 1 month ago Plasma's architecture blends high-speed, modern consensus with Ethereum's battle-tested execution environment, all resting on top of Bitcoin for security. Understanding how these components fit together is critical to why Plasma is **uniquely powerful for stablecoin settlement**. PlasmaBFT, our highly efficient consensus layer, integrates seamlessly with a Reth-derived execution client using a loosely coupled design built on the Engine API. In this design, PlasmaBFT handles sequencing while a Reth core manages transaction execution and EVM state management. This ensures that Plasma inherits **full EVM compatibility** without compromise: Reth guarantees that every smart contract and opcode behaves exactly as it would in Ethereum, while PlasmaBFT propels the chain forward. Critically, this design accelerates performance beyond native approaches. Our consensus model can propose and finalize blocks in near-real time without requiring finality gadgets or other compatibility mechanisms. Instead, we optimize for speed and decisively confirm transactions, exceeding current industry standards while preserving the proven EVM model. On this foundation, we leverage the strengths of our design to provide a **decentralized settlement layer** on Bitcoin. This enables users to move assets between chains and secure their assets using Bitcoin's PoW when appropriate—in a trust-minimized approach that ensures assets are never solely controlled by the bridge. In the following sections, we will dive deeper into our design choices and lay out the roadmap for where Plasma will evolve. ![](https://docs.plasma.to/~gitbook/image?url=https%3A%2F%2F30806345-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FnO2kf3iLnk3p5wnpui1z%252Fuploads%252FtE2tNnr0F6uQjBK9Gbvw%252Farch-light.png%3Falt%3Dmedia%26token%3D775153ca-1b90-42a9-a63b-237dc9c9d609&width=768&dpr=4&quality=100&sign=2ff342de&sv=2) ![](https://docs.plasma.to/~gitbook/image?url=https%3A%2F%2F30806345-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FnO2kf3iLnk3p5wnpui1z%252Fuploads%252FLtCWQjHc1tyaVpumIdZx%252Farch-dark.png%3Falt%3Dmedia%26token%3D3b5fa55d-d928-482d-b9dd-51e8c0439e3c&width=768&dpr=4&quality=100&sign=273fe2f6&sv=2) --- # Core Features | Plasma Docs These features are under active research and development and subject to change in implementation design. Plasma is focused on enhancing the stablecoin user experience with features that traditional blockchains often overlook. Designed from first principles for stablecoin payments, these core features directly address the shortcomings of general-purpose blockchains when handling stablecoins. While not live in the initial mainnet beta, they will be rolled out in future upgrades to meet the unique needs of stablecoin users. ### [](#custom-gas-tokens) **Custom Gas Tokens** To simplify the user experience, Plasma allows transaction fees to be paid in whitelisted assets—such as USDT or BTC—instead of requiring a dedicated fee token. When a non-native token is used, an automatic swap mechanism powered by embedded oracle data converts it at the current market rate into the native fee token. This seamless integration prevents situations where users are blocked from transferring stablecoins due to the absence of a separate native token, ensuring **smoother and more intuitive transactions**. ### [](#zero-fee-usdt-transfers) **Zero-Fee USDT Transfers** High or unpredictable fees can significantly burden price-sensitive users in volatile economies. Plasma addresses this by offering zero-fee USDT transfers exclusively for simple, metadata-free transactions. These transfers leverage a **split block architecture**: one block layer processes fee-paying transactions, while another parallel layer isolates zero-fee transfers to prevent them from congesting the main network. An adaptive, delay-based prioritization mechanism further balances network load, allowing users to opt for fee-free transfers with longer acceptable delays. Additionally, protective measures—such as rate limiting, aggressive transaction replacement policies, and minimum balance requirements—are in place to mitigate spam and abuse, ensuring that zero-fee transfers remain a public good without compromising network security or performance. ### [](#confidential-transactions) **Confidential Transactions** Recognizing the need for privacy, Plasma is actively researching confidential transaction techniques. Through the deployment of **shielded transactions**, Plasma aims to protect users’ financial histories by concealing transaction details, thereby enhancing privacy while maintaining security and compliance. Together, these core features underscore Plasma’s commitment to a stablecoin-first experience, delivering solutions that enhance usability, affordability, and privacy for a global user base. [PreviousSystem Overview](/architecture/system-overview) [NextConsensus](/architecture/consensus) Last updated 1 month ago --- # Consensus | Plasma Docs Plasma is secured by **PlasmaBFT** — an in-house implementation of Fast Hotstuff, a modern and efficient Byzantine Fault Tolerant (BFT) protocol. Fast Hotstuff streamlines consensus by reducing communication rounds, ensuring rapid confirmation of transactions. Written in Rust, PlasmaBFT is optimized for low end-to-end latency — the duration from when a request is sent until a committed response is received. This design meets the dual needs of rapid transaction processing and deterministic finality, delivering the necessary throughput for global payments and ensuring that confirmed transactions are irreversible. ### [](#block-generation-and-staking) **Block Generation and Staking** Blocks on the Plasma network are produced using a Proof of Stake (PoS) mechanism. Our approach simplifies staking by eliminating punitive measures like stake slashing, meaning validators do not lose staked tokens for misbehavior. We are also exploring staking without lock-up periods, enabling token holders to withdraw their stake immediately if desired. ### [](#consensus-rollout) **Consensus Rollout** The deployment of Plasma’s consensus mechanism will occur in three phases: * **Trusted Validators:** At initial mainnet launch, validation starts with a select group of trusted entities. This controlled phase establishes a stable and secure network and allows for further protocol improvements. * **Expansion and Scalability Testing:** Next, the validator set will be expanded to rigorously test Plasma’s horizontal scalability and performance under larger committees. * **Full Decentralization:** In the final phase, Plasma will transition to a permissionless model where anyone can become a validator, achieving complete decentralization and enhanced network security. [PreviousCore Features](/architecture/core-features) [NextHotStuff](/architecture/consensus/hotstuff) Last updated 1 month ago --- # HotStuff | Plasma Docs Before diving into PlasmaBFT, it's useful to contextualize the consensus landscape. **HotStuff** is a modern BFT consensus protocol that improves upon earlier designs—such as Tendermint—both theoretically and practically, and it serves as an ancestor to PlasmaBFT. A key advantage of HotStuff is its responsiveness; by eliminating fixed timeout delays, a correct leader can drive consensus at the limit of communication latency in synchronous networks, while maintaining linear message complexity relative to the number of replicas. In contrast, other methods often rely on gossip broadcasts of votes during view changes, leading to quadratic communication complexity or worse. HotStuff streamlines consensus by collecting votes from the committee and distributing an aggregated proof, thereby reducing overhead and maintaining both liveness and safety. These proofs, known as **Quorum Certificates (QCs)**, are formed from signatures collected from a quorum of validators. This cryptographic proof serves as evidence that a supermajority of validators supported a given round's proposal. Thanks to the intersection property of quorums, no two nodes can observe an equivalent quorum for two conflicting blocks unless the number of faulty replicas exceeds the consistency bound. While these techniques significantly reduce communication complexity, there are still further improvements possible—such as pipelining and view-change adjustments—that can enhance consensus times even more. [PreviousConsensus](/architecture/consensus) [NextPlasmaBFT](/architecture/consensus/plasmabft) Last updated 1 month ago --- # PlasmaBFT | Plasma Docs [PreviousHotStuff](/architecture/consensus/hotstuff) [NextCommittee Formation](/architecture/consensus/committee-formation) Last updated 1 month ago PlasmaBFT is an efficient and secure implementation of a **Fast HotStuff-style consensus**, written in Rust. It inherits HotStuff’s core design while optimizing for even lower latency by using a two-chain commit in the common case—often referred to as the fast path. This approach demonstrates that HotStuff’s additional third phase is not always necessary, as consensus can frequently be reached in just two rounds. This reduction in communication steps lowers commit latencies while preserving the desirable properties of linearity and responsiveness. Practically, PlasmaBFT finalizes blocks in fewer communication steps when the leader is honest and the network is responsive, while remaining safe against adversarial behavior. It operates under classic BFT security assumptions: n≥3f+1,q\=2f+1,f\=⌊n−13⌋ n \\geq 3f + 1,\\quad q = 2f + 1,\\quad f = \\left\\lfloor \\frac{n - 1}{3} \\right\\rfloor n≥3f+1,q\=2f+1,f\=⌊3n−1​⌋ where _n_ is the number of replicas, _f_ is the number of Byzantine nodes, and _q_ is the required quorum size. This means that **PlasmaBFT remains secure** when no more than 33% of validators are malicious. Our system achieves high throughput—processing many thousands of transactions per second in benchmarks—and serves as an essential foundation for a stablecoin-optimized protocol. We chose Rust for its performance and safety guarantees, ensuring robustness and efficiency even under heavy workloads. We rely on Quorum Certificates (QCs) at every step. In the happy path, when a newly proposed block builds directly on its predecessor, the QCs alone establish correctness while benefiting from the efficiency of signature aggregation. This mechanism also enables rapid finality; once a 2-chain is formed, the block can be immediately finalized as consecutive quorums have certified its correctness. QC(bv)←QC(bv+1)←QC(bv+2)←…QC(b\_{v}) \\leftarrow QC(b\_{v+1}) \\leftarrow QC(b\_{v+2}) \\leftarrow \\dots QC(bv​)←QC(bv+1​)←QC(bv+2​)←… We additionally make use of pipelining to improve throughput. Under pipelining, while the previous round continues through the precommit and commit phases, newer proposals continue in parallel: In the event of a leader failure or view change, **aggregated QCs (AggQCs)** come into play. When a view change occurs, validators forward their most recent QC to the new leader, who then combines these into an AggQC. This process prevents the new leader from equivocating about the highest block observed, effectively certifying the state through an additional layer of aggregation. Importantly, these differ from the threshold signatures used in HotStuff because only two signatures need to be validated under this case. Other approaches, such as Jolteon and Ditto—proposed by Gelashvili et al.—rely on a similar yet slightly different methodology. Instead of relying on AggQCs, these methods use timeout certificates (TCs) to advance the committee by eliminating gaps caused by view changes. ![](https://docs.plasma.to/~gitbook/image?url=https%3A%2F%2F30806345-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FnO2kf3iLnk3p5wnpui1z%252Fuploads%252FMtxtVR85f7Zpi0AvDwkn%252Fpipelining.png%3Falt%3Dmedia%26token%3D9d2487e6-fc60-4165-90c1-2d4d5d49dacc&width=768&dpr=4&quality=100&sign=37135ac7&sv=2) ![](https://docs.plasma.to/~gitbook/image?url=https%3A%2F%2F30806345-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FnO2kf3iLnk3p5wnpui1z%252Fuploads%252Fmz1gCfPJhUaGqstFAl0S%252Fpipeline-dark.png%3Falt%3Dmedia%26token%3D1f03990f-8882-48b3-8729-2bc48fae6aaf&width=768&dpr=4&quality=100&sign=f08497af&sv=2) --- # Committee Formation | Plasma Docs The Committee Formation is under active research and development and subject to change in implementation design. In PlasmaBFT, committee formation is crucial for achieving **consensus at scale**. State replication tends to scale poorly in worst-case scenarios, often degrading to quadratic complexity (or worse). To maintain performance under such conditions, choosing a smaller subset of all possible validators limits the potential communication explosion in these cases. This approach naturally aligns with the message validation required by BFT-based systems. Since every validator in this smaller set—and their corresponding public key—is known, we can efficiently authenticate messages and reveal equivocation. However, using a known, fixed set also implies that nodes cannot easily join or leave the committee on a per-round basis without supporting mechanisms. In Plasma, committee members are chosen using a cryptographically secure random process, weighted by the **Proof of Stake (PoS)** mechanism underlying our validator set. This method not only ensures fairness but also prevents Sybil attacks by limiting voting power to a verifiable, limited resource, thereby hindering attackers from overwhelming the system with a multitude of nodes. ### [](#slashing) Slashing In any Proof of Stake system, the question arises regarding how the system deals with the 'nothing at stake' problem. Since staking requires minimal computational resources, malicious validators can—in theory—explore the space of eligible blocks to find one that satisfies their eligibility above those of their fellow validators. If they do so privately, they can build and maintain a hidden fork that could enable a double-spend. In doing so, an adversary must either reveal a valid block and then later reveal a second, similarly valid but distinct block (double sign) or skip their valid eligibilities to maintain their private chain. The former is easy to detect because it can only result from malicious behavior. The latter, however, is indistinguishable from normal stochastic failures in a dynamic environment. To disincentivize malicious nodes from these types of behaviors, we considered two types of slashing. **Stake slashing**, in which the collateral of the malicious validator is seized or burned, is the most aggressive form of punishment, as even plausibly accidental failure to produce a block can result in a loss of funds. **Reward slashing**, in comparison, is a more passive approach that revokes rewards for a given period from the adversary but does not affect their initial staked collateral. The intuition behind reward slashing relies on the economically rational behavior of the adversary: if their behavior will be detected with high probability, then the marginal probability of the loss of rewards will, over time, trend to a less financially beneficial outcome than simply following the protocol. A key advantage of the latter approach is better alignment with traditional financial systems. While an unexpectedly low return from a yield-bearing product is well-understood by existing legacy models, the sudden evaporation of deposited funds without a corresponding transaction is not. Since Plasma aims to integrate and facilitate with such systems, it is therefore important that our behavior is predictable and compatible in that context. [PreviousPlasmaBFT](/architecture/consensus/plasmabft) [NextReferences](/architecture/consensus/references) Last updated 1 month ago --- # RPC-API | Plasma Docs [PreviousHardware Requirements](/architecture/hardware-requirements) [NextEVM Details](/architecture/evm-details) Last updated 1 month ago When interacting with Plasma, most requests pass directly through the node. Because the node is based on Reth, it follows a fully-compatible structure with Ethereum’s JSON-RPC. For further details on the supported endpoints, please refer to the and the . As in Reth, endpoints can be accessed over HTTP, WebSockets, or IPC. _**Please note:**_ Exposing JSON-RPC endpoints publicly is **not advisable**; properly securing node communications is the responsibility of the node operator. The following namespaces and endpoints are supported: * `**eth**` * `eth_getBlockByNumber` * `eth_blockNumber` * `eth_getBlockReceipts` * `eth_getTransactionByHash` * `eth_sendRawTransaction` * `eth_getTransactionCount` * `eth_getBalance` * `eth_estimateGas` * `eth_gasPrice` * `eth_getLogs` * `eth_getTransactionReceipt` * `**web3**` * `web3_clientVersion` * `web3_sha3` * `**txpool**` * `txpool_content` * `txpool_contentFrom` * `txpool_inspect` * `txpool_status` * `**debug**` * `debug_getRawHeader` * `debug_getRawBlock` * `debug_getRawTransaction` * `debug_getRawReceipts` * `debug_getBadBlocks` * `debug_traceChain` * `debug_traceBlock` * `debug_traceBlockByHash` * `debug_traceBlockByNumber` * `debug_traceTransaction` * `debug_traceCall` * `**trace**` * `trace_call` * `trace_callMany` * `trace_rawTransaction` * `trace_replayBlockTransaction` * `trace_replayTransaction` * `trace_block` * `trace_filter` * `trace_get` * `trace_transaction` * `**rpc**` * `rpc_modules` [Ethereum documentation](https://ethereum.org/en/developers/docs/apis/json-rpc/) [Reth book](https://reth.rs/jsonrpc/intro.html) --- # References | Plasma Docs [PreviousCommittee Formation](/architecture/consensus/committee-formation) [NextExecution](/architecture/execution) Last updated 1 month ago * J. Kwon, “Tendermint: Consensus without mining,” Draft v. 0.6, Fall, vol. 1, no. 11, pp. 1–11, 2014. Available: * D. Malkhi and K. Nayak, “HotStuff-2: Optimal Two-Phase Responsive BFT,” 2023, 2023/397. \[Online\]. Available: * M. M. Jalalzai, J. Niu, C. Feng, and F. Gai, “Fast-HotStuff: A Fast and Robust BFT Protocol for Blockchains,” IEEE Trans. Dependable and Secure Comput., vol. 21, no. 4, pp. 2478–2493, Jul. 2024, doi: 10.1109/TDSC.2023.3308848. . * R. Gelashvili, L. Kokoris-Kogias, A. Sonnino, and Z. Xiang, “Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback,” Financial Cryptography and Data Security, p. 32, 2022. Available: * M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “HotStuff: BFT Consensus with Linearity and Responsiveness,” in Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC ’19, New York, NY, USA, Jul. 2019, pp. 347–356. Available: * S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. Available: * M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” in Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ’99, Berkeley, CA, USA: USENIX Association, 1999, pp. 173–186. \[Online\]. Available: [https://tendermint.com/static/docs/tendermint.pdf](https://tendermint.com/static/docs/tendermint.pdf) [https://eprint.iacr.org/2023/397](https://eprint.iacr.org/2023/397) [Available online](https://www.researchgate.net/profile/Mohammad_Mussadiq_Jalalzai/publication/344828409_Fast-HotStuff_A_Fast_and_Resilient_HotStuff_Protocol/links/61e724eac5e3103375a37c76/Fast-HotStuff-A-Fast-and-Resilient-HotStuff-Protocol.pdf) [https://arxiv.org/pdf/2106.10362](https://arxiv.org/pdf/2106.10362) [https://dl.acm.org/doi/pdf/10.1145/3293611.3331591](https://dl.acm.org/doi/pdf/10.1145/3293611.3331591) [https://bitcoin.org/bitcoin.pdf](https://bitcoin.org/bitcoin.pdf) [https://www.usenix.org/legacy/publications/library/proceedings/osdi99/full\_papers/castro/castro.ps](https://www.usenix.org/legacy/publications/library/proceedings/osdi99/full_papers/castro/castro.ps) --- # Hardware Requirements | Plasma Docs [PreviousBitcoin Bridge](/architecture/bitcoin-bridge) [NextRPC-API](/architecture/rpc-api) Last updated 1 month ago The following requirements pertain specifically to the PlasmaBFT consensus layer. Plasma’s node software is implemented in Rust, keeping hardware requirements low. The expected requirements for a validator node running PlasmaBFT are roughly equivalent to an AWS c6a.large instance: * **2 CPU cores** * **4 GB RAM** * **SSD-based persistent storage** Low-latency connectivity is crucial for optimal consensus and transaction propagation. Deployment is straightforward via containerization (e.g., Docker, Helm) or direct source compilation, making participation accessible while maintaining network resilience. Note that, while not required, validator nodes typically will also run other supporting packages such as Reth and Bitcoin. For details on hardware requirements for the Reth execution client and Bitcoin components, please refer to the respective documentation: In a fully-equipped validator running all packages, we suggest the following hardware specifications: * **4+ CPU cores** * **16+ GB RAM** * **8+ TB NVMe SSD** [Reth Hardware Requirements](https://reth.rs/installation/installation.html) [Bitcoin Node Hardware Guidelines](https://bitcoin.org/en/bitcoin-core/features/requirements) --- # Bitcoin Bridge | Plasma Docs The Bitcoin bridge and settlement are under active research and development and subject to change in implementation design. They will not be live for the initial Plasma mainnet beta launch but are planned for future upgrades. Plasma’s native Bitcoin interoperability enables secure, direct integration between Plasma and Bitcoin. This design allows users to safely transfer and manage Bitcoin within the Plasma ecosystem, enhancing liquidity and cross-chain functionality. In the evolving landscape of Bitcoin bridges, various models have emerged. Some rely entirely on centralized custodians, while others use a whitelisted federation of operators based on an honest majority assumption. Plasma distinguishes itself by securing its bridge through a **decentralized, permissionless set of validators**—the same validators that secure the Plasma consensus. This approach minimizes single points of failure and reduces trust assumptions to those inherent in existing models. Alternative trust-minimized bridge designs, such as BitVM, have been spearheaded by teams like Alpen Labs and Citrea. Their innovative work, along with potential opcode developments in Bitcoin Core—most notably a potential OP\_CAT opcode—showcases unique trust assumptions and paves the way for further advancements. As BitVM continues to progress and becomes more battle-tested in production, Plasma is well-positioned to **upgrade its bridge design** in the future, further minimizing trust assumptions. We continuously monitor these advancements and remain open to integrating emerging cryptographic innovations, such as zero-knowledge proof techniques, to further enhance our trust minimization. [](#plasma-native-bitcoin-bridge) Plasma Native Bitcoin Bridge ------------------------------------------------------------------- ### [](#bitcoin-synchronization) **Bitcoin Synchronization** Validator nodes can optionally run a fully synchronized Bitcoin client alongside their Plasma software. This setup not only provides a real-time view of Bitcoin’s global state but also reinforces Bitcoin’s decentralized ethos by increasing the overall number of Bitcoin nodes in the ecosystem. Greater participation enhances both responsiveness and security, as validators independently track and verify Bitcoin’s state. ### [](#utxo-merkle-anchoring) **UTXO Merkle Anchoring** Each participating validator constructs a cryptographic summary of Bitcoin’s Unspent Transaction Output (UTXO) set using a Merkle tree. The latest Merkle root is embedded in every Plasma block header, and validators recalculate and verify this root against their local Bitcoin state before finalizing a block. This process ensures the accuracy and consistency of the integrated Bitcoin data. Notably, this mechanism facilitates **efficient proof verification** for lightweight clients, supporting transparent and trustless state reconstruction. ### [](#bitcoin-bridge-operations) **Bitcoin Bridge Operations** Plasma’s native Bitcoin bridge enables seamless asset transfers between chains via a secure two-phase process: * **Asset Locking:** Users transfer Bitcoin to a Plasma-controlled bridging address, locking their funds on the Bitcoin blockchain. Validators detect this transaction through their synchronized Bitcoin client and mint equivalent tokens on Plasma. * **Redemption:** To redeem tokens, users submit a request on Plasma. Validators then collectively sign the transaction using threshold Schnorr signatures (leveraging Bitcoin’s Taproot upgrade) and broadcast it to Bitcoin, releasing funds back to the user’s Bitcoin wallet. The trust assumption for these operations is ⅔ majority-based: a decentralized validator set must reach consensus before any Bitcoin-related action is executed, ensuring that no single validator or small group can unilaterally compromise the bridge. ### [](#settlement-on-bitcoin) **Settlement on Bitcoin** To further enhance security and provide an immutable record, Plasma periodically commits its state differences to Bitcoin. During each designated settlement cycle, a cryptographic summary of the Plasma state diff is anchored on the Bitcoin blockchain via an **inscription-like envelope**. This settlement process captures the complete state transition up to that point, ensuring that the latest state is publicly verifiable. By anchoring state summaries on Bitcoin, we leverage Bitcoin’s decentralized security model to provide an independent audit trail that is highly resistant to tampering and chain reorganizations. Our approach not only ensures that each Plasma state transition is secure and transparent but also lays a solid foundation for future enhancements as we explore advanced cryptographic techniques to further improve settlement efficiency and minimize trust requirements. [PreviousExecution](/architecture/execution) [NextHardware Requirements](/architecture/hardware-requirements) Last updated 1 month ago --- # Execution | Plasma Docs Plasma features a **general-purpose EVM** as its core execution environment—a critical choice given that over 90% of stablecoin infrastructure and applications are built on the EVM. Full EVM compatibility was deliberately selected to allow developers to seamlessly deploy existing smart contracts and leverage the extensive tooling available in the wider EVM ecosystem. Our execution layer is built on **Reth**, a high-performance, modular, Ethereum-compatible execution engine written in Rust. Plasma introduces several performance and usability enhancements at the execution layer while remaining fully compliant with the EVM specification. In practical terms, any smart contract deployable on Ethereum can be deployed on Plasma without requiring any code modifications. [PreviousReferences](/architecture/consensus/references) [NextBitcoin Bridge](/architecture/bitcoin-bridge) Last updated 1 month ago --- # EVM Details | Plasma Docs Plasma’s design closely mirrors Ethereum’s standards to ensure seamless compatibility. Key points include: * **EVM**: Plasma supports the same smart contract languages that are supported by Ethereum. If it runs on Ethereum, then it runs on Plasma. * **Accounts:** Plasma uses the same account model as Ethereum, so existing wallets and tools work out-of-the-box. * **Transaction Format:** Plasma supports Ethereum’s transaction formats, including both dynamic fee (EIP-1559-style) and legacy types. * **Transaction Lifecycle:** The process—from creation and submission to verification, block production, and finalization—follows Ethereum’s established patterns, ensuring compatibility with existing infrastructure. This alignment with Ethereum’s standards makes transitioning to Plasma straightforward for both developers and users. [PreviousRPC-API](/architecture/rpc-api) [NextOfficial Links](/community/official-links) Last updated 1 month ago --- # Official Links | Plasma Docs [PreviousEVM Details](/architecture/evm-details) Last updated 1 month ago * Website: * X/Twitter: * Discord: [https://www.plasma.to/](https://www.plasma.to/) [https://x.com/PlasmaFDN](https://x.com/PlasmaFDN) [https://discord.com/invite/plasmafdn](https://discord.com/invite/plasmafdn) ---