Following up on my previous posts regarding the Account-Lattice and the RPC impedance mismatch with standard EVM wallets: I have completely bypassed the need for a custom JSON-RPC endpoint extensions.
Benchmarking bare-metal node physics against real-world client implementations exposed the fundamental limitations of monolithic EVM design and indexer reliance. To achieve planetary scale without data center hardware, we must stop trying to execute transactions faster and instead eliminate global state I/O and shared lock contention altogether.
The Local-First Sovereign Wallet (WIP Prototype)
Below is an interim snapshot of the self-contained client:
Note on current state: This is an in-between WIP build before committing the latest batch of changes.
-
Zero Middleware: Connects directly to standard EVM wallets (e.g. Rabby) without custom RPC extension wrappers. Sadly we cannot serve it over
file://, I already created an issue for that on the Rabby Github to address this in terms to become decentralized and sovereign. -
DID Anchoring: Maps the legacy EVM address directly to the
did:pkhordid:sovereignwhen did is registered and tracks the key tier natively. (Legacy/Classic, Quantum Proof, High Trust etc.) -
Local Sandbox Storage: Uses the modern FileSystem Access API as the primary storage engine to directly manage sandboxed local state and post-quantum keys (with the legacy File API kept strictly as a backward-compatibility fallback with Ponyfills).
-
Cross-Chain Intents for NFT sales: The marketplace interface will natively reflect external chain assets (Arbitrum ETH, Base USDC, Gnosis EURe etc.), feeding into the Based Mesh Syncing detailed below. So we can accept anything on anything, getting it swapped to whatever we want. (Most likely EURe on Gnosis, if it doesn’t execute the EEZ)
Zero-Middleware EVM Compatibility: The System Address Illusion
Instead of fighting brittle legacy wallet UI heuristics, I am leveraging standard EVM EIP-1352 low-entropy address reservations.
Standard Web3 wallets interact seamlessly via vanilla eth_sendRawTransaction by targeting specific system precompiles (e.g.):
| Reserved System Address | Operation | REVM Execution Hook |
|---|---|---|
0x00...0002 |
Inbox Sweep | Validates floating receive proof, credits lattice leaf, waives gas. |
0x00...0003 |
DID Registry | Commits DID payload to the user’s local sequence thread. |
0x00...0004 |
Intent Router | Initiates an async Saga Escrow Sub-Leaf. |
The Result: The wallet extension sees standard contract interactions (e.g., from: Alice, to: 0x00...0002) and renders clean “Success” receipts, bypassing $0$-value self-send UI bugs. We achieve 100% native EVM wallet UX without proprietary RPC extensions.
(Note: While the base layer natively supports post-quantum ML-DSA key mapping and other curves, registering a PQ key via a legacy EVM wallet flags the metadata with a Secp256k1Wrapped transport security warning, explicitly warning the user that their PQ key is temporarily bottlenecked by the classical envelope’s vulnerability during transport).
O(1) Stateless Account-Lattices
We abandon the monolithic global Merkle Patricia Trie entirely. Every account is its own independent state thread.
-
Local-First State: State storage moves directly to the user’s local client (via the FileSystem Access API).
-
Stateless Node Physics: The validator network holds zero user state. Nodes simply validate ZK/polynomial vector witness proofs in pure O(1) time.
-
Infinite Parallelism: Because accounts do not share a global lock, millions of independent lattice updates process asynchronously. If a specific contract bottlenecks, the blast radius is confined entirely to that contract’s thread and the touched accounts. I may need to add a CALL etc. rejection to accounts. That could use the same jurisdictional mechanisms. So users can make sure their own Contract Accounts don’t get locked due to external CALLs into them.
Asynchronous Saga Intents (Replacing Synchronous CALLs)
The legacy EVM breaks parallel execution by forcing synchronous, atomic cross-contract locks (CALL, DELEGATECALL). We replace this with Asynchronous Saga Intents with Actor message queuing:
-
Non-Blocking Escrow: Account A locks tokens into a temporary Escrow Sub-Leaf targeting Contract B. Account A’s main sequence thread continues operating freely.
-
Epoch Expiration: The lock is anchored to an expiration Epoch checkpoint.
-
Stateless Refunds: If Contract B fails to claim the intent by the target Epoch, Account A submits a local refund block containing a ZK Absence Proof (a non-inclusion proof showing Contract B never executed). The zkEVM engine validates the proof and unlocks the escrow in a single cycle.
Single-Cycle DAO Compliance via Bitmasking
We decouple policy setting from policy enforcement. A DAO is no longer a massive, gas-heavy smart contract storing authorized user lists; it is simply an independent account leaf publishing a compact policy bitmask.
-
User Leaf: Contains a 256-bit credential mask (e.g.
Bit 0: Clean OFAC,Bit 2: DAO Merit Tier). -
Hardware-Speed Validation: When a user interacts with a governed system, they submit a witness proof linking their leaf to the DAO’s policy root. The revm should evaluate compliance in a single CPU cycle.
-
This guarantees compliance at the engine level before bytecode execution, immune to RPC bypassing.
The Global Clock: Epoch Checkpoints & Verifiable Merit
To synchronize time across asynchronous account threads without a blocking global block counter, I am using Chandy-Lamport Epoch Checkpoints. Accumulating the deltas into one checked state root.
(Ironically, this is similar to what IOTA used to do, but we do it fully decentralized with snow family consensus and no ternary bs. Since we have the math for it now, we can actually do it.)
-
Epoch Anchors: The rotating validator set continuously emits signed Epoch checkpoints, acting as the decentralized temporal anchor for Intent timeouts and sub-committee consensus rounds, legacy smart contract support for block-counting etc.
-
TinyMeritRank Commits: At designated Epochs, dedicated Merit Committees evaluate verifiable work graphs. The deterministic
TinyMeritRankgraph is computed and committed as a state vector root, statelessly distributing merit-based token allocations to account leaves (reflected as “Merit Rank” in the UI). -
Sybil Resistance: Admission to Sync, Jurisdiction, and Merit sub-committees is gated strictly by this Merit Score, entirely replacing capital-heavy, centralized PoS lockups with verifiable skin-in-the-game. You need to participate in the network with merit before you can run a validator ndoe. (e.g. through code contributions, marketing or whatever the network considers a real merit.)
Reverse Shadow Contracts & Based Mesh Syncing
For cross-chain composability (like a local NFT marketplace that bridges to OpenSea etc.), we do not anchor to a single external chain. We form an unanchored Based Mesh Network.
-
The Reverse Shadow Pattern: Canonical assets live natively on the Sovereign Lattice. A lightweight “Shadow Contract” is deployed to a legacy chain (e.g. Base) to access liquidity venues like OpenSea. Reverse, because while the Contract is just a Shadow to the native one, it has exclusive right to write certain parameter into the native contract. e.g. owner of NFT.
-
Sync Committees: When a shadow asset is burned on Base, our rotating Sync Committees observe the event. They construct the stateless inclusion proof and instantly unlock the canonical asset on the Sovereign Lattice.
-
Arbitrage, routing, and relayer speeds are left entirely to open market competition among the validators. You can even generate a proof on older state roots, as long as the sync-committee can confirm, via Snowflake consensus, that the proof is still valid aka the account slot hasn’t changed.
@GhostAgent I have yet to check how this all plays into your AI Agent NFT stuff though. I also saw your point about SIWE on discord. Will answer later to it.