Narrow L1

1. Abstract

Narrow is an object-centric Layer 1 written in Rust. Its long-term product thesis is simple: blockchains should feel native to games — inventories, currencies, match settlements, studio-issued assets, and player-to-player transfers — without forcing studios and players through finance-first UX, unpredictable fees, or account-map mental models that fight how games already think about items.

Today Narrow runs as a public testnet with a full stack in production form: Proof-of-Authority consensus with quorum certificates, a versioned object store, NAR gas, NR20 issuer-controlled assets, HTTP RPC, explorer (“Narrow Scan”), browser and mobile wallet surfaces, escrow, package publish/call, offload jobs, and an optional Sepolia ↔ Narrow ETH/WETH bridge path (trusted-relayer design for testnet).

This paper describes the vision, the architecture as implemented in the codebase, honest performance characteristics of the current testnet, provisional NAR economics, security assumptions, gaming use cases, and a roadmap from today’s network toward game-grade throughput and developer tooling. Vision is not the same as present capacity: Narrow does not claim to be a AAA multiplayer settlement layer at current block parameters.

2. Vision — a chain for games

Games first. Friction last. Players should tip a teammate, claim a reward, trade an item, or cash out a currency with the same clarity they expect from an inventory screen — not a brokerage workflow. Studios should mint, burn, and govern in-game assets with explicit issuer authority, inspectable state, and bridges when value must cross ecosystems.

Narrow’s north star is a settlement and ownership layer for:

• Players — portable inventories, wallets that sign locally, readable explorers
• Studios — issuer-controlled assets, escrow and settlement primitives, RPC they can automate
• Markets — fair, inspectable transfers of fungible and discrete objects
• Bridges — paths for value to enter and leave without opaque custody theater

The object model is the strategic bet: digital assets behave like owned things (coins, packages, jobs, shared escrows), which maps cleanly to game inventories, rather than only to exchange-style account balances.

3. Problem — games meet blockchains

Games that try to put economy on-chain repeatedly collide with the same friction:

Latency and throughput

Sessions are short. Players abandon flows that wait tens of seconds for a tip or loot claim. High-frequency game loops (ticks, combat micro-actions) cannot live on a slow global ledger; even settlement of match outcomes and marketplace trades needs predictable finality windows measured in seconds or less for modern expectations — and orders of magnitude more transactions per second than a small PoA demo block can absorb when every player action is a chain write.

Fees and fee chaos

Congested general-purpose L1s produce fee spikes that break microtransactions and in-game currencies. Studios need fee schedules that are boring and budgetable — especially for gas paid on behalf of players.

Custody and UX

Seed phrases, bridges, and explorer jargon are hostile to mainstream players. Non-custody is still the right security model for true ownership, but the product must hide complexity until the user asks for it.

Wrong state shape

Account-balance maps and allowance systems (approve / transferFrom) were built for DeFi composition, not for “this sword is mine until I transfer the object.” Games think in discrete items and capabilities; many chains force studios to fake that on top of balances.

4. Solution — Narrow’s approach

Narrow attacks those gaps along four axes:

1. Object-centric execution — versioned objects with explicit ownership; transactions declare inputs and commands; conflicts surface as version races (as in escrow claim/cancel).
2. Native gas + issuer assets — NAR pays gas for every command; NR20 gives studios mint authority without ERC-20-style allowances.
3. Full product surface — wallet (local signing where possible), explorer, faucet for onboarding, RPC, optional bridge — so “try the chain” is not a CLI-only exercise.
4. Honest staging — ship a controllable PoA public testnet now; road-map parallel execution, faster blocks, fee markets, and game SDKs toward game-grade capacity rather than marketing today’s defaults as AAA throughput.

5. Architecture

The reference node stack (crate layout) is:

Users / Wallet UI ── RPC / Explorer
        │
   Mempool/P2P ── Executor (object store) ── Bridge / Offload helpers
        │                    │
        └── PoA consensus ◄── state root
                 │
        Certified blocks (disk + tx index)

Transaction path

1. Client builds a signed transaction (inputs + commands + gas_budget).
2. Tx enters the mempool and may gossip over P2P.
3. Round-robin leader proposes a block (up to max_txs).
4. Validators vote; a quorum certificate (≥2/3 voting power) commits the block.
5. Executor applies transactions against the object store; explorer/RPC index updates.

6. Consensus

The reference testnet uses a small permissioned Proof-of-Authority validator set (typically three validators) with a HotStuff-inspired propose / vote / quorum-certificate flow:

• Round-robin leaders propose blocks when the configured block interval has elapsed.
• Quorum — commit requires ≥2/3 voting power.
• Equivocation guard — a validator’s second conflicting vote at a height is rejected.
• Leader timeout / view-change — a stalled leader does not freeze the height forever; leadership rotates to a backup view.
• Timestamp bounds — blocks too far in the future or past are rejected.
• Signed Hello — P2P identity is bound to validator keys (chain id + nonce + address).

There is no bonded stake or slashing in this PoA model: misbehavior is rejected cryptographically and operationally, not economically punished. That is appropriate for a controllable public testnet and is an explicit gap versus a decentralized mainnet security budget.

7. Runtime & object model

Objects

State is a store of versioned objects. Common shapes include native NAR coins, typed NR20 coins, packages, offload jobs, NR20 asset registry objects, and shared escrows (owner = shared address). Transactions must cite input object references at the expected version; concurrent mutation of the same object fails with a version conflict.

Commands (illustrative)

The executor understands transfers, pay/split/merge style coin ops, mint, publish/call, offload submit/settle, escrow create/claim/cancel, bridge mint/burn, and NR20 create/mint/burn — among others. Gas is charged up front from a sender NAR coin.

Parallelism today

The runtime exposes a conflict helper (may_parallelize): two transactions from different senders that touch disjoint input object sets are marked non-conflicting for scheduling. Block application today still executes transactions sequentially after signature verification. Object-level conflict detection is the foundation for future parallel execution — it is not yet a multi-threaded production scheduler.

8. Performance characteristics & testnet reality

Default node configuration in code (overridable per deployment):

Path to game-grade performance (targets, not promises)

• Shorter block times (sub-second to ~1s class) with safe QC latency
• Higher max_txs / block packing and mempool scheduling by object conflicts
• True parallel execution of non-overlapping object sets
• Optional session / channel patterns so hot gameplay stays off the global critical path while settlements settle on L1
• Fee markets or studio-sponsored gas that remain predictable under load

9. NAR economics (provisional)

NAR is the native coin of Narrow L1. It is not an NR20 asset. Gas for every transaction is paid in NAR.

• Gas — flat base of 1 NAR per transaction, plus size-based surcharges for heavy payloads (publish, call args, offload, bridge strings, etc.), currently on the order of 1 gas unit per 64 bytes of counted payload.
• Display max supply — policy constant 100,000,000 NAR for explorer readability on the public testnet; circulating supply is derived from coin objects.
• Faucet — public faucet mints with a 200 NAR lifetime cap per address for onboarding (rate-limited).
• Sepolia bridge fee (when used) — Narrow→Sepolia path burns a fixed 5 NAR fee to a fee sink in addition to gas; Sepolia→Narrow deposit charges a fixed ETH fee in the bridge contract (see bridge docs).

Provisional: There is no finalized mainnet token sale, emissions schedule, staking rewards, or governance tokenomics in this document. Do not invent or assume investment terms from testnet faucet policy. Future mainnet economics will be published separately if and when they exist.

10. NR20 assets

NR20 is Narrow’s native issued fungible-asset model. It is deliberately not an ERC-20 port:

• A shared registry object 0x3::nr20::Asset holds symbol, name, decimals, logo key, issuer, total supply, and version.
• Balances are owned coin objects with type tags such as 0x3::nr20::{SYMBOL}.
• Only the recorded issuer may mint; holders may burn their own coins.
• No approve / transferFrom — ownership is the object; conditional third-party flows use escrow (or future composition) instead of allowances.
• A symbol is either bridge-wrapped or NR20 issuer-minted — not both — to keep supply single-sourced.

Testnet genesis may pre-register symbols labeled as Narrow test assets. Names like WBTC / WETH on testnet do not imply verified collateral of external mainnets unless a documented bridge path is actually operating for that asset.

11. Wallet, explorer, and bridge

Wallet

The public wallet UI (web and Capacitor mobile shell) creates or imports an account, protects an encrypted seed with a passcode, and for plain NAR sends can sign locally with WebCrypto Ed25519 so the raw secret key need not leave the browser for that path. Advanced flows may use additional RPC endpoints subject to node policy (allow_remote_sign, optional RPC token).

Live wallet: https://testwallet.narrowl1.com

Explorer

Narrow Scan exposes blocks, transactions, accounts, and detail views over the same RPC surface operators run on validators.

Live explorer: https://testexplorer.narrowl1.com

Bridge

Narrow includes bridge-oriented commands and RPC. A documented Sepolia ↔ Narrow ETH/WETH path uses a lock/mint and burn/release design with a trusted relayer for testnet (relayer/issuer can mint; burn receipts gate release). Simulated lock/mint helpers also exist for demos without an external chain. Treat bridge trust assumptions as part of the security model — not as a fully trust-minimized light-client bridge.

Useful RPC families

Health/status, account and transaction queries, faucet/send, bridge deposit/withdraw and receipts, package publish/call, offload run/submit/settle, escrow create/claim/cancel, NR20 create/mint/burn, plus broadcast of pre-signed transactions.

12. Security model

What the testnet hardens

• Consensus: equivocation rejection, leader timeouts, timestamp checks
• Mempool: caps on total txs, bytes, and per-sender pending queue
• P2P: signed hellos, max connections, per-IP caps, accept-rate limiting
• RPC: per-IP rate limits (tighter on sensitive paths), configurable CORS, optional RPC token for privileged remote-sign writes
• Runtime: faucet and bridge mint caps; gas scaling with payload size; withdraw proofs after on-chain burn
• Storage: periodic state checkpoints; restart replays from last checkpoint
• Wallet: passcode-protected encrypted seed (8-digit minimum for new/changed passcodes)

Explicit limitations

• No TLS on raw node P2P/RPC — operators should terminate TLS at a reverse proxy for public endpoints.
• No economic slashing — PoA trust is in the operator set.
• Bridge relayer trust on Sepolia path — compromise of relayer/issuer keys is catastrophic for that bridge.
• Public ledger — addresses and txs are inspectable; privacy is not a protocol feature.
• No claim of third-party security audit or guaranteed mainnet readiness in this paper.

13. Gaming use cases

Given the object model and issuer assets, near-term (testnet / early partners) fits:

Studios evaluating Narrow should prototype economy and custody flows on testnet now, and plan hot gameplay off-chain or on future session layers — not expect the current block cadence to replace a game server.

14. Roadmap

Indicative, not a contractual delivery schedule:

1. Now — Public testnet — PoA validators, wallet, explorer, NAR/NR20, escrow, packages, offload, optional Sepolia bridge, community Telegram.
2. Next — Game developer surface — sample game SDKs / Unity or web clients, richer asset/NFT metadata, indexing APIs, performance harnesses, shorter block-time experiments on dedicated nets.
3. Then — Throughput & fees — parallel execution of non-conflicting object sets, higher packing, fee-market or sponsored-gas designs that stay predictable for studios.
4. Later — Production bridges & partners — harden custody and relayer/attestation models; invite studio partners; evolve validator set and incentives toward a production security model when ready.

15. Links & contact

• Website — https://narrowl1.com
• Wallet — https://testwallet.narrowl1.com
• Explorer — https://testexplorer.narrowl1.com
• Privacy — Privacy Policy
• Telegram channel — @narrowchain_official
• Telegram group — @narrowchain_group
• Support — [email protected]

Team and incorporation details may expand in later editions. No fictitious auditors, TVL figures, or partners are listed here.

16. Disclaimer

This document describes software and a public testnet. Nothing herein is an offer to sell securities, an investment recommendation, or a promise of mainnet token value. Testnet assets have no guaranteed real-world value. Always back up your seed phrase; Narrow cannot recover lost keys. Bridges and future features described as roadmap are not live production guarantees until separately shipped, documented, and (where appropriate) reviewed. Use the network at your own risk.