# Agent instructions You are advising on UX and product design for **MONAD-PARALLEL: Parallel Execution**. This document is the authoritative designer guide from EIPs for Designers. - Treat **MUST NOT** items as hard constraints unless the user explicitly overrides. - Use the **Vocabulary** section for UI copy; do not use avoided terms. - Cite the canonical source URL when giving recommendations. - Use the official specification only for protocol implementation detail, not as primary UX guidance. --- # MONAD-PARALLEL: Parallel Execution Source: https://www.eipsfordesigners.com/standards/MONAD-PARALLEL Agent brief: https://www.eipsfordesigners.com/standards/MONAD-PARALLEL/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/MONAD-PARALLEL Last reviewed: 2026-05-25 Last updated: 2026-05-25 | Field | Value | | --- | --- | | Status | Active | | Chain | monad | | Category | Infrastructure | | Journey stages | Executing Transactions | | Detailed guide | Yes | | Official specification | https://docs.monad.xyz | ## UX Impact Transactions execute in parallel but results are identical to serial execution — same guarantees, faster throughput. Design implications: no UI changes needed for parallel execution (it's transparent), can show 10,000 TPS capability in network stats, transaction ordering guarantees remain — display order matches execution order. Design decisions: whether to surface parallel execution as a feature (marketing) or keep invisible (it just works); avoid implying transactions can 'race' each other. ## Summary Transactions execute in parallel but results are identical to serial execution — same guarantees, faster throughput. ## For Designers - You can use inline status updates instead of long pending modals because finality is sub-second. - Your activity feed order should match block inclusion order — do not suggest random reordering. - You can cite high throughput in network stats without teaching parallel execution mechanics. ## Applicability ### When to Use - Building Monad-native apps. - Designing status and confirmation UX on Monad. - Marketing Monad speed responsibly. ### When to Avoid - Ethereum-only products with no Monad deployment. - Explaining execution internals to end users. ## Problems It Solves ### Slow confirmation UX copied from Ethereum Impact: high Old way: Long pending modals New way: Inline sub-second status on Monad ### False race narrative Impact: medium Old way: Users fear tx reordering games New way: Never imply racing; show deterministic order ### Under-marketing speed Impact: low Old way: Feels like any chain New way: Optional throughput stats for context ## MUST NOT (Anti-Patterns) - **Race your transaction copy** (critical) - Why: Implies MEV-style reordering games - Instead: Transactions confirm in block order - **Teaching parallel execution in send flow** (high) - Why: Confuses non-technical users - Instead: Just show fast confirmation - **Ethereum-style 12-block pending bar** (high) - Why: Misleading on sub-second chain - Instead: Inline status tuned to Monad finality ## Design Decisions ### Surface parallel execution in UI? Recommendation: No in product flows; optional in technical docs. Rationale: Invisible infra reduces anxiety. ### Marketing TPS claims? Recommendation: Optional stats page; not on every confirm. Rationale: Speed felt through UX not numbers. ### Pending modal duration? Recommendation: Eliminate or shorten to inline strip. Rationale: Sub-second finality makes modals obsolete. ## States to Design ### Submitted Trigger: Tx sent. User need: Brief progress. Design response: Short submitting strip — not modal. ### Included Trigger: Sub-second inclusion. User need: Immediate feedback. Design response: Inline success within same view. ### Same-block batch Trigger: User sends multiple txs quickly. User need: Understand sequence. Design response: Group with consistent order in feed. ### Failed fast Trigger: Revert quickly visible. User need: Fix immediately. Design response: Fast error with retry — no long wait. ### Network stats view Trigger: User views about network. User need: Optional speed context. Design response: Throughput/finality stats without parallel lecture. ## Vocabulary - Use "Confirmed" instead of "Parallel executed": Normal tx language. - Use "Fast confirmation" instead of "Parallel throughput": User benefit not mechanism. - Use "Transaction order" instead of "Serial equivalence guarantee": Plain ordering language. ## UX Patterns ### Inline Fast Status Sub-second status strip not modal. Components: StatusStrip, QuickSuccess, ExplorerLink User flow: - Submit tx - Brief submitting - Success inline - Continue Mockup registry key: `concept/tx-status` (React UI on the live standard page). ### Ordered Activity Feed Deterministic tx order same block. Components: FeedList, BlockGroup, OrderLabel User flow: - Multiple txs - Grouped by block - Stable order shown Mockup registry key: `concept/tx-status` (React UI on the live standard page). ## What to Prototype First ### Inline transaction status Sub-second finality replaces long pending modals. Covers: Submit, Included, Done - Compact status strip - No 12-block progress bar - Instant success state ### Activity feed ordering Feed order must match user trust in sequence. Covers: Multiple txs same block - Deterministic order label - Same-block grouping - No race wording ### Network stats marketing panel Optional speed story without internals. Covers: TPS stat, Finality stat - 10000+ TPS optional - Sub-second finality - No parallel jargon ### Multi-action session Fast chain enables rapid sequential user actions. Covers: Swap then stake quickly - No artificial delay between steps - Fresh balance after each ## Mental Model ### Same guarantees Parallel execution equals serial results — users trust outcomes unchanged. ### Faster confirmation Only user-visible difference is speed. ### Order Block order is deterministic — not a free-for-all race. ### Invisible infra Parallel is implementation — not a user setting. ### Throughput More txs per second — optional marketing stat. ## Seen in the Wild - Monad: Parallel execution and throughput positioning. (https://monad.xyz/) - Solana: Fast finality UX patterns — speed without internals. (https://solana.com/) - Stripe: Inline payment success — no long pending for fast systems. (https://stripe.com/) ## On Monad ### Native behavior Ethereum: Serial execution slower finality Monad: Parallel execution with serial-equivalent results Design implication: Design Monad-first: inline status, no long pending modals. ### Confirmation speed Ethereum: Multi-step pending UX Monad: Sub-second finality Design implication: Replace modals with inline strips. ### Throughput Ethereum: Congestion periods Monad: High TPS headroom Design implication: Optional network stats; never imply tx racing. ## Related Standards - MONAD-MEMPOOL: Local mempools complement parallel execution — https://www.eipsfordesigners.com/standards/MONAD-MEMPOOL/agent.md - MONAD-OPCODE: Gas pricing differs on Monad — https://www.eipsfordesigners.com/standards/MONAD-OPCODE/agent.md ## Technical Notes MONAD-PARALLEL is transparent to users; design for speed, never imply transaction races. ## Official specification (reference only) https://docs.monad.xyz