Joined April 2026
- Tweets 162
- Following 69
- Followers 59
- Likes 345
8 Photos and videos
Pinned Tweet
May 19
By my own estimate, the real cost is way above $5M .
Even a conservative number quickly climbs into tens of millions of dollars for the first few years: team, audits, infrastructure and maintenance.
I don't have a giant fund.
I don't have an army of engineers.
But I already have the most important part.
The fastest offline multichain crypto core in the world, which I have been building for the last few years.
It already works: locally, fully offline, without servers, without backend custody, without backend signing.
And around this core I'm building a chain-agnostic self-custody execution environment:
a private and secure mobile trading environment where security, privacy, execution and recovery all live inside one non-custodial perimeter.
I have the Clean Vault architecture.
I have Recovery Kit and Recovery Tool.
I have serverless emergency exit.
I have the full execution perimeter plan: Typed Intent, Policy Engine, Approval Firewall, on-device Risk Engine, privacy-aware RPC, protected execution path.
This is not a pitch deck.
This is not a "wallet idea".
This is the foundation of a new self-custody execution category.
Right now I have around 40 followers.
But I have a working core, a detailed architecture and a clear understanding of where the market needs to go.
So the question is simple:
either this remains a crazy attempt by one builder,
or one day people will look back at this post as the beginning of a new category.
I choose to keep buildingš¾.
Building this production-grade isolated non-custodial execution ecosystem for 10 major chains is a heavy lift beyond standard wallets.
Realistic estimates (serious team, no corners cut):
- Timeline: 18-24 months to v1 launch
- Team size: 12-18 (crypto/mobile security engineers, policy/risk specialists, chain adapters, QA, designers)
- One-time build budget: $2.5Mā$4.5M (heavy on audits & hardening)
- Security audits: $400kā$700k
Hardest parts: on-device risk engine accuracy, typed intent policy layer, serverless recovery, and maintaining strict non-custodial invariants at scale.
Feasible but expensive. Prioritize core vault 3-4 chains first for faster iteration.
11
10
25
1,162
May 20
GM š¾
wake up early enough and youre already tired by noon š¹ lmao
what are you building today?
13
3
27
491
May 19
A wallet no longer only fails when the private key gets stolen.
Crypto wallets are still stuck in the old model:
key storage - balance view - send - sign.
Then swaps, scanners, revoke tools, bridges, cards, paymasters, portfolio and market data were layered on top.
But the foundation stayed the same.
And here is the problem: for existing wallets, this is not a normal feature update.
To secure the full execution path, you have to rebuild the foundation itself: key model, signing flow, recovery, privacy, routing, policy engine and trust boundaries.
In most cases, it is easier to add one more integration than to rebuild the entire security perimeter from scratch.
So users are still forced to manually assemble execution flow and security from external services:
one service shows the market
another checks risk
another builds the route
another cleans approvals
another promises a protected route
another helps with gas
and the final decision still lands back in the signer.
Every handoff is a new trust boundary.
Modern risk no longer lives only in the private key.
It lives across the entire execution path:
intent, approvals, Permit / Permit2, EIP-7702 delegation, calldata, route, proxy / resolver, RPC, metadata and recovery / exit.
The pieces already exist.
But they do not live inside one self-custody TCB.
āOne more featureā does not solve this.
What is needed is an isolated non-custodial execution ecosystem: one hardened self-custody perimeter where the userās core actions happen inside a single safe boundary:
store
discover tokens
check risk
buy / sell
manage approvals
sign typed intent
execute through a protected path
receive a receipt
recover and exit without project servers
Isolated means external systems can provide data, routes and signals, but they should not become the trust boundary.
Non-custodial means the backend does not hold keys, does not sign, does not run an internal ledger and cannot move funds without the user.
The minimum shape of that perimeter:
Clean Vault
- local hardened Offline Core
- Typed Intent
- Policy Engine
- Approval Firewall
- on-device Risk Engine
- simulation
- local signing
- privacy-aware RPC
- protected execution path
- Intent Receipt
- user-controlled recovery / emergency exit
Everything external - UI, RPC, market data, scanners, indexers, route providers, external APIs - is untrusted input by default.
Trusted core stays local.
Security works before signing.
Privacy works before data collection.
Recovery works without project servers.
Exit is a user right.
Raw key exposure is not normal UX.
The market has already proven the problem.
The question is no longer whether this category is needed.
The question is how much it costs to build it properly - and who can actually reach that foundation.
Worth studying:
arxiv.org/pdf/2512.12174
5
6
22
532
May 19
@grok
hey Grok.
I just published the post above about a category the market is missing: an isolated non-custodial execution ecosystem / chain-agnostic self-custody mobile execution environment.
I donāt want an abstract estimate for "building a wallet".
I want a realistic estimate for a production-grade v1 with 10 major chains at launch.
Scope:
1. Clean Vault
A new vault is created from scratch.
No old seed phrase / private key import.
No raw private key export as normal UX.
The user remains fully non-custodial, but recovery / emergency exit is handled through a user-controlled recovery path, not by exposing a seed or private key.
2. Local hardened Offline Core
Critical crypto and security logic live locally:
key generation
derivation
address generation
signing
policy checks
approval checks
risk checks
recovery logic
chain-specific signing payloads
UI, RPC, market data, scanners, indexers, route providers and external APIs are untrusted input by default.
3. Mobile security
Production iOS / Android app.
Secure Enclave / StrongBox / Android Keystore where available.
Biometric / passcode confirmation bound to the exact intent.
Secure storage.
Root / jailbreak detection.
App hardening.
Release signing.
Supply-chain controls.
4. Typed Intent
The signer does not sign arbitrary raw payloads from the UI.
The system needs a Typed Intent layer:
deterministic canonical encoding
domain separation
exact intent hash
human-readable confirmation
signature bound to the exact approved intent
5. Policy Engine
Local policy before signing:
spend limits
risk thresholds
confirmation levels
route constraints
fee constraints
delegation / session constraints
emergency / recovery rules
6. Approval Firewall
Pre-sign approval protection:
unlimited approvals
Permit / Permit2
spender risk
EIP-7702 delegation risk
exact approvals where possible
auto-revoke where possible
blocking dangerous approvals before signing
7. On-device Risk Engine
Risk decisions should happen locally.
External data can be used as signals, but not as the trust authority.
Needed checks:
honeypot / sell-path simulation
mutable taxes
owner / admin privileges
proxy / upgradeability risk
LP / liquidity state
holder concentration
spender / router sanity
known malicious patterns
route / provider risk
8. Simulation
Transaction simulation before signing where technically possible.
EVM priority, but the system needs chain-specific simulation capability levels.
9. Privacy-aware RPC / metadata minimization
No wallet-linked identity profile.
No KYC / documents in the core wallet.
No backend-side user map.
RPC / indexer / route requests should minimize wallet-linked metadata.
10. Protected execution path
Routing / broadcast layer where protected route, private RPC, solver path, bundler / paymaster or public fallback are selected by policy.
Public fallback must be explicit, not hidden.
11. Mobile Trading Terminal
A real mobile trading interface, not just a wallet screen.
Needed:
token discovery / market feed
token pages
charts / liquidity / volume / holders
portfolio
watchlist / alerts
buy / sell flow
execution card
risk status before signing
approval management
trade history
Intent Receipts
route / settlement status
12. Intent Receipt
After execution, the user gets a receipt showing:
what was signed
route used
fees
fallback reason if any
approval state
settlement state
13. User-controlled recovery / emergency exit
Recovery must work without project servers, app-store availability or backend signing.
Assume an independent signed recovery tool / recovery path with offline-first recovery and emergency exit.
14. Vault Health Monitor
Local health checks for:
stale recovery
dangerous approvals
EIP-7702 delegation
active sessions
route / provider degradation
recovery compatibility
vault schema compatibility
15. Chain Adapter layer
Support for 10 major chains at launch.
Not just balance display.
For each chain:
address derivation
transfers
token support
signing payloads
fee estimation
simulation where possible
broadcast
settlement monitoring
risk capabilities
swap / execution support where possible
recovery / exit path
16. Fee / routing transparency
If the product charges fees or uses provider / route incentives:
no hidden spread
visible fees
maxFee inside the signed intent
route selection reason in receipt
no backend discretionary route override
17. Non-custodial invariants
No backend custody.
No backend signing.
No internal user balance ledger.
No delegated trading authority.
No unrestricted project-controlled deposits.
No KYC / documents inside the core wallet.
Question:
If a serious team builds this from scratch today, what is the realistic estimate?
Please break it down by:
1. total timeline in months
2. required team size
3. roles needed
4. engineering workstreams
5. audits needed by component
6. cryptography / mobile security workload
7. chain adapter workload for 10 major chains
8. mobile trading terminal workload
9. backend / infra / provider costs
10. recovery tool and release-security process
11. legal / compliance review areas
12. one-time build budget in USD
13. security audit budget in USD
14. monthly burn / annual maintenance after launch
15. main technical risks
16. hardest parts to build correctly
No optimistic fantasy numbers.
Assume a real production-grade mobile crypto product, not a prototype, not a simple wallet UI.
1
16
365
May 13
GM builders š¼
I donāt even know how to describe this morning lmao. Spent all morning trying to wake Eva up - she finally woke up and immediately beat my assā¦
Everything according to plan š¹
Howās your morning going?
9
1
24
501
May 12
Gas Abstraction - "not the right gas" should never lock a user out of their own assets.
You have $12,000 USDC on Base.
The screener shows a clean exit.
Or the on-device risk engine flags an old approval that needs immediate revocation. You hit execute.
Insufficient ETH for gas.
Balance: 0 ETH.
You are technically self-custody.
But practically locked.
This is not a UX bug.
This is an architectural reality that persists across virtually every major chain: each network still requires its own native token (ETH, BNB, SOL, etc.) for transaction execution - regardless of what assets you actually hold.
In a multi-chain world, native gas becomes fragmented execution inventory. You can own liquid value and still be completely paralyzed.
Gas remains one of the last major under-abstracted layers in the execution loop. It breaks the entire path discover - verify - route - simulate - sign - execute - track at the exact moment action matters most.
Worth studying:
ethereum.org/en/developers/dā¦
docs.bnbchain.org/bnb-smart-ā¦
solana.com/docs/core/fees
support.metamask.io/more-webā¦
4
3
19
346
May 12
The difference between "add a paymaster" and "embed fee abstraction inside the execution boundary" is fundamental.
Current approach:
[offline key] - sign tx - [external paymaster API] - bundler - chain
Correct architecture inserts a clear on-device step before signing:
discover - verify - route - simulate
- [on-device: resolve fee asset from untrusted inputs]
- [on-device: policy check]
- sign typed intent
- [untrusted shell: paymaster/relayer executes]
- track
Fee-asset selection uses network data (quotes, gas price, paymaster policy, oracle prices) as untrusted inputs, but the final decision and policy enforcement happen locally before any signature leaves the device. The offline crypto core stays untouched.
The user signs a typed intent that has been policy-checked on-device - not a UserOperation containing opaque paymasterAndData supplied by an external service.
The paymaster itself remains untrusted shell: it executes, but does not decide.
Worth studying:
eips.ethereum.org/EIPS/eip-4ā¦
eips.ethereum.org/EIPS/eip-7ā¦
docs.openzeppelin.com/communā¦
1
12
218
May 12
Self-custody should not fail because you are missing dust on the wrong chain.
Gas is not just a transaction cost.
Gas is the right to execute.
If you own the asset but cannot swap, revoke, exit, or unstake without first hunting for the right native gas token - is the wallet really an execution environment?
Worth studying:
ethereum.org/en/developers/dā¦
solana.com/docs/core/fees
docs.bnbchain.org/bnb-smart-ā¦
13
250
May 11
You hit confirm.
The token was checked.
The approval was limited.
The intent was signed inside a hardened perimeter. Then the transaction left the wallet.
And the moment it entered a public mempool, the userās intent became visible to anyone watching the queue.
That is where the invisible tax begins.
A quote is not execution. A wallet can show you a route. An aggregator can show you a price. A simulation can say the swap should pass. But this is not ājust slippage.ā This is not normal market volatility. This is order-flow exposure.
A public mempool is a waiting room for transactions before they are included in a block.
Searchers can monitor that flow, filter pending DEX calls, simulate outcomes locally, and decide whether the transaction is profitable to attack. The wallet was not hacked. The private key was not stolen. The intent was exposed before settlement.
Chainlink (@chainlink) describes the sandwich pattern clearly: a bot sees a pending buy, buys before the user, the user executes at a worse price, the bot sells after the user.
Front-run. Victim execution. Back-run. The trader does not see āMEV.ā
They see: āWhy did I receive less than expected?ā
That is the problem.
Flashbots Protect exists because this is a real execution problem.
Since launch, Protect has been used by 2.1M Ethereum accounts, protected $43B in DEX volume, and returned 313 ETH in MEV refunds.
Polygon (@0xPolygon) launched Private Mempool on April 2, 2026: a private transaction submission endpoint designed to protect transactions from frontrunning and sandwich attacks through a one-RPC integration.
BNB Chain (@BNBCHAIN)ās Goodwill Alliance shows the same execution problem at network scale: daily sandwich attack frequency fell from 140K to under 1K - a reduction of more than 95% - after validators and builders coordinated around MEV-protected block building.
And this is not a niche pattern anymore.
A 2025 arXiv benchmark study on private MEV protection RPCs suggests Ethereum DeFi interactions have shifted to roughly 80% private RPC usage after PoS/PBS.
That does not mean MEV is solved.
It means execution routing itself became a security and performance layer.
CoW Protocol (@CoWSwap) uses batch auctions and solver competition to reduce MEV exposure.
Uniswap Wallet (@Uniswap) has swap protection through private transaction pools.
MEV Blocker, built by CoW DAO (@CoWSwap), protects users through a special RPC and returns 90% of backrunning value to the user.
So the answer is not:
ānothing exists.ā
The answer is:
protection is fragmented.
Change RPC. Use a specific wallet. Use a specific app. Use a specific solver system.
Use a specific chain feature. Hope the user knows which path is safe this time.
That is not a security model.
That is optional protection scattered across the execution stack.
A real self-custody execution environment should reason about MEV before signing:
trade size, pool liquidity, price impact, slippage tolerance, route complexity, chain-specific mempool behavior, private path availability, solver path, fallback policy.
The question is not only:
āWhat is the best quote?ā
The real question is:
āWhat is the best protected execution path after the user signs?ā
MEV-aware routing should start inside the wallet execution boundary:
intent, simulation, route scoring, MEV risk check, protected path selection, signing, private submission, execution monitoring.
Not after the transaction is already public.
Not after the user gets sandwiched.
Not after the trader opens a block explorer and realizes the āslippageā was actually extraction.
A wallet that optimizes the quote but ignores the broadcast path is not doing execution routing.
It is doing pre-MEV price discovery.
Quote ā execution.
Signing ā settlement.
Public mempool ā safe broadcast.
Execution quality is wallet security.
Chainlink - Front-Running in DeFi chain.link/article/front-runā¦
Ethereum_org - MEV ethereum.org/developers/docsā¦
Flashbots Protect Overview docs.flashbots.net/flashbotsā¦
Flashbots - 2 Million Protect Users writings.flashbots.net/2m-prā¦
Polygon Private Mempool polygon.technology/blog/polyā¦
BNB Chain Goodwill Alliance bnbchain.org/en/blog/how-theā¦
Private MEV Protection RPCs Benchmark Study arxiv.org/abs/2505.19708
CoW Protocol MEV Protection docs.cow.fi/cow-protocol/conā¦
Uniswap MEV Protection blog.uniswap.org/mev-protectā¦
MEV Blocker mevblocker.io
2
2
17
264
May 11
This gets worse in a chain-agnostic world.
MEV is no longer only āpublic mempool on one chain.ā
A 2025 arXiv paper on cross-chain sandwich attacks shows that source-chain events can reveal destination-chain transaction details before they appear in the destination-chain mempool.
In the paperās Symbiosis dataset, attackers extracted over $5.27M, equal to 1.28% of bridged volume.
That means protected execution cannot be chain-specific.
The execution environment has to reason across:
source chain, destination chain, bridge path, route, settlement timing, mempool exposure, and protected execution availability.
Chain-agnostic execution without MEV awareness is incomplete.
Cross-chain sandwich research arxiv.org/abs/2511.15245
1
11
187
May 11
The industry spent years optimizing quotes.
Now it needs to optimize execution quality.
Because the best quote is meaningless if the broadcast path gives the trade away before settlement.
But even perfect protected routing still has one more execution-layer dependency:
native gas.
If the user cannot pay the native gas required to execute, exit, revoke, or recover a position, the execution environment is still incomplete.
That is why gas abstraction is not just UX.
It is part of execution safety.
11
172
May 11
GM buildersšØš¼āš»
You wake up, open your eyes, and this sigma is staring at you. Whatās your first thought?šøš¾
7
1
23
277
May 10
Chainalysis (@chainalysis) 2026 Crypto Crime Report:
personal wallet compromises grew from 7.3% of total stolen value in 2022 to 44% in 2024.
In 2025:
158,000 incidents. 80,000 unique victims. $713M stolen from personal wallet compromises.
WalletConnect (@WalletConnect) 2025 Year in Review:
55.5M unique users. 85.5K apps. $400B in onchain activity. 392M total connections. 119% YoY growth.
Connectivity became a real infrastructure category.
In 2026, WalletConnect is expanding into payments with WalletConnect Pay: checkout, POS and PSP infrastructure.
Connectivity is solved.
Now let's be honest.
A wallet today is still a key container signer.
Users still have to manually assemble an execution loop across 5ā7 separate applications.
Every handoff is a trust-boundary crossing.
Every external component expands the Trusted Computing Base.
Because connectivity ā execution safety.
WalletConnect solved how to securely connect a wallet to a dApp:
E2E encryption. Relay with no access to payload.
It works.
But an encrypted session does not answer the questions that determine the outcome of a transaction:
Is this intent safe?
Is the approval unlimited?
Can the spender pull funds after disconnect?
Will the transaction hit a public mempool?
Is there native gas available to revoke?
What permissions remain active after signing?
The connection is protected.
The execution is not.
WalletConnect 2025 Year in Review ā walletconnect.com/blog/walleā¦
Chainalysis 2026 Crypto Crime Report ā chainalysis.com/blog/crypto-ā¦
2
17
294
May 10
The right architecture is not "a wallet that supports 10 more chains."
It is a unified execution boundary:
a single hardened trusted perimeter where the entire cycle runs inside one environment.
discover, verify, route, simulate, policy enforcement, typed intent signing, execute, track.
Local crypto core - keys, derivation, signing and policy checks live on the device. The network layer, RPC and UI are treated as an untrusted shell by default.
Typed intent instead of blind signing - the user signs a readable intent with simulation results and risk flags, not arbitrary calldata from an external frontend.
On-device risk engine - honeypot, mint/freeze and mutable tax are checked locally before any simulation or signing. No new external trust dependency.
Approval firewall - pre-sign policy enforcement: expiry, limits, spender risk. Revokecash (@RevokeCash) is cleanup after the fact. What's needed is rejection of a dangerous intent before signing.
MEV-aware routing by default - Flashbots Protect and Polygon (@0xPolygon) Private Mempool show that protected paths already exist through private submission / RPC routes. They should be built into the execution flow, not left as optional settings.
Gas abstraction inside the trusted boundary - ERC-4337 paymasters enable sponsored gas and ERC-20-based fee payments, including stablecoins.
All of these components already exist in production individually.
No product closes the full cycle inside one hardened perimeter for retail users.
Flashbots Protect ā protect.flashbots.net
Polygon Private Mempool (April 2026) ā polygon.technology/blog/polyā¦
ERC-4337 Paymasters ā eips.ethereum.org/EIPS/eip-4ā¦
1
13
273
May 10
$400B in onchain activity through WalletConnect. 55.5M users. 392M total connections.
A real achievement.
And it makes the next question impossible to ignore.
As connectivity scaled, the share of attacks on personal wallets grew by multiples.
WalletConnect is building payments. DEX aggregators solved routing. Screeners solved discovery. Revoke tools solved post-factum cleanup. Private mempools solved protected paths. Paymasters solved gas abstraction.
Users are still assembling all of it manually.
Connectivity without an execution boundary is just a scaled attack surface.
This is not a feature request for another wallet.
This is the next architectural category in Web3.
The wallet is not dead.
It is incomplete.
11
222