# RISE Documentation (/docs)
import { Rocket, Globe, Wallet, ArrowLeftRight, Layers, Dices, Clock, GitFork } from 'lucide-react';
RISE is an Ethereum Layer 2 blockchain delivering near-instant transactions at unprecedented scale with sub-3ms latency and 100,000+ TPS capacity, all secured by Ethereum.
Built for CEX-grade performance and full EVM composability, RISE enables builders, traders, and institutions to create and connect to global orderbooks alongside a thriving DeFi ecosystem with ease.
## Explore
} title="Network Details" href="/docs/builders/network-details" description="RPC, Chain ID, and explorer info" />
} title="Builder Quickstart" href="/docs/builders/quick-start" description="Start building on RISE" />
} title="Parallel EVM" href="/docs/rise-evm/pevm" description="The ultimate parallel EVM execution engine" />
} title="RISE Wallet" href="/docs/rise-wallet" description="Gas sponsored, passkey compatible wallet integration" />
} title="RISEx" href="/docs/risex" description="RISE's native decentralized exchange" />
} title="Shreds" href="/docs/builders/shreds" description="RISE's mini-block like structures" />
} title="VRF" href="/docs/builders/vrf" description="Verifiable randomness on RISE" />
## AI & LLM Access
These docs are optimized for AI consumption. You can access the content in machine-readable formats:
* **Full documentation**: [/llms-full.txt](/llms-full.txt) - All docs in a single text file
* **Individual pages**: Append `.mdx` to any page URL (e.g., `/docs/get-started/rise.mdx`) to get the raw markdown
This makes it easy to feed RISE documentation into AI assistants like ChatGPT, Claude, or other LLMs.
## Community
Join our growing community to stay updated and engage with the RISE ecosystem:
* [Discord](https://discord.gg/risechain)
* [Twitter](https://x.com/risechain)
* [GitHub](https://github.com/risechain)
# Mermaid Test (/docs/test-mermaid)
# Mermaid Diagram Test
This page demonstrates Mermaid diagram rendering.
## State Diagram
Here's your state diagram from the image:
## Flow Chart
## Sequence Diagram
## Gantt Chart
# Components (/docs/test)
## Code Block
```js
console.log('Hello World');
```
## Cards
# Contract Addresses (/docs/builders/contract-addresses)
This page provides a reference for all contract addresses on RISE Testnet.
## Pre-deployed Contracts
These contracts are pre-deployed and available from genesis.
| Contract Name | Description | Address |
| ---------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Create2Deployer | Helper for CREATE2 opcode usage | [`0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2`](https://explorer.testnet.riselabs.xyz/address/0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2) |
| DeterministicDeploymentProxy | Integrated with Foundry for deterministic deployments | [`0x4e59b44847b379578588920ca78fbf26c0b4956c`](https://explorer.testnet.riselabs.xyz/address/0x4e59b44847b379578588920ca78fbf26c0b4956c) |
| MultiCall3 | Allows bundling multiple transactions | [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://explorer.testnet.riselabs.xyz/address/0xcA11bde05977b3631167028862bE2a173976CA11) |
| GnosisSafe (v1.3.0) | Multisignature wallet | [`0x69f4D1788e39c87893C980c06EdF4b7f686e2938`](https://explorer.testnet.riselabs.xyz/address/0x69f4D1788e39c87893C980c06EdF4b7f686e2938) |
| GnosisSafeL2 (v1.3.0) | Events-based implementation of GnosisSafe | [`0xfb1bffC9d739B8D520DaF37dF666da4C687191EA`](https://explorer.testnet.riselabs.xyz/address/0xfb1bffC9d739B8D520DaF37dF666da4C687191EA) |
| MultiSendCallOnly (v1.3.0) | Batches multiple transactions (calls only) | [`0xA1dabEF33b3B82c7814B6D82A79e50F4AC44102B`](https://explorer.testnet.riselabs.xyz/address/0xA1dabEF33b3B82c7814B6D82A79e50F4AC44102B) |
| MultiSend (v1.3.0) | Batches multiple transactions | [`0x998739BFdAAdde7C933B942a68053933098f9EDa`](https://explorer.testnet.riselabs.xyz/address/0x998739BFdAAdde7C933B942a68053933098f9EDa) |
| Permit2 | Next-generation token approval system | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://explorer.testnet.riselabs.xyz/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
| EntryPoint (v0.7.0) | ERC-4337 entry point for account abstraction | [`0x0000000071727De22E5E9d8BAf0edAc6f37da032`](https://explorer.testnet.riselabs.xyz/address/0x0000000071727De22E5E9d8BAf0edAc6f37da032) |
| SenderCreator (v0.7.0) | Helper for EntryPoint | [`0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C`](https://explorer.testnet.riselabs.xyz/address/0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C) |
| WETH | Wrapped ETH | [`0x4200000000000000000000000000000000000006`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000006) |
## L1 (Sepolia) System Contracts
These contracts are deployed on the Sepolia Ethereum testnet and handle the communication between L1 and RISE Testnet.
| Contract Name | Description | Address |
| --------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AnchorStateRegistryProxy | Stores state roots of the L2 chain | [`0x5ca4bfe196aa3a1ed9f8522f224ec5a7a7277d5a`](https://sepolia.etherscan.io/address/0x5ca4bfe196aa3a1ed9f8522f224ec5a7a7277d5a) |
| BatchSubmitter | Submits batches of transactions | [`0x45Bd8Bc15FfC21315F8a1e3cdF67c73b487768e8`](https://sepolia.etherscan.io/address/0x45Bd8Bc15FfC21315F8a1e3cdF67c73b487768e8) |
| Challenger | Handles challenges to invalid state transitions | [`0xb49077bAd82968A1119B9e717DBCFb9303E91f0F`](https://sepolia.etherscan.io/address/0xb49077bAd82968A1119B9e717DBCFb9303E91f0F) |
| DelayedWETHProxy | Wrapped ETH with withdrawal delay | [`0x3547e7b4af6f0a2d626c72fd7066b939e8489450`](https://sepolia.etherscan.io/address/0x3547e7b4af6f0a2d626c72fd7066b939e8489450) |
| DisputeGameFactoryProxy | Creates dispute games for challenging invalid state | [`0x790e18c477bfb49c784ca0aed244648166a5022b`](https://sepolia.etherscan.io/address/0x790e18c477bfb49c784ca0aed244648166a5022b) |
| L1CrossDomainMessengerProxy | Handles message passing from L1 to L2 | [`0xcc1c4f905d0199419719f3c3210f43bb990953fc`](https://sepolia.etherscan.io/address/0xcc1c4f905d0199419719f3c3210f43bb990953fc) |
| L1ERC721BridgeProxy | Bridge for NFTs between L1 and L2 | [`0xfc197687ac16218bad8589420978f40097c42a44`](https://sepolia.etherscan.io/address/0xfc197687ac16218bad8589420978f40097c42a44) |
| L1StandardBridgeProxy | Bridge for ETH and ERC20 tokens | [`0xe9a531a5d7253c9823c74af155d22fe14568b610`](https://sepolia.etherscan.io/address/0xe9a531a5d7253c9823c74af155d22fe14568b610) |
| MIPS | MIPS verification for fault proofs | [`0xaa33f21ada0dc6c40a33d94935de11a0b754fec4`](https://sepolia.etherscan.io/address/0xaa33f21ada0dc6c40a33d94935de11a0b754fec4) |
| OptimismMintableERC20FactoryProxy | Factory for creating bridged tokens on L2 | [`0xb9b92645886135838abd71a1bbf55e34260dabf6`](https://sepolia.etherscan.io/address/0xb9b92645886135838abd71a1bbf55e34260dabf6) |
| OptimismPortalProxy | Main entry point for L1 to L2 transactions | [`0x77cce5cd26c75140c35c38104d0c655c7a786acb`](https://sepolia.etherscan.io/address/0x77cce5cd26c75140c35c38104d0c655c7a786acb) |
| PreimageOracle | Stores preimages for fault proofs | [`0xca8f0068cd4894e1c972701ce8da7f934444717d`](https://sepolia.etherscan.io/address/0xca8f0068cd4894e1c972701ce8da7f934444717d) |
| Proposer | Proposes new L2 state roots | [`0x407379B3eBd88B4E92F8fF8930D244B592D65c06`](https://sepolia.etherscan.io/address/0x407379B3eBd88B4E92F8fF8930D244B592D65c06) |
| SystemConfigProxy | Configuration for the RISE system | [`0x5088a091bd20343787c5afc95aa002d13d9f3535`](https://sepolia.etherscan.io/address/0x5088a091bd20343787c5afc95aa002d13d9f3535) |
| UnsafeBlockSigner | Signs blocks in development mode | [`0x8d451372bAdE8723F45BF5134550017F639dFb11`](https://sepolia.etherscan.io/address/0x8d451372bAdE8723F45BF5134550017F639dFb11) |
## L2 (RISE Testnet) System Contracts
These are the predeploy contracts on RISE Testnet.
| Contract Name | Description | Address |
| ----------------------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| L2ToL1MessagePasser | Initiates withdrawals to L1 | [`0x4200000000000000000000000000000000000016`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000016) |
| L2CrossDomainMessenger | Handles message passing from L2 to L1 | [`0x4200000000000000000000000000000000000007`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000007) |
| L2StandardBridge | L2 side of the token bridge | [`0x4200000000000000000000000000000000000010`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000010) |
| L2ERC721Bridge | L2 side of the NFT bridge | [`0x4200000000000000000000000000000000000014`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000014) |
| SequencerFeeVault | Collects sequencer fees | [`0x4200000000000000000000000000000000000011`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000011) |
| OptimismMintableERC20Factory | Creates standard bridged tokens | [`0x4200000000000000000000000000000000000012`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000012) |
| OptimismMintableERC721Factory | Creates bridged NFTs | [`0x4200000000000000000000000000000000000017`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000017) |
| L1Block | Provides L1 block information | [`0x4200000000000000000000000000000000000015`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000015) |
| GasPriceOracle | Provides gas price information | [`0x420000000000000000000000000000000000000F`](https://explorer.testnet.riselabs.xyz/address/0x420000000000000000000000000000000000000F) |
| ProxyAdmin | Admin for proxy contracts | [`0x4200000000000000000000000000000000000018`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000018) |
| BaseFeeVault | Collects base fee | [`0x4200000000000000000000000000000000000019`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000019) |
| L1FeeVault | Collects L1 data fees | [`0x420000000000000000000000000000000000001A`](https://explorer.testnet.riselabs.xyz/address/0x420000000000000000000000000000000000001A) |
| GovernanceToken | RISE governance token | [`0x4200000000000000000000000000000000000042`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000042) |
| SchemaRegistry | EAS schema registry | [`0x4200000000000000000000000000000000000020`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000020) |
| EAS | Ethereum Attestation Service | [`0x4200000000000000000000000000000000000021`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000021) |
## Usage Examples
### Bridging ETH from L1 to L2
```solidity
// On Sepolia (L1)
IL1StandardBridge bridge = IL1StandardBridge(0xe9a531a5d7253c9823c74af155d22fe14568b610);
// Deposit ETH to L2
bridge.depositETH{value: amount}(
minGasLimit,
emptyBytes // No additional data
);
```
### Sending a Message from L2 to L1
```solidity
// On RISE Testnet (L2)
IL2CrossDomainMessenger messenger = IL2CrossDomainMessenger(0x4200000000000000000000000000000000000007);
// Send message to L1
messenger.sendMessage(
targetL1Address,
abi.encodeWithSignature("someFunction(uint256)", value),
minGasLimit
);
```
# Build on RISE (/docs/builders)
import { Card, Cards } from 'fumadocs-ui/components/card';
import { Zap, Globe, Wallet, Layers, Dices } from 'lucide-react';
## Why Build on RISE?
RISE is built for builders who demand speed, precision, and zero compromise. Offering the fastest execution and lowest latency available today, RISE empowers developers to create high-performance applications—from CLOBs and actively managed strategies to DePIN and fully onchain gaming. If your users can't wait, build on RISE.
* **Blazing Performance**: Over 100,000 transactions per second unlocks massive scalability for next-gen dApps
* **Instant Confirmations**: 10ms end-to-end confirmations ensure your applications respond in realtime, even under heavy load
* **Ultra-Low Fees**: Optimized for minimal gas costs, making high-frequency and high-volume activity sustainable
* **Seamless Development**: Complete EVM compatibility means you can build fast, deploy instantly, and scale without friction
## Getting Started
} title="Quick Start" href="/docs/builders/quick-start" description="Deploy your first contract" />
} title="Network Details" href="/docs/builders/network-details" description="Connect to RISE and configure your dev environment" />
### Tools
} title="RISE Wallet" href="/docs/rise-wallet" description="Gasless transactions with passkey authentication" />
} title="Shreds" href="/docs/builders/shreds" description="Realtime 3ms transaction confirmations" />
} title="Fast VRF" href="/docs/builders/vrf" description="Verifiable randomness for gaming and more" />
## Connect with Builders
Join the RISE Developer Community. Connect with other builders, share ideas, get technical support, and collaborate on projects.
} title="Builder Discord" href="https://discord.com/invite/qhKnePXdSM" description="Connect with other builders and get support" />
# Internal Oracles (/docs/builders/internal-oracles)
Internal price oracles deployed on RISE Testnet.
## Oracle Addresses
| Ticker | Address |
| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ETH | [`0x7114E2537851e727678DE5a96C8eE5d0Ca14f03D`](https://explorer.testnet.riselabs.xyz/address/0x7114E2537851e727678DE5a96C8eE5d0Ca14f03D) |
| USDC | [`0x50524C5bDa18aE25C600a8b81449B9CeAeB50471`](https://explorer.testnet.riselabs.xyz/address/0x50524C5bDa18aE25C600a8b81449B9CeAeB50471) |
| USDT | [`0x9190159b1bb78482Dca6EBaDf03ab744de0c0197`](https://explorer.testnet.riselabs.xyz/address/0x9190159b1bb78482Dca6EBaDf03ab744de0c0197) |
| BTC | [`0xadDAEd879D549E5DBfaf3e35470C20D8C50fDed0`](https://explorer.testnet.riselabs.xyz/address/0xadDAEd879D549E5DBfaf3e35470C20D8C50fDed0) |
## Usage
The oracle price for each asset can be fetched by calling the `latest_answer` function on the respective oracle address.
```solidity
interface IPriceOracle {
function latest_answer() external view returns (int256);
}
// Example: Get ETH price
IPriceOracle ethOracle = IPriceOracle(0x7114E2537851e727678DE5a96C8eE5d0Ca14f03D);
int256 ethPrice = ethOracle.latest_answer();
```
# Network Details (/docs/builders/network-details)
Use the information below to connect and submit transactions to RISE.
| Property | Testnet |
| --------------- | --------------------------------------- |
| Network Name | RISE Testnet |
| Chain ID | `11155931` |
| RPC URL | `https://testnet.riselabs.xyz` |
| Explorer | `https://explorer.testnet.riselabs.xyz` |
| Currency Symbol | ETH |
## Using with Development Tools
### Hardhat Configuration
```javascript
// hardhat.config.js
module.exports = {
networks: {
riseTestnet: {
url: "https://testnet.riselabs.xyz",
chainId: 11155931,
accounts: process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : []
}
}
};
```
### Foundry Configuration
```toml
# foundry.toml
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
[rpc_endpoints]
rise_testnet = "https://testnet.riselabs.xyz"
[blockscout]
rise_testnet = { key = "", url = "https://explorer.testnet.riselabs.xyz/api" }
```
## Gas & Transaction Details
| Property | Value |
| ----------------------------- | ------------------ |
| Max Gas Limit per Transaction | 16M |
| Nonce Order | Enforced on-chain |
| Data Storage Fees | Same as L1 |
| Blocks to Finality | 259,200 (\~3 days) |
## Getting Testnet ETH
} title="RISE Faucet" href="https://faucet.testnet.riselabs.xyz" description="Get free testnet ETH and other tokens for testing" />
# Quick Start (/docs/builders/quick-start)
RISE is fully EVM compatible. You can use your existing Ethereum development tools and workflows with minimal configuration changes.
## Smart Contracts
Learn how to create a new smart contract project, compile your contracts, and deploy them to RISE.
} title="Remix IDE" href="/docs/builders/smart-contracts/remix" description="Deploy contracts on RISE using Remix IDE" />
} title="Hardhat" href="/docs/builders/smart-contracts/hardhat" description="Set up Hardhat for smart contract development on RISE" />
} title="Foundry" href="/docs/builders/smart-contracts/foundry" description="Set up Foundry for smart contract development on RISE" />
## Applications
Learn how to build frontend applications to interact with smart contracts on RISE.
} title="Viem" href="/docs/builders/frontend/viem" description="Build apps using Viem" />
} title="Ethers.js" href="/docs/builders/frontend/ethers" description="Build apps using Ethers.js" />
# RISE Wallet Stack (/docs/builders/rise-wallet)
import { Card, Cards } from 'fumadocs-ui/components/card';
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
import { Zap, Key, Code, BookOpen } from 'lucide-react';
RISE Wallet is a chain-native wallet layer that provides gasless transactions, passkey authentication, and session keys for your dApp. Built on audited smart accounts from Porto and integrated directly into RISE's infrastructure.
## Key Features
* **Gasless by Default**: Users don't need ETH to start using your app
* **Passkey Authentication**: No seed phrases - just biometrics (FaceID, TouchID)
* **Session Keys**: Enable high-frequency interactions without popups
* **3ms Confirmations**: Leverages RISE's shred architecture for instant feedback
## Quick Integration
```bash
npm i rise-wallet wagmi viem
```
```bash
pnpm add rise-wallet wagmi viem
```
```bash
yarn add rise-wallet wagmi viem
```
```bash
bun add rise-wallet wagmi viem
```
```tsx
import { Chains, RiseWallet } from "rise-wallet";
import { riseWallet } from "rise-wallet/wagmi";
export const rwConnector = riseWallet(RiseWallet.defaultConfig);
```
## Learn More
} title="Overview" href="/docs/rise-wallet" description="Introduction to RISE Wallet features and benefits" />
} title="Getting Started" href="/docs/rise-wallet/minting" description="Interactive tutorials for common use cases" />
} title="Session Keys" href="/docs/rise-wallet/session-keys" description="Build popup-free experiences" />
} title="Integration Guides" href="/docs/rise-wallet/wagmi" description="Framework-specific documentation" />
# Testnet Tokens (/docs/builders/testnet-tokens)
ERC20 tokens deployed on RISE Testnet (Chain ID: 11155931).
These tokens have been minted purely for testing purposes. They hold no value.
You can acquire tokens via the faucet on the [Testnet Portal](https://portal.risechain.com).
## Token Addresses
| Name | Symbol | Decimals | Address |
| --------------- | ------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Wrapped ETH | WETH | 18 | [`0x4200000000000000000000000000000000000006`](https://explorer.testnet.riselabs.xyz/address/0x4200000000000000000000000000000000000006) |
| USD Coin | USDC | 6 | [`0x8a93d247134d91e0de6f96547cb0204e5be8e5d8`](https://explorer.testnet.riselabs.xyz/address/0x8a93d247134d91e0de6f96547cb0204e5be8e5d8) |
| Tether USD | USDT | 8 | [`0x40918ba7f132e0acba2ce4de4c4baf9bd2d7d849`](https://explorer.testnet.riselabs.xyz/address/0x40918ba7f132e0acba2ce4de4c4baf9bd2d7d849) |
| Wrapped Bitcoin | WBTC | 18 | [`0xf32d39ff9f6aa7a7a64d7a4f00a54826ef791a55`](https://explorer.testnet.riselabs.xyz/address/0xf32d39ff9f6aa7a7a64d7a4f00a54826ef791a55) |
| RISE | RISE | 18 | [`0xd6e1afe5ca8d00a2efc01b89997abe2de47fdfaf`](https://explorer.testnet.riselabs.xyz/address/0xd6e1afe5ca8d00a2efc01b89997abe2de47fdfaf) |
| Mog Coin | MOG | 18 | [`0x99dbe4aea58e518c50a1c04ae9b48c9f6354612f`](https://explorer.testnet.riselabs.xyz/address/0x99dbe4aea58e518c50a1c04ae9b48c9f6354612f) |
| Pepe | PEPE | 18 | [`0x6f6f570f45833e249e27022648a26f4076f48f78`](https://explorer.testnet.riselabs.xyz/address/0x6f6f570f45833e249e27022648a26f4076f48f78) |
## Contract Features
All tokens implement:
* ERC20 standard functionality (transfer, approve, transferFrom)
* Custom decimals support (6 to 18)
* Minting capability (restricted to owner)
* Burning capability (anyone can burn their own tokens)
### WETH
The WETH token at `0x4200000000000000000000000000000000000006` is a predeploy contract with additional functionality:
* Wrap ETH by sending ETH to the contract or calling `deposit()`
* Unwrap WETH by calling `withdraw(uint)`
* Standard ERC20 interface for wrapped ETH
## Example Commands
```bash
# Check token balance
cast call "balanceOf(address)(uint256)" --rpc-url https://testnet.riselabs.xyz
# Transfer tokens
cast send "transfer(address,uint256)(bool)" --private-key $PRIVATE_KEY --rpc-url https://testnet.riselabs.xyz
# Wrap ETH
cast send 0x4200000000000000000000000000000000000006 "deposit()" --value --private-key $PRIVATE_KEY --rpc-url https://testnet.riselabs.xyz
# Unwrap WETH
cast send 0x4200000000000000000000000000000000000006 "withdraw(uint256)" --private-key $PRIVATE_KEY --rpc-url https://testnet.riselabs.xyz
```
# Based Sequencing (/docs/rise-evm/based-sequencing)
# Based Sequencing
## The Sequencer Problem
At the core of every rollup is the sequencer, a critical entity that manages transaction flow on the rollup, ensuring efficient and secure interaction with L1.
The sequencer fetches and orders incoming transactions from the mempool into blocks (similar to block proposers in regular blockchains). It also creates L2 checkpoints by posting the latest state commitment to L1. It acts as an intermediary between the L2 and L1, performing the following functions.
* **Ordering.** The sequencer receives transactions from users on the L2, orders them, and includes them in blocks.
* **Execution.** The sequencer executes the transactions and updates the state of the rollup.
* **Batching.** The sequencer groups transactions into batches, compresses the data, and submits these batches to Ethereum.
* **Preconfirmation**. The sequencer advertises an RPC endpoint for users to submit transactions to. As a response, the sequencer issues soft confirmations on user transactions.
### Centralization Risks
Traditional rollups favor centralized sequencers because they offer high performance on dedicated hardware, low latency for better user experience. Low latency is crucial for applications that require quick transaction confirmations, such as perpetual exchanges or lending platforms. Last but not least, a rollup with centralized sequencers is simple to implement, mainly because no consensus is required.
However, a centralized sequencer becomes a **single point of failure**, making the entire rollup vulnerable to technical failures, attacks, or manipulations. A centralized sequencer has the absolute power to censor transactions, reorder transactions to favor their own interests, go offline and halt the rollup entirely, or extract bad MEV from users. This raises concerns about censorship resistance. If they refuse to process certain types of transactions, perhaps due to regulatory pressure or self-interest, users may find themselves unable to execute essential operations within the ecosystem. The impact of censorship undermines the fundamental principles of a permissionless network.
***
## Based Sequencing: Leveraging Ethereum's Security
[Based sequencing](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) removes the centralized sequencer entirely. Instead, L1 block proposers, the same entities responsible for building Ethereum blocks, serve as sequencers for the rollup.
### The Philosophy
Rather than building a separate L2 consensus mechanism, RISE leverages Ethereum's existing, battle-tested block building pipeline. RISE inherits Ethereum proven liveness and censorship resistance properties backed by around 1M+ validators with no additional consensus layer.
### How It Works
Users submit transactions to the current L1 proposer. The L1 proposer orders these transactions alongside regular L1 transactions. The rollup's execution node processes these transactions off-chain and generates a new state commitment.
## Based Preconfirmations
While based sequencing solves centralization, it introduces a new problem: **latency**. Users must wait for L1 blocks to be included (typically 12 seconds) before seeing transaction confirmation, even though the sequencer is already part of L1. This is not wanted in a rollup as users are familiar with fast confirmations given by centralized sequencers.
RISE solves this with **based preconfirmations**: cryptographically enforced promises from Ethereum proposers that certain events will happen in upcoming blocks.
### What Are Preconfirmations?
A **preconfirmation** (or **preconf**) is a collateral-backed promise by the current proposer (or a **gateway**, whomever the proposer delegates to) that certain events will happen at a specific future timestamp.
The fundamental shift is moving from **trust-based systems** to **a more trustless and cryptographically enforced system**. Instead of trusting a centralized sequencer, RISE uses Ethereum-enforced slashing mechanisms, and collateral requirements to reduce transaction latency from 12 seconds to milliseconds while maintaining security guarantees.
### Gateway
Issuing preconfs adds many requirements to L1 proposers. To mitigate this sophistication, in our design, we assume the proposer delegates sequencing right to a sophisticated entity called a gateway (*a.k.a* a **preconfer**). Gateways function as intermediaries connecting Ethereum's block-building market to the L2. They serve as sequencers while providing L1-secured preconfs to users. Unlike traditional sequencers, gateways face slashing penalties for not honoring preconfs.
The delegation is somewhat similar to how most proposers today delegate their block building tasks to builders. The delegation of preconf rights can occur through on-chain or off-chain mechanisms. We consider the off-chain approach (i.e, via the existing PBS pipeline) in this design.
#### Registration and Collateral
A registry contract is deployed for any L1 validators to sign up to become a sequencer for the RISE rollup. Upon registration, L1 validators also need to stake some collateral. This collateral requirement ensures that L1 validators are economically discouraged to misbehave as this will result in their collateral being slashed.
#### Slashing
The system penalizes two categories of violations: **liveness faults** (when preconfs were not included and the proposer's slot was missed) and **safety faults** (when preconfs were not included despite the proposer's slot being available). Both trigger slashing events that penalize the misbehaving validator's collateral.
#### Gateway Delegation and PBS Integration
Proposers delegate sequencing rights to gateways through existing PBS (Proposer-Builder Separation) pipelines. This architecture mirrors builder relationships in current Ethereum MEV workflows, ensuring compatibility with the existing block-building ecosystem.
#### Batch Processing with Shreds
Preconfs are issued in batches using [shreds](/docs/rise-evm/shreds). Batch preconfs inherently align with the operational efficiency of rollups, which are designed to process transactions in bulk. By issuing a single preconf for multiple transactions, rollups can potentially achieve lower overhead per transaction compared to providing individual preconf for each user. Shreds are currently variable in time to balance between throughput and latency.
### Preconf Propagation
When users submit transactions, they send them to any node, which forwards them to the current gateway. The gateway orders these transactions into a shred, executes the shred, and broadcasts the resulting shred through the P2P network. This design ensures that preconfs are visible across the network in near realtime, giving users and applications strong assurance that their transactions will be included/executed. More details about shred propagation can be found [here](/docs/rise-evm/shreds#block-propagation).
### Fallback Gateway Mechanism
To maintain liveness and availability, RISE employs a fallback gateway mechanism. This ensures the network continues functioning during gateway unavailability and addresses two critical scenarios:
* **Cold-start problem**. In the early state of Phase 3 (see below), there might be only a few L1 validators opted into sequencing, creating gaps between preconf slots. A fallback gateway ensures continuous sequencing availability during this transition period.
* **Liveness failures**. When an active gateway experiences operational issues that prevent rollup progression, a fallback sequencer steps in immediately rather than waiting for the full sequencing window to expire. The system monitors the maximum duration between consecutive state commitments. If no L2 state commitment is published within this period, the next gateway in rotation can take over immediately.
This approach balances safety during early phases with the decentralization goals of the long-term vision, ensuring users always have confirmed transactions while progressively removing central dependencies.
***
## Implementation Roadmap
RISE implements based sequencing in three phases, progressively decentralizing the network while maintaining operational maturity throughout the transition.
### Phase 1: The Taste
The initial phase extends the current RISE sequencer to incorporate gateway functionalities. This phase proves that the gateway architecture works in practice and validates all necessary components before broader adoption.
Key activities include implementing L1 interactions (slashing and delegation mechanisms), issuing L1-secured execution preconfs as shreds, testing gateway component maturity and reliability, and validating software stability under production conditions.
By the end of this phase, a single gateway provides fast, L1-secured preconfs to users, slashing and delegation mechanisms are battle-tested, the system proves capable of handling transaction volume and latency requirements, and infrastructure is ready for decentralized participation.
### Phase 2: The Aligning
This phase serves as a transitional phase before full permissionlessness. Multiple whitelisted gateways operate in a **round-robin rotation system**. RISE will remain in this phase long enough to ensure everything works correctly, the system is robust, and operational processes are mature before moving to full permissionlessness. During this phase, a default gateway (operated by RISE) serves as a fallback gateway to ensure the rollup's liveness.
#### How Rotating Works
Multiple gateways take turns to sequence the rollup. Each gateway operates during a fixed sequencing window (measured in L1 blocks) before handing off to the next gateway. Gateways rotate sequencing duties with each receiving equal opportunity to sequence during its window. The selection mechanism is fully deterministic and transparent on-chain: anyone can identify the current and next gateway using a deterministic formula derived from the L1 Registry contract.
#### Efficient Handover
The system ensures smooth handover through two mechanisms.
* **Shred streaming** provides realtime block segments that deliver near-instantaneous state updates between gateways.
* **Mempool synchronization** maintains a direct communication channel between current and the next gateways so they have consistent transaction pool views, allowing the next gateway to pre-process transactions not yet processed by the current gateway for instantaneous handover.
#### Enhanced Liveness and Censorship Resistance
This phase enhances the rollup's robustness in several ways. Multiple whitelisted but independent gateways share sequencing duties for decentralization, backup gateways prevent downtime if the current gateway goes offline, no single entity controls transaction ordering for censorship resistance, and the system survives individual gateway failures through redundancy. Rotation prevents any single entity from dominating block building over time, building long-term censorship capabilities.
### Phase 3: The Basedening
The final phase removes gateway whitelisting entirely for full permissionless participation. Any Ethereum validator can become a gateway by delegating block-building rights through collateral staking. Gateways compete freely for users and transaction ordering, economic incentives align as validators earn fee portions for including rollup transactions. The economic incentives are straightforward: when proposers propose blocks, they include rollup transactions and receive fee revenue as compensation for sequencing.
By this phase, rollup decentralization grows with Ethereum's validator set, no single entity can have full control over gateway participation, users benefit from free market competition among sequencers, and full permissionless composability with Ethereum is achieved.
## The Ultimate Vision
When fully implemented, the boundary between RISE and Ethereum becomes smaller. RISE becomes not just a fast L2, but a natural extension of Ethereum itself, offering security with L1-enforced slashing, L1-secured near realtime preconf rather than waiting for L1 confirmation, full composability with Ethereum's block-building market.
# Continuous Block Pipeline (/docs/rise-evm/cbp)
# Continuous Block Pipeline (CBP)
## The Problem with Traditional Block Production
In typical Layer 2 systems, block production follows a strictly sequential process, where only a small portion of the total blocktime is spent on actual transaction execution. This inefficiency stems from the traditional flow.
* **Consensus (C)**: Deriving L1 transactions and new block attributes. This phase blocks all other operations.
* **Execution (E)**: Executing derived transactions as well as L2 transactions from mempool. Execution is CPU-intensive.
* **Merkleization (M)**: Sealing the block by computing the new commitment to the state. Merkleization is IO-intensive and increases in cost as state size grows.
*A typical block pipeline for an L2 with a one-second block time and large state. The block gasLimit will be limited by how much gas can be processed in the time allocated to execution; however, in this system, execution accounts for only a minority of the block-building pipeline. The first block in an epoch has longer consensus time due to L1 and deposit derivation.*
During the block-building pipeline, most of the blocktime is allocated to consensus and merkleization, leaving a tiny portion of total blocktime for execution. This insufficient use of blocktime leads to poor performance on many L2s.
## Execution-Merkleization Separation
To speed up execution time, many Ethereum clients separate their databases for execution and merkleization. During execution, block executors use a flat database (flatDB) to read states. The flatDB provides O(1) time complexity for reading and writing key-value pairs, much faster than the MPT's log-squared complexity, enabling fast block executions.
All changes to keys are recorded in a **ChangeSet**. After block execution completes, the merkleization process updates the MPT with all changes from the ChangeSet to generate the full state commitment.
## RISE's Continuous Block Pipeline
Since execution and merkleization can operate on different databases, the next block's execution can start as soon as the current block's execution finishes without waiting for merkleization. CBP restructures the block building pipeline to reduce execution idle time.
The idea is simple: we perform execution if there are transactions residing in the mempool. We consider two cases:
### First L2 block in an epoch
For this block, consensus must derive new L1 block information and include L1→L2 deposited transactions. Therefore, execution of this block must be performed after consensus, since deposited transactions are prioritized and might invalidate L2 transactions.
### Other blocks in an epoch
L1 information within an epoch is the same for all blocks, therefore consensus for these blocks mostly depends on the previous block. Since there are no L1-derived transactions in these blocks, execution can safely start as soon as the execution of the previous block finishes.
## Benefits
This approach offers several key benefits:
* **Continuous Execution of Transactions**. The execution thread monitors the mempool for transactions and executes them in multiple block segments, no longer waiting for consensus to request a new block
* **Higher Execution Throughput**. Execution of the next block happens simultaneously with merkleization of the current block, allocating more time for execution
* **Optimized Mempool Processing**. A new mempool structure balances latency and throughput by pre-ordering transactions to minimize shared states and maximize parallel execution
CBP enables RISE to achieve exceptional throughput while maintaining the safety and consistency guarantees expected from modern rollups.
# Data Availability (/docs/rise-evm/data-availability)
# Data Availability
## Motivation
Data availability (DA) guarantees that all the necessary information to reconstruct the state of a rollup is available to anyone who needs it. This is crucial for the security of rollups, as it allows anyone to independently verify as well as challenge the validity of transactions and the state of the rollup. Furthermore, DA ensures that users can still access their funds and withdraw from the rollup even if the rollup itself (i.e, the sequencer) goes offline.
Ethereum introduced a new DA layer (blobs) to complement to the old `calldata` DA in its [Dencun hardfork](https://ethereum.org/en/roadmap/dencun/) with EIP-4844. Blobs enable cheaper DA costs (compared to `calldata`) as blobs’ data is transient and will be expired in around 18 days. This in turn helps reduce the overall cost for a rollup. However, the current blob throughput is limited. At the current state, Ethereum targets 6 blobs per block, with the maximum of 9 blobs. This translates to the target throughput of 64KB/s. The blob throughput is expected to (theoretically) be 8x after the Fukasa upgrade (expected late 2025), this will scale the target throughput to 512KB/s through PeerDAS v1.x. However, even with the upgrade, this throughput is insufficient for a high-load rollup like RISE.
***
## EigenDA
We use [EigenDA](https://www.eigenda.xyz/) as the main DA layer for our rollup in the normal case. EigenDA’s Mainnet currently supports a throughput of [100 MB/s](https://x.com/0xkydo/status/1950571973790363737), with the average confirmation of 5s. With this impressive throughput, EigenDA is able to provide sufficient throughput for RISE to operate upon.
EigenDA also offers good Ethereum alignment as it leverages restaking through EigenLayer to achieve native Ethereum integration through EigenLayer, directly leveraging Ethereum's validator set via restaking. EigenDA uses Ethereum for operator registration, dispute resolution, and settlement, with no separate consensus layer.
***
## Ethereum Blob Fallback
In the event of EigenDA unavailability, the rollup can fall back to posting transactions to Ethereum’s blobs. This helps maintain the rollup’s liveness and ensure users’ funds not getting stuck in the rollup’s bridge.
Ethereum fallback is triggered whenever the `op-batcher` receives an error from EigenDA or fails to receive any acknowledgement from EigenDA, or in the case where the batcher does not have enough funds to pay EigenDA transaction fees.
After issues with EigenDA have been addressed, the `op-batcher` will switch back to EigenDA as the main DA layer.
# RISE EVM Architecture (/docs/rise-evm)
# Architecture
Traditional web servers update state in a continuous, interrupt-driven manner. This means transactions are processed as soon as they arrive. When demand is high, servers implement queueing to manage the load and process requests as resources become available. This is the exact UX we aim to achieve with RISE.
RISE provides developers with exceptional performance and capabilities while delivering near-instant latency and seamless user experience. RISE achieves over 1 GGas/s with millisecond-latency for immediate transactions.
## Components
The figure below details the high-level architecture of the RISE stack.
* **Execution**. A revolutionary EVM-compatible execution engine that redefines performance with infinite speed.
* **Parallel EVM (pevm)**. The ultimate parallel EVM engine
* **Continuous Block Pipeline (CBP)**. Executing transactions while residing in mempool.
* **Shreds**. Efficient interrupt-driven block construction.
* **RiseDB**. A custom DB specifically designed for EVM chain states.
* **Data Availability**. A highly performant DA layer with Ethereum fallbacks.
* **ZK Fraud Proofs**. Simpler fraud proofs for better UX.
* **Based Sequencing**. The RISE's plan for decentralization.
## Core Components
The RISE stack delivers exceptional performance through these key components:
### Execution Engine
* **[Continuous Block Pipeline](/docs/rise-evm/cbp)** - Continuous block processing pipeline for optimal throughput
* **[Shreds](/docs/rise-evm/shreds)** - Fast transaction shredding for parallel execution
### Settlement & DA
* **[ZK Fraud Proofs](/docs/rise-evm/zk-fraud-proofs)** - Hybrid rollup approach combining optimistic and ZK proving for efficient fraud resolution
* **[Data Availability](/docs/rise-evm/data-availability)** - Modular DA layer leveraging Celestia and EigenDA for scalability
### Network Layer
* **[Transaction Lifecycle](/docs/rise-evm/tx-lifecycle)** - Complete transaction processing pipeline from submission to finality
* **[Network Participants](/docs/rise-evm/network-participants)** - Overview of RISE network participant types, roles, and hardware requirements
### Future Improvements
* **[Parallel EVM (PEVM)](/docs/rise-evm/pevm)** - The ultimate parallel EVM engine
* **[Based Sequencing](/docs/rise-evm/based-sequencing)** - Decentralized sequencing leveraging Ethereum L1 with cryptographically enforced preconfirmations and rotating gateways
These components work together to deliver over 100,000 TPS with sub-10ms latency while maintaining full EVM compatibility and Ethereum's security guarantees.
# Layer 2 Architecture (/docs/rise-evm/layer-2)
Content coming soon.
# Network Participants (/docs/rise-evm/network-participants)
# Network Participants
Traditional blockchains requiring every node to re-execute all transactions face significant drawbacks that hinder scalability, decentralization, and efficiency. This creates a problem when a blockchain wants to scale up its performance: **it needs to scale up the specs for all nodes in the network**. This is not wanted as fewer participants are able to join the network.
RISE's architecture features specialized network participants with distinct roles and hardware requirements, designed to enable scalability without requiring all nodes to re-execute transactions. Together with different optimization strategies, nodes are aided by the sequencer when performing state updates, further lowering hardware requirements to minimums.
In this doc, we use Capitalized words to denote distinct types of network participants. This convention helps clearly differentiate key roles such as **Sequencers**, **Replicas**, **Fullnodes**, **Challengers**, and **Provers** emphasizing their specific responsibilities within the network.
***
## Participants
### Sequencers
Sequencers serve as the network's core, ordering and processing transactions, then batching them for L1 submission. They leverage optimized execution engines (including [pevm](/docs/rise-evm/pevm), [CBP](/docs/rise-evm/cbp) and [shreds](/docs/rise-evm/shreds)) to achieve high performance. In RISE's based sequencing model, sequencers are [gateways](/docs/rise-evm/based-sequencing) operated by Ethereum validators.
### Replicas
Replicas synchronize with the chain by applying state-diffs from the Sequencer rather than re-executing transactions. This approach allows indexing services, block explorers, and archival nodes to operate on commodity hardware while relying on fraud proofs for security verification. Replicas maintain the full chain state without the computational overhead of re-execution.
### Fullnodes
Fullnodes re-execute transactions to independently verify state updates, requiring higher hardware specs than Replicas but lower than Sequencers. They benefit from metadata (e.g, state-diff, dependency DAG) provided during synchronization, allowing them to verify state changes more efficiently than re-execution. Fullnodes provide a security checkpoint for the network because they can detect and challenge invalid state transitions.
### Challengers
As an L2, we also need a special party to submit challenges to the L1 when it detects a misbehavior of the Sequencer. This party is called **Challenger**. A Challenger must maintain a Fullnode to be able to re-execute transactions provided by the Sequencer. It only requires a single honest Challenger to maintain the security of the L2 chain. This economic incentive model ensures that even if most participants are dishonest, one honest Challenger can protect all users.
### Provers
Provers generate validity proofs using specialized hardware accelerators (FPGA/GPU) when fraud challenges occur. They operate only when needed, activated only when the Sequencer misbehaves, making them cost-effective participants. Provers don't need to run continuously; they can be brought online on-demand as disputes arise.
***
## Hardware Specs
Sequencers consume the most resources because they must execute all transactions with high performance to maintain network throughput. Replicas are optimized for accessibility, requiring minimal hardware since they avoid transaction re-execution. Fullnodes and Challengers sit in the middle, requiring enough resources for independent verification. Provers operate on-demand with specialized accelerators, making them cost-effective despite their hardware needs.
| Node Type | Sync Method | Security | Hardware Requirements |
| --------------- | ---------------------- | ------------------------------ | ------------------------------------------ |
| **Sequencers** | Self-execution | High | 32GB RAM |
| **Replica** | State-diff appliance | Low, depending on fraud proofs | 8-16GB RAM |
| **Fullnodes** | Re-execution with aids | High, same as the Sequencer | 16-32GB RAM |
| **Challengers** | Same as Fullnodes | High, same as Fullnodes | 16-32GB RAM |
| **Provers** | Trusting the Sequencer | N/A | Depending on proving services, rarely used |
The diversity in hardware requirements ensures RISE can accommodate participants ranging from individual operators running lightweight Replicas to infrastructure providers operating high-performance Sequencers, all contributing to the security and resilience of the network.
# Parallel EVM (PEVM) (/docs/rise-evm/pevm)
# Parallel EVM (PEVM)
Note the PEVM is not currently live on RISE & is a future improvement. We have already published the PEVM implementation in [GitHub](https://github.com/risechain/pevm) for reference.
With our current architecture still able to achieve 1 GGas/s with sub 3 millisecond-execution.
## Motivation
### The Sequential Execution Bottleneck
Ethereum's execution model processes transactions sequentially by design. This sequential constraint stems from a fundamental requirement for distributed consensus: **all network participants must compute identical results**. While this sequential guarantee ensures correctness, it creates a severe performance limitation. Modern CPUs contain 8 to 16 cores, yet the EVM execution path utilizes only a single core. The remaining cores are idle while waiting for the current transaction to complete.
Additionally, independent transactions that could be executed in parallel are still executed in a sequential manner, creating unnecessary latency for users and limiting the network throughput. As a result, there exists a performance gap between Ethereum (and its rollups) and competitors like Solana:
* Ethereum and its rollups combined are processing around only [200-300 TPS](https://rollup.wtf/) across 50+ rollups.
* In contrast, Solana consistently produces 1000-2000 TPS, about 10 times larger than that of all rollups combined.
### EVM Parallelization Challenges
Parallel execution for blockchains has gained prominence with Aptos, Sui, and Solana, but EVM-compatible implementations face unique challenges. Early attempts to parallelize EVM execution, notably by Polygon and Sei using [Block-STM](https://arxiv.org/abs/2203.06871), showed limited gains, mainly due to:
1. Lack of EVM-specific optimizations tailored to Ethereum's state access patterns.
2. Implementation limitations in languages like Go (with garbage collection pauses).
3. Overhead from synchronization mechanisms that negate parallelism benefits.
### Slow State Root Calculation
Beyond transaction execution, the full block processing pipeline faces a secondary bottleneck. After executing all transactions, nodes must calculate the Merkle root of the new state (the state root). This computation can be as expensive or even more expensive than transaction execution itself. If state root calculation exceeds the block time, there will be less time left for execution, causing a performance loss.
[RISE parallel EVM (pevm)](https://github.com/risechain/pevm) sets to address these limitations through a ground-up redesign focused on the EVM's unique characteristics that efficiently **executes transactions, broadcasts results, and calculates the state root in parallel**; tightly implemented in Rust for minimal runtime overheads.
***
## Technical Overview
### What is pevm?
pevm is a revolutionary execution engine that enables concurrent processing of EVM transactions while maintaining deterministic outcomes. By distributing transaction execution across multiple CPU cores, pevm dramatically increases throughput and reduces latency compared to traditional sequential execution. Key features include:
* Optimistic execution of transactions in parallel.
* Detection of transaction dependencies and conflicts to ensure deterministic outcomes.
* Compatibility with existing sequential executors for easy integration and performance boosts.
### Optimistic Concurrent Execution
pevm is built upon the foundation of [Block-STM's](https://arxiv.org/abs/2203.06871) optimistic concurrent execution: rather than predicting dependencies, pevm assumes transactions are independent, executes them in parallel, then validates the execution afterward. The engine dynamically identifies transaction parallelism without requiring developers to change anything (like explicitly declaring access states in Solana and Sui). Regardless, dApps do need to innovate new parallel designs to get more out of the parallel engine, like [Sharded AMM](https://arxiv.org/abs/2406.05568) and RISE's upcoming novel CLOB; just like how multiprocessors gave rise to the design of multithreaded programs.
Overall, this strategy trades computational work (re-executing conflicting transactions) for parallelism. On blocks with numerous independent transactions, re-execution overhead is minimal because few conflicts occur. On blocks with sequential dependencies (e.g., multiple transactions sequentially updating the same contract), re-execution occurs but the system gracefully degrades to near-sequential performance, avoiding the overhead of parallel coordination.
### EVM-Specific Innovations
pevm's contribution is not just the Block-STM itself, but rather its adaptation to EVM's specific challenges.
#### Lazy Updates
All EVM transactions in the same block read and write to the same beneficiary account for gas payments, making all transactions interdependent by default. pevm addresses this by utilizing lazy updates for this account.
We mock the balance on gas payment reads to avoid registering a state dependency and only evaluate it at the end of the block or when there is an explicit read. We apply the same technique to other common scenarios such as raw ETH or ERC20 transfers.
This enables the ability to parallelize transfers from and to the same address, with only a minor post-processing latency for lazy evaluations.
#### Mempool Preprocessing
Unlike previous rollups that ordered transactions by first-come-first-served or gas auctions, RISE innovates a new mempool structure that balances latency and throughput. The goal is to pre-order transactions to z shared states and maximise parallel execution. This has a relatively similar effect as the local fee market on Solana, where congested contracts & states are more expensive regarding gas & latency. Since the number of threads to execute transactions is much smaller than our intended TPS, we can still arrange dedicated threads to execute high-traffic contract interactions sequentially and others in parallel in other threads.
***
## Architecture Design
Blockchain execution must be deterministic so that network participants agree on blocks and state transitions. Therefore, parallel execution must arrive at the same outcome as sequential execution. Having race conditions that affect execution results would break consensus.
### Legacy Architecture
RISE pevm started out with Block-STM's optimistic execution, with a collaborative scheduler and a multi-version data structure to detect state conflicts and re-execute transactions accordingly. pevm comprises several interacting layers:
* **Scheduler** manages and distributes tasks to worker threads. It maintains atomic counters for execution and validation task indices, allowing worker threads to claim tasks without conflict. Besides, the scheduler tracks transaction status (ready for execution, currently executing, awaiting validation, validated, or aborting) and manages transaction incarnation numbers (re-execution counts).
* **Worker Threads** are executor agents. In pevm, multiple worker threads operate in parallel and independently. Each worker thread executes a sequence of tasks assigned by the scheduler: execution tasks and validation tasks. Workers do not directly synchronize with each other; all coordination occurs through the scheduler and multi-version memory structures.
* **Multi-Version Memory (MvMemory)** is the central data for conflict detection. MvMemory preserves a complete history of all writes, indexed by transaction index. For each location, MvMemory tracks which transaction wrote what value and in what order. When a transaction reads a location, it retrieves the most recent value written by any lower-indexed transaction. This versioning enables validation: after a transaction executes, validation can determine whether the specific transactions that wrote to each read location have changed.
We made several contributions fine-tuned for EVM. For instance, all EVM transactions in the same block read and write to the beneficiary account for gas payment, making all transactions interdependent by default. RISE pevm addresses this by lazy-updating the beneficiary balance. Rather than writing actual beneficiary balance changes during execution, pevm defers this update at the end of block execution. Similarly, for raw ETH transfers to non-contract addresses, it defers both sender and recipient balance updates. These lazily-accumulated values are accumulated throughout the block and evaluated once at execution completion, or on-demand if explicitly read.
However, the legacy architecture has a limitation: it wraps the [revm](https://github.com/bluealloy/revm) EVM implementation as a black box. The custom database interface (VmDB) intercepts reads and writes but cannot optimize the internal execution flow.
### Early Performance Benchmarks
Although the legacy pevm is in pre-alpha stage, [early benchmarks](https://github.com/risechain/pevm/tree/main/crates/pevm/benches) already show promising results:
* For large blocks with few dependencies, Uniswap swaps saw a 22x improvement in execution speed.
* On average, pevm is around 2x faster than typical sequential execution for a variety of Ethereum blocks.
* The max speed-up is around 4x for a block with few dependencies.
* For L2's with large blocks, pevm is expected to consistently surpass 5x improvement in execution speed.
***
## Future Works: pevm Evolution
As we worked on our [continuous block pipeline](/docs/rise-evm/cbp), [shreds](/docs/rise-evm/shreds), and [Reth's parallel sparse trie](https://github.com/paradigmxyz/reth/tree/v1.9.3/crates/trie/sparse), we eventually found ways to innovate Parallel EVM way beyond what BlockSTM originally proposed. The ultimate goal is to achieve 10 Gigagas/s and beyond, making RISE pevm the fastest EVM execution engine available.
The new architecture aims to accelerate the legacy architecture through the following optimizations.
### Inline Parallel-Aware EVM
Rather than wrapping [revm](https://github.com/bluealloy/revm), the new architecture implements an EVM interpreter specifically designed for parallel execution. The inline interpreter sets to minimize VM overheads, and enable efficient sharing of read-only bytecode and state across worker threads.
### Shred Integration
As [shreds](/docs/rise-evm/shreds) are becoming more mature, we will add shreds to broadcast pending states per committed transactions in realtime, enabling fullnodes and dApps to observe state changes in realtime. Furthermore, each shred contains a state-diff from the previous state, making it possible for following nodes to build a transaction dependency graph (i.e, DAG), further accelerate re-execution performance.
### Sparse Trie for State Root Calculation
Computing the Merkle root of all state changes is computationally expensive and traditionally blocks the critical path. The new design employs a sparse trie to accelerate state root calculation. Rather than computing a state root after all transactions complete, the system progressively updates the trie as transactions validate, with background worker threads computing Merkle proofs in parallel. This reduces the overhead of state root calculation from the critical path, leaving more time for execution.
### Extended Resource-Aware Scheduler
We extend the scheduler to also schedule shred committing and multiproof tasks, with a new design that is highly resource-aware. The new scheduler evolves beyond distributing execution and validation tasks to coordinating a richer task set: **execution, validation, multiproof generation, and shred commitment**. It becomes *resource-aware* by analyzing CPU and memory usage, dynamically adjusting task priorities and worker thread assignments.
# RiseDB (/docs/rise-evm/rise-db)
# RiseDB
## Motivation
Every transaction in a blockchain updates state: account balances change or contract updates, and historical records accumulate. Managing this state efficiently is critical to blockchain performance. However, traditional state management architectures face significant bottlenecks that limit throughput and increase latency.
The current state storage uses a two-layered architecture.
* **Merkle Patricia Trie (MPT)**. An authenticated data structure that guarantees data integrity and is typically built using a Merkle tree-like structure. It also provides a mechanism to verify the presence of specific data within the state. Nodes in the ADS are usually connected via hashes, and each node is stored in the underlying database
* **Backend database**. A component that helps persist data to disks; manages physical storage and retrieval; and handles compaction and organization of data. This backend database is often LSM-based.
This diagram illustrates the structure:
A read to the state involves traversing the MPT from its root down to the target leaf node. During this traversal, the MPT must fetch the content of each node from the backend database (if not cached). Due to the LSM tree structure of the database, each query itself involves multiple disk accesses. Consequently, a single read operation often translates into many I/O operations. This amplification effect worsens as the state size increases.
*A simplified version of the Ethereum’s MPT (source: [CSDN](https://it007.blog.csdn.net/article/details/86551694?spm=1001.2101.3001.6650.19\&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-19-86551694-blog-79992072.pc_relevant_multi_platform_whitelistv1_exp2\&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-19-86551694-blog-79992072.pc_relevant_multi_platform_whitelistv1_exp2\&utm_relevant_index=25)). All keys have the same `a7` prefix so an extension node is created to save space and redundancy. The same goes for `a77d337` and `a77d397` which share the same `d3` prefix.*
The MPT aims to reduce redundancy and I/Os by compressing nodes with a single child to form so-called extension nodes. As reads need to query all nodes along the path from the root down to the target leaf node, extension nodes help reduce the number of queries. Extension nodes are more effective when the underlying data is sparse. However, as the state grows, the data becoming less sparse, effectively reducing the effects of extension nodes.
For a high-performance rollup like RISE targeting 100k+ TPS, this traditional architecture becomes a bottleneck. Every millisecond of latency in state access directly reduces the number of transactions RISE can process per second.
***
## RiseDB
RiseDB is a high-performance verifiable key-value store with a specific focus on efficiently managing the state of blockchain networks. One key objective of RiseDB is to achieve significantly faster state updates and access compared to existing solutions. This high throughput is compulsory for blockchains striving to support a large and active user set with numerous transactions.
### Unified Architecture
Traditional systems manage world state and Merkle trees separately, creating overhead and redundant operations. RiseDB merges world state and Merkle tree storage into a single, streamlined architecture, eliminating the overhead associated with managing separate layers, leading to more efficient data handling and merkleization processes. This unified design eliminates context switches between different storage engines, reduces data duplication, and streamlines state operations.
### Low Memory Footprint
The memory footprint of RiseDB is very small, allowing it to operate efficiently on consumer-grade computers, potentially lowering the barrier to entry for participating in blockchain networks. As a result, it enables broader node participation, reduces operational costs for node operators, and maintains the network's resilience by not requiring expensive infrastructure. Furthermore, the low memory footprint does not come at the cost of performance, RiseDB achieves high-speed operations while remaining memory-efficient.
### SSD-Optimized Access Patterns
RiseDB employs a storage design carefully tailored to leverage the strengths of modern SSDs, optimizing access patterns to maximize throughput and durability. By organizing data in a way that minimizes costly random writes and favors sequential, append-only operations, RiseDB efficiently utilizes SSD I/O capabilities.
# Shreds (/docs/rise-evm/shreds)
# Shreds
Shreds enable a user experience that feels like the modern web, but on a blockchain. They generate transaction preconfirmations within single-digit milliseconds, reacting to demand in real time. Unlike traditional blockchains, which wait for discrete blocks to process, Shreds are continuous and interrupt-driven.
## Breaking Down Blocks
When posting summaries to L1 and DA, a rollup typically batches multiple L2 blocks together to reduce costs. Since merkleization is not required for every L2 block, we can break L2 blocks (12-second long) into **Shreds** (sub-second long), essentially **mini-blocks without a state root**.
Constructing and validating these Shreds is much faster due to the omission of state root merkleization. Therefore, broadcasting them enables rapid transaction and state confirmations. This improved latency doesn't sacrifice security, as new L2 blocks can only provide unsafe confirmations anyway.
[//]: # ""
***
## What are Shreds?
Shreds partition an L2 block into multiple consecutive, connecting segments. Each Shred for an L2 block is identified via its sequence number. In other words, `block_num` and `seq_num` together can always identify a Shred. The sequence number increases for each Shred and resets when a new L2 block is constructed.
A Shred contains a **ChangeSetRoot** that commits to all state changes made within the Shred. During execution, the sequencer uses the flatDB to access data and records all changes to a **ChangeSet**. The number of entries in a ChangeSet is relatively small compared to the state size because it only holds the changes, therefore the data is sparse and can fit in memory. As a result, constructing the ChangeSetRoot can be efficiently done.
***
## Block Propagation
Broadcasting is done per Shred instead of waiting for the full L2 block. Shreds with invalid signatures are discarded. As peer nodes receive valid Shreds, they optimistically construct a local block and provide preconfirmations to users.
The sequencer might also broadcast the ChangeSet within a Shred to its peers. This ChangeSet can be verified against the ChangeSetRoot attached to the Shred's header. Nodes trusting the sequencer can apply the ChangeSet immediately to their local state without re-executing transactions.
***
## Batch Preconfirmations
Preconfirmations are issued per batch via Shreds instead of per individual transaction. Users can receive preconfirmations without waiting for the entire L2 block to be completed. The Shred blocktime can be configured to balance multiple factors, including preconfirmation latency and network bandwidth.
***
## Efficient Merkleization
Merkleization's performance is influenced by both the size of state data and the number of changes (i.e., the size of the ChangeSet). Additionally, batch updates are more efficient than sequential updates.
Merkleization for an L2 block only happens after the last Shred is generated. Accumulating changes over multiple Shreds reduces the number of final keys that need updating, thanks to transaction overlap. The same data is likely to be accessed multiple times across blocks, especially with popular dApps like Uniswap.
Shreds enable RISE to provide instant transaction confirmations while maintaining the security and consistency guarantees of traditional rollups.
# Transaction Lifecycle (/docs/rise-evm/tx-lifecycle)
# Transaction Lifecycle
RISE's transaction lifecycle facilitates a streamlined process, designed to reduce latency to as low as possible. Unlike other blockchains, RISE aims to provide near-instant responses to users' transactions.
## 1. Transaction Preparation & Broadcasting
The lifecycle of a transaction starts with a user creating and signing a transaction, and submitting it to an RPC node via their frontend.
## 2. P2P Propagation
After receiving the transaction from the user, the RPC node performs sanity checks and then broadcasts this transaction to the sequencer using the P2P network.
## 3. Mempool Pre-Execution
As described in the [CBP](cbp), the transaction is pre-executed as soon as it lands in the sequencer's mempool. The CBP makes use of idle time to execute transactions while other tasks are happening. This is one of the ways we reduce end-to-end latency for transaction processing.
## 4. Shred Inclusion
Pending transactions (residing in the mempool) are included in a **Shred**. Shreds partition a canonical L2 block into multiple consecutive yet separately-verifiable segments. Shreds allow an L2 block to be incrementally constructed, with each Shred serving as a batch of preconfirmations for transactions it contains.
Importantly, each Shred does not require merkleization, allowing RISE to reduce its latency to just a few milliseconds.
Pending transactions are pre-executed while sitting in the mempool, therefore, at the time of Shred inclusion, we can reuse the pre-executed results from the previous step.
## 5. Shred Propagation & Early Updates
The sequencer broadcasts a Shred to other nodes via the P2P network after it is created. As soon as a node receives a new Shred, it immediately executes transactions within this Shred (or applies changes provided by the Shred) to get the latest state of the network.
This enables faster state synchronization across the network and a quicker response to the user's transaction. At this point, the receipt for the transaction is available and can be returned to the user.
## 6. L2 Block Inclusion
After a predefined period of time (L2 blocktime), Shreds are batched together to create a canonical L2 block. At this time, merkleization is done to seal the L2 block.
## 7. L1 Block Inclusion
Periodically, L2 blocks are batch-submitted to the DA layer and the L1 for finalizing. At this stage, transactions are considered safe (if no fraud challenge is triggered).
## Key Benefits
* **Pre-execution**: Transactions are executed before inclusion, reducing confirmation time
* **Shred-based confirmations**: Users get confirmations in milliseconds, not seconds
* **Early state updates**: Nodes update state immediately upon receiving Shreds
* **Optimized pipeline**: Each step is optimized to minimize latency while maintaining security
This lifecycle enables RISE to provide the instant responsiveness users expect while maintaining the security and decentralization properties of a proper rollup.
# ZK Fraud Proofs (/docs/rise-evm/zk-fraud-proofs)
# ZK Fraud Proofs
## Motivation
At the beginning, we adopted an optimistic design primarily due to the simplicity of the optimistic approach and the limitations of zero-knowledge (ZK) proving technology. At that time, simulating an EVM machine with ZK was not feasible, and ZK proving was unable to meet the desired throughput demands. Optimistic rollups, on the other hand, offered a simpler and more scalable solution.
### Complicated Interactive Fraud Proofs
However, traditional optimistic rollups rely on **interactive fraud proofs** where validators engage in multiple back-and-forth interactive steps to identify the exact transaction or step where computation diverged. This process is complex to implement correctly, due to:
* **Multi-round Interactions**. Parties must engage in multiple rounds of challenges and responses.
* **State Management**. Tracking disputed ranges, bisection points, and commitments adds significant complexity.
* **Latency Overhead**. Challenge-response cycles can take days or weeks, delaying final settlement.
Although interactive fraud proofs work, the process is complex and time-consuming, and requires significant interactions and is unfriendly to challengers.
### Expensive ZK Proofs
With recent advancements in the ZK ecosystem, we are now able to prove an EVM block in an order of seconds and transitioning to a full ZK rollup is feasible. Nevertheless, we realize that generating validity proofs is not always ideal.
* Validity proofs offer fast finality but the proving performance might not keep up with our execution client on realtime proving. We aim to process 100k TPS at RISE, and ZK proving at this rate is not possible at the moment.
* Verifying a validity proof on the L1 is expensive. If we do this frequently, users have to bear this cost, and thus, increase the transaction cost to users.
* Furthermore, as long as the sequencer behaves honestly, we will never need to use validity proofs. However, generating validity proofs for every transaction incurs an additional cost for users.
### Inability of DA Commitment Challenging with AltDA
Data Availability (DA) is crucial to fraud games, and the security of a rollup. Without DA, it is not possible to ensure the challenge and sequencer are playing a game on the same data. RISE's current design is built upon the battle-tested [OP Stack](https://github.com/ethereum-optimism/optimism) and leverages [EigenDA for its Data Availability (DA) layer](/docs/rise-evm/da). However, this design has a critical security issue that makes the sequencer highly trusted, discouraging users to use RISE.
When rollups use an AltDA layer instead of posting all data to Ethereum L1, they introduce a new challenge: **verifying DA commitments on-chain becomes problematic**.
OP Stack supports two AltDA systems: **Type 0 (Keccak)** commitments, which are simple hashes and can be challenged directly on-chain, and **Type 1 (DA-Service)** commitments, which have a flexible `da_layer_byte ++ payload` structure designed to be handled by the AltDA Server.
The problem is, the existing OP Stack implementation [does not support AltDA challenge other than Type 0 (Keccak)](https://specs.optimism.io/experimental/alt-da.html?highlight=altDA#data-availability-challenge-contract). This creates a verification gap, the network must trust the AltDA Server's claim about data availability, making fraud proofs not possible, which in turn violates the security of the rollup.
***
Therefore, we consider a hybrid approach in which we still adopt the optimistic design but utilizing ZK to generate validity proofs for a state commitment if challenged.
***
## ZK Fraud Proofs with OP Succinct Lite
RISE's ZK Fraud Proofs are made possible by [OP Succinct Lite](https://github.com/succinctlabs/op-succinct). OP Succinct Lite allow us to resolve any dispute in a single round, without the interaction requirement between the challengers and the proposer. This is more efficient than the interactive bisecting game mentioned above. Moreover, OP Succinct Lite supports AltDA like EigenDA or Celestia, which is the perfect match for RISE.
### The Workflow
The following diagram depicts the simplified flow of the hybrid approach.
The sequencer publishes state commitments without proof similar to traditional optimistic rollups. If anyone detects an invalid state commitment, they can initiate a fraud challenge. Once challenged, the sequencer is responsible for generating a ZK validity proof demonstrating that the state transition was correct. Failures in providing a valid ZK proof in time will lead the sequencer to be slashed, and the corresponding commitment is considered invalid.
The system's elegance lies in its economics: **most of the time (99.9999%), validity proofs are never needed**. This means users avoid bearing the costs associated with proof generation and verification.
### Implications
The ZK fraud proof approach offers a more efficient, secure, and user-friendly experience.
* **Shorter Challenge Period**. Validity proofs are only required once we have a challenge. If a challenge is invoked, the sequencer then has an additional window to submit the required validity proof. The additional window time should be on an order of the maximum proving time for the sake of security.
* **Simpler and Robust Fraud Mechanism**. ZK proofs appear to be more robust than interactive fraud proofs and there are several ZK rollups that have been running on the mainnet. With this approach, a challenger can just focus on keeping up with the chain progress and identifying the incorrect state transition (same as the re-executing fraud proofs), no other interaction is required.
* **Cost Saving**. The cost for users is the same as in an optimistic rollup and operational costs are lower than a ZK rollup. While ZK rollups have to bear the cost of generating validity proofs for every state transition, even if there is no transaction; this is not required in a hybrid mode. As a result, users do not have to pay extra costs of validity proof generation and verification.
* **AltDA**. OP Succinct Lite's support for EigenDA means RISE can achieve the cost and scalability benefits of off-chain DA while maintaining on-chain verifiability through ZK proofs. No trust on the sequencer is required for security.
***
## The Path Forward: ZK Rollup
RISE is designed to evolve toward a full ZK rollup as ZK proving technology matures and becomes more cost-effective. Rather than attempting to jump directly to pure ZK proving, we follow a phased approach that allows us to validate performance, optimize systems, and maintain user experience at each stage.
### Phase 1: ZK Fraud Proofs (Current)
RISE currently operates as a hybrid rollup using ZK fraud proofs for security. The sequencer publishes state commitments optimistically, and ZK proofs are generated only when disputes arise. This phase delivers fast, low-cost transactions in the honest case, cryptographic security guarantees through on-demand ZK proving, and economic efficiency where users do not bear proving costs for normal operation.
### Phase 2: Proactive Proving
***Figure**. Lifecycle of a fraud game.* (\*: *resolve can only be processed if the parent game is already resolved*).
As ZK proving technology continues to advance and costs decrease, RISE will transition to **proactive proving**, where the sequencer voluntarily submits ZK proofs for state commitments even without fraud challenges. This is a critical transitional phase for several reasons.
First, transactions achieve cryptographic finality as soon as the proof is verified on L1, rather than waiting for a challenge window to pass, delivering faster finality to users.
Second, this phase allows RISE to operationally validate ZK proving performance at scale without being dependent on it for security: running proofs continuously reveals performance bottlenecks and allows optimization before full ZK commitments.
Third, users experience faster finality incrementally without a sudden transition. In this phase, fraud proof challenges still serve as a security backup: if a sequencer fails to submit a proof, the fraud proof mechanism activates. This provides a graceful fallback while allowing real-world testing of proving infrastructure at scale.
### Phase 3: Full ZK Rollup
Once proving costs are sufficiently reduced and performance meets RISE's throughput demands, the network will transition to a **full ZK rollup**. At this point, validity proofs become mandatory for every state transition, delivering instant cryptographic finality as standard. The fraud proof mechanism is no longer needed since cryptographic correctness is always proven. Security is guaranteed cryptographically rather than through economic assumptions.
The transition between phases is not time-bound but rather tied to technological maturity and cost-effectiveness of ZK proving. RISE will remain in Phase 1 until Phase 2 becomes practical, and will remain in Phase 2 until Phase 3 becomes economically viable. This phased approach ensures RISE maintains optimal performance and user experience at every stage of evolution.
# Connecting Wallet (/docs/rise-wallet/connecting)
import { WalletConnect } from "@/components/rise-wallet/WalletConnect";
import { ComponentPreviewTabs } from "@/components/rise-wallet/ComponentPreviewTabs";
import { CODE_EXAMPLES } from "@/components/rise-wallet/code-examples";
# Connecting Wallet
Connecting to RISE Wallet is as simple as using any standard Wagmi connector. The Porto connector handles passkey authentication automatically, creating a seamless login experience.
## How it Works
1. **Find the Rise Wallet Connector**: Locate the Rise Wallet connector from the available connectors using its ID `com.risechain.wallet`.
2. **Trigger Connection**: Call the `connect` function with the Rise Wallet connector.
3. **Passkey Authentication**: The user is prompted to authenticate using their device's passkey (FaceID, TouchID, etc.).
4. **Account Ready**: Once authenticated, the account is connected and ready to transact.
The Rise Wallet connector integrates seamlessly with Wagmi's standard hooks like `useAccount`, `useConnect`, and `useDisconnect`, requiring no specialized APIs.
# How It Works (/docs/rise-wallet/how-it-works)
import { Steps, Step } from 'fumadocs-ui/components/steps';
RISE Wallet is built on top of [Porto](https://porto.sh/), a next-generation account stack for Ethereum that leverages [EIP-7702](https://eip7702.io/) for native account abstraction. With our backend & SDK customised to utilise RISE high performance in addition to providing chain wide gas sponsorship for real users. This page explains how RISE Wallet works under the hood.
## Architecture Overview
RISE Wallet consists of three main components:
### 1. Smart Account Infrastructure
* **Porto Smart Accounts**: Audited contracts that provide account abstraction features
* **EIP-7702 Integration**: Native account abstraction without smart contract wallets
* **Key Management**: Support for multiple key types (P256, `secp256k1`, WebAuthn)
### 2. Relay Infrastructure
* **Gas Sponsorship**: Automatic gas payment for eligible transactions
* **Transaction Batching**: Bundle multiple operations into single atomic transactions
* **Circuit Breakers**: Safety mechanisms to prevent abuse and overspending
### 3. Dialog Interface
* **Passkey Authentication**: WebAuthn-based login with biometrics
* **Cross-Platform Support**: Works on web, mobile, and desktop
* **Session Management**: Secure storage and handling of session keys
## Transaction Flow
When a user interacts with RISE Wallet, the following process occurs:
### User Action
User initiates a transaction (transfer, swap, mint, etc.)
### Wallet Dialog\*
RISE Wallet dialog opens to handle the request
When a valid session key is available, this step is bypassed entirely. The transaction is signed automatically without requiring user interaction, enabling seamless high-frequency actions.
### Authentication Check
The system checks if a valid session key exists:
* **Has Session Key** → Sign automatically with session key
* **No Session Key** → Request user signature via passkey
### Relay Processing
The signed transaction is sent to the RISE Relay for processing
### Sponsorship Validation
Relay checks sponsorship rules:
* User tier and daily limits
* Whitelisted contracts
* Allowed functions
### Network Submission
Valid transaction submitted to RISE network
### Instant Confirmation
Shred confirmation received in \~3ms via WebSocket
## Key Technologies
### EIP-7702: Set Code Transaction
EIP-7702 allows EOAs (Externally Owned Accounts) to temporarily delegate their functionality to smart contract code during a transaction. This enables account abstraction features without deploying a smart contract wallet, while maintaining compatibility with existing Ethereum infrastructure. Read more about EIP-7702 [here](https://eip7702.io/).
### WebAuthn & Passkeys
RISE Wallet uses WebAuthn for authentication, supporting biometric login methods like FaceID, TouchID, and Windows Hello. Keys are stored securely in the device's secure enclave and can sync across devices via cloud providers.
### Session Keys
Temporary keys with specific permissions enable apps to act on a user's behalf within defined limits. This allows high-frequency actions without user interruption, while maintaining safety through time and spend limits.
## Gas Sponsorship
RISE Wallet implements intelligent gas sponsorship:
### Default Sponsorship
* New users receive daily gas budget
* Core protocol interactions (swaps, mints) are sponsored
* RISEx trading is fully sponsored
## Security and Recovery
RISE Wallet employs multi-layer security with passkeys stored in secure hardware, audited Porto contracts, and RISE's fast finality to prevent reorg attacks. Session keys use time-bound permissions with explicit scoping for safe temporary access.
Account recovery is supported through guardian recovery with trusted addresses, time-locked recovery mechanisms for added security, and multi-signature options for high-value accounts.
## Integration with RISE
RISE Wallet is optimized for RISE's unique architecture:
### Shred Integration
* Instant confirmation notifications via WebSocket
* Realtime balance updates
* Immediate transaction feedback
## Technical Specifications
### Supported Chains
* RISE Mainnet (coming soon)
* RISE Testnet
* Future: Cross-chain support via RISE bridges
### Key Types
* **P256**: Native browser/device support
* **`secp256k1`**: Ethereum standard compatibility
* **WebAuthn P256**: Passkey integration
{/* ### Performance
- Transaction preparation: <100ms
- Signature generation: <50ms
- Network submission: <10ms
- Total UX latency: <200ms + network time */}
## Learn More
* [Porto Documentation](https://porto.sh/) - Original Porto implementation
* [EIP-7702 Specification](https://eips.ethereum.org/EIPS/eip-7702) - Set code transaction details
# RISE Wallet (/docs/rise-wallet)
import { RiseWalletPlaygroundSimple } from "@/components/rise-wallet/RiseWalletPlaygroundSimple";
import { Card, Cards } from 'fumadocs-ui/components/card';
import { Cpu, Code, Key, Coins, ArrowLeftRight } from 'lucide-react';
RISE Wallet Stack is a chain-native wallet layer for the entire RISE ecosystem. It is a shared, trustless walet experience that feels like Web2, backed by audited smart accounts from Porto and wired into RISE's ultra-fast EVM.
## Why RISE Wallet?
Most of today's wallets were built for early crypto power users, requiring seed phrases, browser extensions, manual gas management, and complex bridging. RISE Wallet takes a different path:
* **Gasless by Default**: Users receive a daily gas budget. You don't need to hold ETH to start using apps.
* **Passkey Login**: No seed phrases. Sign in with biometrics (FaceID, TouchID) or WebAuthn.
* **One Wallet, Everywhere**: A single global wallet experience that spans the entire RISE ecosystem.
* **Session Keys**: Delegate specific permissions (e.g., "spending 50 tokens/minute") to local keys for instant, popup-free transactions.
## Try It Out
Connect your wallet below to experience the RISE Wallet flow. You can create a session key, mint test tokens, and swap them instantly.
## Features
### Chain-Native Integration
RISE Wallet is wired directly into RISE's infrastructure, providing a seamless experience across all applications on the chain.
### Built for Speed
Leveraging RISE's 3ms confirmations via shreds, wallet operations feel instant.
### Developer-First
Simple SDK integration with standard `Wagmi` and `Viem` libraries means you can add wallet functionality without learning specialized APIs.
## Next Steps
} title="How It Works" href="/docs/rise-wallet/how-it-works" description="Technical architecture and implementation details" />
} title="Viem Integration" href="/docs/rise-wallet/viem" description="Integrate with Viem for direct contract interactions" />
} title="Wagmi Integration" href="/docs/rise-wallet/wagmi" description="Add RISE Wallet to your React app with Wagmi" />
} title="Session Keys" href="/docs/rise-wallet/session-keys" description="Enable gasless, popup-free transactions" />
} title="Minting Example" href="/docs/rise-wallet/minting" description="Mint tokens with RISE Wallet integration" />
} title="Swapping Example" href="/docs/rise-wallet/swapping" description="Build token swap functionality with session keys" />
# Minting Tokens (/docs/rise-wallet/minting)
import { MintWidget } from "@/components/rise-wallet/MintWidget";
import { ComponentPreviewTabs } from "@/components/rise-wallet/ComponentPreviewTabs";
import { CODE_EXAMPLES } from "@/components/rise-wallet/code-examples";
# Minting Tokens
This example demonstrates how to interact with a smart contract on RISE. Because RISE Wallet users often start without gas, transactions are sponsored by the relay infrastructure.
## How it Works
1. **Contract Interaction**: We use `wagmi`'s `useSendCalls` (or a wrapper hook) to send transactions.
2. **Gas Sponsorship**: The RISE Paymaster automatically sponsors eligible transactions.
3. **User Experience**: The user signs the request with their Passkey (or Session Key if active), and the transaction is submitted instantly.
### Sending a Transaction
To write to a contract, encode the function data using `viem` and send it using `sendCallsAsync`.
```tsx
import { useSendCalls } from "wagmi";
import { encodeFunctionData } from "viem";
import { MintableERC20ABI } from "@/abi/erc20";
// ... inside your component
const { sendCallsAsync } = useSendCalls();
const handleMint = async () => {
const data = encodeFunctionData({
abi: MintableERC20ABI,
functionName: "mintOnce",
args: [],
});
await sendCallsAsync({
calls: [
{
to: "0x...", // Token Contract Address
data,
},
],
});
};
```
# Session Keys (/docs/rise-wallet/session-keys)
import { SessionKeysWidget } from "@/components/rise-wallet/SessionKeysWidget";
import { ComponentPreviewTabs } from "@/components/rise-wallet/ComponentPreviewTabs";
import { CODE_EXAMPLES } from "@/components/rise-wallet/code-examples";
# Session Keys
Session keys are temporary keys that are granted specific permissions. They allow your app to sign transactions on behalf of the user without prompting them for confirmation every time.
This is critical for:
* **High-frequency trading**: Place and cancel orders instantly.
* **Games**: Move characters or perform actions without interrupting gameplay.
* **Social apps**: Like posts or follow users with a single tap.
## Creating a Session Key
You use the `useGrantPermissions` hook from `rise-wallet/wagmi` to request a new session key. You must define exactly what this key can do (permissions) and how long it lasts (expiry).
```tsx
import { Hooks } from "rise-wallet/wagmi";
import { P256, PublicKey } from "ox";
// ... inside component
const grantPermissions = Hooks.useGrantPermissions();
const createSession = async () => {
// 1. Generate a local key pair (P256)
const privateKey = P256.randomPrivateKey();
const publicKey = PublicKey.toHex(P256.getPublicKey({ privateKey }), {
includePrefix: false,
});
// 2. Define Permissions (e.g., allow calling 'mint' on a specific contract)
const permissions = {
calls: [
{
to: "0x...", // Contract Address
signature: "0x...", // Function Selector
}
]
};
// 3. Request the session key from the wallet
await grantPermissions.mutateAsync({
key: { publicKey, type: "p256" },
expiry: Math.floor(Date.now() / 1000) + 3600, // 1 hour
permissions,
});
// 4. Store the private key securely (e.g., localStorage) to sign future requests
localStorage.setItem("session_key", privateKey);
};
```
Once created, you can use the stored private key to sign and send `wallet_sendPreparedCalls` requests directly to the RISE RPC, bypassing the wallet popup completely.
# Swapping Tokens (/docs/rise-wallet/swapping)
import { SwapWidget } from "@/components/rise-wallet/SwapWidget";
import { ComponentPreviewTabs } from "@/components/rise-wallet/ComponentPreviewTabs";
import { CODE_EXAMPLES } from "@/components/rise-wallet/code-examples";
# Swapping Tokens
Swapping tokens often requires two steps: **Approval** and **Execution**. RISE Wallet supports batching these operations into a single atomic transaction when using EIP-5792 `sendCalls`, providing a much smoother UX.
## Atomic Batching
Instead of asking the user to sign an "Approve" transaction, wait for it to land, and then sign a "Swap" transaction, you can bundle them together.
```tsx
const approveData = encodeFunctionData({
abi: ERC20_ABI,
functionName: "approve",
args: [ROUTER_ADDRESS, amount],
});
const swapData = encodeFunctionData({
abi: ROUTER_ABI,
functionName: "swapExactTokensForTokens",
args: [amount, minOut, path, recipient, deadline],
});
// Send both calls in one user operation
await sendCallsAsync({
calls: [
{ to: TOKEN_ADDRESS, data: approveData },
{ to: ROUTER_ADDRESS, data: swapData },
],
});
```
This reduces the time users spend waiting and clicking popups, making DeFi feel instant.
# Viem Integration (/docs/rise-wallet/viem)
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
This guide covers integrating RISE Wallet with [Viem](https://viem.sh/), a TypeScript interface for Ethereum that provides low-level access to blockchain functionality.
## Overview
RISE Wallet provides first-class Viem support through custom actions and account implementations. This integration is ideal for developers who need fine-grained control over wallet operations.
## Installation
```bash
npm i rise-wallet viem
```
```bash
pnpm add rise-wallet viem
```
```bash
yarn add rise-wallet viem
```
```bash
bun add rise-wallet viem
```
## Basic Usage
### Creating a Client
Use Rise Wallet's EIP-1193 provider with Viem's custom transport:
```ts
import { createClient, custom } from "viem";
import { RiseWallet } from "rise-wallet";
// Create Rise Wallet instance
const rw = RiseWallet.create();
// Create Viem client with Rise Wallet provider
const client = createClient({
transport: custom(rw.provider),
});
```
### Using Wallet Actions
RISE Wallet exports a `WalletActions` module with Rise Wallet-specific functionality:
```ts
import { WalletActions } from "rise-wallet/viem";
// Connect to wallet
const { accounts } = await WalletActions.connect(client);
console.log("Connected account:", accounts[0]);
// Get user assets
const assets = await WalletActions.getAssets(client);
console.log("User assets:", assets);
```
## Standard Viem Actions
All standard Viem wallet actions work with RISE Wallet:
### Send Transaction
```ts
import { parseEther } from "viem";
import * as Actions from "viem/actions";
const hash = await Actions.sendTransaction(client, {
to: "0x...",
value: parseEther("0.001"),
});
console.log("Transaction hash:", hash);
```
### Send Calls (EIP-5792)
```ts
const result = await Actions.sendCalls(client, {
account: "0x...",
calls: [
{
to: "0x...",
data: "0x...",
},
],
});
```
### Sign Message
```ts
const signature = await Actions.signMessage(client, {
account: "0x...",
message: "Hello RISE!",
});
```
## RISE Wallet Actions
### Grant Permissions
Create session keys with specific permissions:
```ts
import { Key } from "rise-wallet/viem";
import { keccak256, toHex, parseEther } from "viem";
const permissions = await WalletActions.grantPermissions(client, {
key: Key.createP256(), // Generate new P256 key
expiry: Math.floor(Date.now() / 1000) + 3600, // 1 hour
permissions: {
calls: [
{
to: "0x...", // Contract address
signature: keccak256(toHex("transfer(address,uint256)")).slice(0, 10),
}
],
spend: [
{
limit: parseEther("50"),
period: "minute",
token: "0x...",
}
],
},
});
```
### Get Permissions
View active permissions:
```ts
const permissions = await WalletActions.getPermissions(client);
permissions.forEach(permission => {
console.log("Key:", permission.key);
console.log("Expiry:", permission.expiry);
console.log("Allowed calls:", permission.calls);
});
```
### Revoke Permissions
Remove granted permissions:
```ts
await WalletActions.revokePermissions(client, {
keyId: "0x...",
});
```
## Key Management
RISE Wallet provides utilities for working with different key types:
### P256 Keys
```ts
import { Key, PublicKey } from "rise-wallet/viem";
// Create new P256 key
const key = Key.createP256();
// Import existing key
const imported = Key.fromP256({
privateKey: "0x...",
});
// Sign with key
const signature = await Key.sign({
payload: "0x...",
privateKey: key.privateKey,
});
```
### WebAuthn Keys
```ts
// Create WebAuthn credential
const credential = await Key.createWebAuthnP256({
user: {
name: "alice@example.com",
displayName: "Alice",
},
});
// Use for signing
const webAuthnKey = Key.fromWebAuthnP256({
credential,
publicKey: credential.publicKey,
});
```
## Advanced Patterns
### Direct Provider Access
For maximum control, access the provider directly:
```ts
const provider = await rw.provider;
// Use JSON-RPC methods directly
const result = await provider.request({
method: "wallet_prepareCalls",
params: [{
calls: [{
to: "0x...",
data: "0x...",
}],
chainId: "0x...",
from: "0x...",
}],
});
```
### Session Key Signing
Sign transactions with session keys:
```ts
import { P256, Signature } from "ox";
// Prepare transaction
const { digest, ...request } = await provider.request({
method: "wallet_prepareCalls",
params: [{
calls: [...],
key: { publicKey, type: "p256" },
}],
});
// Sign with session key
const signature = Signature.toHex(
P256.sign({ payload: digest, privateKey })
);
// Send signed transaction
const result = await provider.request({
method: "wallet_sendPreparedCalls",
params: [{ ...request, signature }],
});
```
### Custom Actions
Create your own actions by extending Viem:
```ts
import { type Client } from "viem";
export async function myCustomAction(client: Client, params: any) {
return client.request({
method: "my_custom_method",
params,
});
}
// Use with client.extend()
const extendedClient = client.extend(() => ({
myCustomAction,
}));
await extendedClient.myCustomAction({ ... });
```
## WebSocket Support
For realtime updates, use WebSocket transport:
```ts
import { createPublicClient, webSocket } from "viem";
import { riseTestnet } from "viem/chains";
const wsClient = createPublicClient({
chain: riseTestnet,
transport: webSocket("wss://testnet.riselabs.xyz/ws"),
});
// Watch for events in realtime
wsClient.watchContractEvent({
address: "0x...",
abi: [...],
eventName: "Transfer",
onLogs: (logs) => {
console.log("Transfer events:", logs);
},
});
```
## Type Safety
RISE Wallet provides comprehensive TypeScript types:
```ts
import type { PermissionsRequest } from "rise-wallet/viem";
// All actions are fully typed
const permissions: PermissionsRequest = {
key: { publicKey: "...", type: "p256" },
expiry: 123456789,
permissions: {
calls: [{
to: "0x..." as const,
signature: "0x..." as const,
}],
},
};
```
## Error Handling
Handle Viem errors appropriately:
```ts
import { BaseError } from "viem";
try {
await Actions.sendTransaction(client, { ... });
} catch (error) {
if (error instanceof BaseError) {
console.error("Error name:", error.name);
console.error("Error details:", error.details);
console.error("Error version:", error.version);
}
}
```
## Best Practices
### 1. Use Action Modules
Import actions from their respective modules for better tree-shaking:
```ts
// Good
import { sendTransaction } from "viem/actions";
import { connect } from "rise-wallet/viem/WalletActions";
// Less optimal
import * as Actions from "viem/actions";
```
### 2. Handle Account State
Always check account connection before operations:
```ts
const accounts = await client.request({ method: "eth_accounts" });
if (!accounts.length) {
// Request connection first
await WalletActions.connect(client);
}
```
### 3. Optimize Gas
Use Viem's gas utilities:
```ts
const gasPrice = await client.getGasPrice();
const gasEstimate = await client.estimateGas({
to: "0x...",
data: "0x...",
});
```
## Examples
* [Basic Viem Usage](https://github.com/risechain/wallet-demo)
* [Session Key Implementation](/docs/rise-wallet/getting-started/session-keys)
* [Contract Interactions](/docs/rise-wallet/getting-started/minting)
## Related Documentation
* [Viem Documentation](https://viem.sh/)
* [Wagmi Integration](/docs/rise-wallet/integration/wagmi)
* [Porto Viem Docs](https://porto.sh/sdk/viem)
# Wagmi Integration (/docs/rise-wallet/wagmi)
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
This guide covers integrating RISE Wallet with [Wagmi](https://wagmi.sh/), the popular collection of React Hooks for Ethereum.
## Overview
RISE Wallet implements a Wagmi connector and provides custom React hooks that map directly to the wallet's capabilities. The integration is designed to feel natural to developers already familiar with Wagmi.
## Installation
```bash
npm i rise-wallet wagmi viem @tanstack/react-query
```
```bash
pnpm add rise-wallet wagmi viem @tanstack/react-query
```
```bash
yarn add rise-wallet wagmi viem @tanstack/react-query
```
```bash
bun add rise-wallet wagmi viem @tanstack/react-query
```
## Basic Setup
### 1. Configure the Rise Wallet Connector
```ts title="config/wagmi.ts"
import { Chains, RiseWallet } from "rise-wallet";
import { riseWallet } from "rise-wallet/wagmi";
import { createConfig, http } from "wagmi";
// Export the connector for advanced usage
export const rwConnector = riseWallet(RiseWallet.defaultConfig);
// Create wagmi config
export const config = createConfig({
chains: [Chains.riseTestnet],
connectors: [rwConnector],
transports: {
[Chains.riseTestnet.id]: http("https://testnet.riselabs.xyz"),
},
});
```
### 2. Set Up Providers
```tsx title="app/providers.tsx"
"use client";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { WagmiProvider } from "wagmi";
import { config } from "@/config/wagmi";
import { useState } from "react";
export function Providers({ children }: { children: React.ReactNode }) {
const [queryClient] = useState(() => new QueryClient());
return (
{children}
);
}
```
### 3. Wrap Your App in the Provider
Add the `Providers` component to your root layout:
```tsx title="app/layout.tsx"
import { Providers } from "./providers";
export default function RootLayout({
children,
}: {
children: React.ReactNode;
}) {
return (
{children}
);
}
```
## Standard Wagmi Hooks
All standard Wagmi hooks work seamlessly with RISE Wallet:
### Connection Management
```tsx title="components/WalletButton.tsx"
import { useConnect, useConnection, useDisconnect, useConnectors } from "wagmi";
export function WalletButton() {
const { address, isConnected } = useConnection();
const connect = useConnect();
const disconnect = useDisconnect();
const connectors = useConnectors();
if (isConnected) {
return (