Summary: Frame-o-lays

A parlay is one wager made of multiple independent predictions (legs) — all legs must win or you lose the full stake. Payouts multiply because joint probability is lower. $20 on a 4-leg parlay can return $300 vs ~$40 for a single bet. Parlays are the highest-margin, most-viral bet type in sports betting, and every major platform now offers some version.

The problem: every onchain parlay implementation is siloed within a single protocol. Polymarket has pre-built parlay markets. Kalshi has RFQ combos. SX Bet has P2P parlays. Third-party layers like PredictShark, Clutch, and Pandora add custom parlays on top of Polymarket. None of them let you pick legs across protocols — a Polymarket election leg, a Kalshi weather leg, and an Azuro NBA leg in one parlay, settled by one contract. Nobody is building cross-protocol parlays with a unified permission and execution layer. The EIP-7702/8141 angle is completely unexplored in this space.

Frame-o-lays is a research framework for cross-protocol onchain parlays, and proofs-of-concept to demonstrate what is possible. We standardize the parlay primitives (market, outcome, leg, stake, settlement) into one composable interface, and make the onboarding as thin as possible — connect wallet, deposit, go. We explore how EIP-8141 frames and onchain permission systems can enable a user to delegate parlay execution across multiple prediction market protocols in one transaction. We break down the parlay into its atomic units, map the user journey across four platform types, identify where onchain prediction markets fail at each step, and evaluate two solution architectures — one live today (EIP-7702 + Smart Sessions) and one in draft (EIP-8141 Frames). This document is the foundation for a proof of concept.

We also believe that building this will expand what is possible with onchain permissions beyond parlays. The permission patterns required here — scoped delegation across multiple contracts, batched execution under one authorization, time-bound and value-capped access — are not parlay-specific. They are general-purpose. If we can get a user to grant one permission that atomically executes across Polymarket, Azuro, and a settlement contract, that same pattern works for any cross-protocol workflow: DeFi strategies across lending and DEX protocols, multi-step DAO governance, coordinated NFT operations. Parlays are the use case. The permission layer is the infrastructure.

Table of contents

1. User goals

2. What is a parlay?

3. Atomic units

4. How parlays work offchain and onchain

5. User journey

6. Permission systems

7. Account journey

8. Parlay problems

9. Account problems

10. Solutions

11. POC

1. User

College kids, young professionals, and crypto degens. They bet on FanDuel, DraftKings, or a local sportsbook for NFL, NBA, UFC, and prop bets. They also hold stablecoins or ETH and take

positions on Polymarket, Kalshi, or Limitless.

The user has two sets of goals — one for the parlay itself (finding markets, building the bet, getting paid) and one for the account layer underneath (identity, permissions, gas). Every

problem in this document maps back to one of these goals.

User goals (parlay):

User goals (account):

2. What is a parlay?

A parlay is a single wager that chains multiple independent bets (legs) together. Every leg must hit or you lose the full stake. The tradeoff: higher risk for multiplicative payouts, since you're

betting on the joint probability of all outcomes.

Simple math:

3. Atomic units

Every parlay — whether it's a paper card at a casino window or a smart contract on Polygon — is made of the same seven building blocks. Understanding these units is critical because Frame-o-lays needs to standardize them into one composable interface across protocols that each implement them differently.

Parlay

├── Stake (one)

├── Leg 1 → Outcome → Market

├── Leg 2 → Outcome → Market

├── Leg 3 → Outcome → Market

└── Settlement (all legs must resolve WIN)

4. How parlays work offchain and onchain

Parlays exist across four platform types today — casinos, sportsbook apps, onchain sports protocols, and prediction markets. The table below shows which parlay types each supports. The key gap: prediction markets have no standard parlays, only workarounds (pre-built markets, RFQ combos, third-party layers).

Onchain sports betting protocols

Azuro, Overtime, and SX Bet are closer to traditional sportsbooks but decentralized. The key difference: a liquidity pool acts as the house — LPs deposit funds and collectively take the other side of all bets. Odds are set algorithmically by AMMs, not by order book. Azuro and Overtime both support parlays natively. SX Bet launched peer-to-peer parlays with market makers pricing combined outcomes.

Prediction markets (onchain)

Polymarket, Kalshi, and Limitless are peer-to-peer order books where users buy binary outcome shares ($0–$1). No house — every buyer has a seller. Odds emerge from supply/demand. Originally none of them offered parlays. All three major platforms have taken different approaches:

• Polymarket (Nov 2025): pre-built parlay markets — not user-built. Polymarket compresses several linked conditions into a single binary yes/no contract. Users buy shares that pay $1 if ALL legs hit, $0 otherwise. Users cannot freely combine arbitrary markets into custom parlays. Incentive program: propose a parlay idea that hits $1M volume, get $300.

• Kalshi (Sep 2025): custom same-game parlays via RFQ model. User submits a combo, institutional market makers price the other side in real time. Each combo gets its own order book. Grew from negligible to over 20% of weekly sports volume during March Madness 2026. Robinhood announced custom sports parlays brokered through Kalshi's RFQ system.

• SX Bet (Oct 2025): first peer-to-peer parlays. Bettors build cross-event tickets, API-connected market makers compete to price combined outcomes. Stakes held in smart contract escrow, payouts settle onchain. 5% fee on winning parlay tickets, 3% on cross-chain bets.

• Limitless: no parlay feature. Focused on short-term fast price markets on Base.

Third-party parlay layers (on top of Polymarket):

• PredictShark (Polygon, native USDC) — combine multiple Polymarket events into single bets with exponential payouts

• Clutch — first fully onchain decentralized parlay platform, combining Polymarket + sports + political predictions on Arbitrum and ApeChain

• BetStack — sequential parlays with live cashout on top of Polymarket

• Pandora Parlays — build parlays from any Polymarket market, up to 420x multipliers, deployed on Polygon

5. User journey

The table below maps the full user journey across all four platform types. The pattern is clear: the top half (access through funding) is where all the friction and fragmentation lives. The bottom half (bet slip through withdrawal) is structurally identical everywhere — a leg is a leg, settlement is binary. A Frame-o-lays POC will standardize the bottom half into one composable interface and makes the top half as thin as possible.

Atomic Units

Each step in the user journey maps back to one or more atomic units:

The two halves:

Top half (house-gated): access, account, KYC, geolocation, funding — this is where every system is different and where all the friction lives. Casino needs physical presence. FanDuel needs SSN. Prediction markets need a wallet + USDC on the right chain. This is the onboarding tax.

Bottom half (parlay primitives): market, outcome, leg, stake, parlay, settlement - these are structurally identical everywhere. A leg is a leg. An outcome is an outcome. Settlement is binary. The mechanics don't change, only the implementation does (paper card vs. bet slip vs. smart contract).

Frame-o-lays: A POC will standardize the bottom half into one composable interface, and make the top half as thin as possible (connect wallet, deposit, go).

6. Permission systems

To build cross-protocol parlays, the user needs to delegate execution across multiple contracts on multiple chains in one action. The table below maps every relevant onchain permission system - what account type it requires, how it handles auth, permissions, execution, token approvals, and gas. This is the design space for Frame-o-lays.

7. Account journey

Each account type is an anchor — it constrains what permission, execution, and gas systems are compatible. Pick the anchor, the rest follows. We evaluate four stacks: 7702 (the most practical today), Safe (the most deployed smart account), Tempo (a new L1 with native abstractions), and Frames (the most elegant design, but not live).

Stack A: EOA → 7702 → 7710/7715 → 7579 sessions → 4337 UserOps → Permit2

Stack B: Safe → Safe7579 → Module auth → Session Keys → execFromModule → Permit2

Stack C: Tempo account → Access Key → Scoped auth → Native tx → Native approval

Stack D: Any account → VERIFY frame → APPROVE → SENDER frames (atomic) → PAYER frame

8. Parlay problems

These are the structural gaps in onchain prediction markets mapped against the parlay user journey. Every row is a step where the user experience breaks down because no protocol has solved cross-protocol coordination.

9. Account problems

The account layer is where each solution stack meets real-world constraints. The table below evaluates each of the four stacks against the seven account-level problems. No stack solves everything — identity and privacy are unsolved across the board, and cross-chain execution remains non-atomic in every approach.

Cross-chain problems:

Polymarket is on Polygon. Limitless is on Base. Azuro is on Gnosis/Base/Polygon. True atomic execution across chains is not possible today.

1. Same-chain subset — If two protocols share a chain (e.g., Limitless + Azuro on Base), batch atomically via 7702 + 4337

2. Parallel execution — User grants permissions once (7715), backend holds multichain session keys (Biconomy), submits parallel UserOps to bundlers on each chain. Not atomic, but one user action.

10. Solutions

Key takeaway: everyone is building parlays as a feature within a single protocol. Polymarket has pre-built parlay markets. Kalshi has RFQ combos. SX Bet has P2P parlays. Third-party layers (PredictShark, Clutch, Pandora) add custom parlays on top of Polymarket. But nobody is building cross-protocol parlays with a unified permission and execution layer — pick legs from Polymarket, Kalshi, Azuro, and Overtime in one parlay, settled by one contract. The EIP-7702/8141 angle is completely unexplored in this space.

We evaluate two architectures. Option A is buildable today using live standards. Option B is the cleaner design but depends on EIP-8141 shipping (Hegota H2 2026). Both solve the same-chain case. Neither solves cross-chain atomicity — that remains an open problem.

Option A: 7702 + Smart Sessions (live today)

Option B: Frames / EIP-8141 (draft, Hegota H2 2026)

Comparison:

Unsolved in both:

11. POC: Frame-o-lays

The POC will test whether the solvable problems identified in this document are actually solvable — same-chain cross-protocol parlays with unified permissions, atomic execution, one token approval, and gas abstraction. Everything in the "unsolved" bucket (cross-chain atomicity, privacy, identity, oracle coordination) will be explicitly out of scope. The POC will implement both solution architectures: Option A (EIP-7702 + Smart Sessions) will ship first since it uses live standards. Option B (EIP-8141 Frames) will ship when Hegota launches (H2 2026) and will explore the cleaner design. Both will target a single chain where two or more prediction market protocols coexist.

Objective: the POC will show that a user can connect an existing wallet, grant scoped permissions once, build a parlay with legs from multiple prediction market protocols, and execute all bets atomically in one transaction — with gas sponsored and tokens approved once. It will validate this across both the 7702 stack (live) and the 8141 Frames stack (draft), showing how the same parlay primitives map to each architecture.

Scope:

What the POC will solve:

The POC will directly address the parlay problems (section 8) and account problems (section 9) that are solvable today. Each row maps a current gap to what the POC will deliver.

The payout problem:

Stitching bets together across protocols in one atomic transaction is not a parlay — it's a batch of independent bets. A real parlay means one stake with a multiplicative payout. The difference is massive:

The user wants $320, not $40. The multiplier is the entire point. To deliver multiplicative payouts, someone has to take the other side of the combined bet — a counterparty who holds the risk that all legs hit simultaneously.

The POC will explore three counterparty models:

All three models share the same settlement contract — the counterparty model determines who funds the payout, not how the parlay resolves. The POC will start with the liquidity pool model (simplest to implement as a smart contract) and will explore the RFQ model as a stretch goal.

What the POC will not solve:

Architecture the POC will explore — Option A (7702 + Smart Sessions):

Architecture the POC will explore — Option B (Frames / EIP-8141):

Settlement contract (shared by both options):

Success criteria:

Conclusion

This document breaks down cross-protocol onchain parlays into their smallest parts — the atomic units, the user journey, the permission systems, the account stacks, the problems, and the solutions. Every piece is now mapped. The parlay primitives are defined. The account journey stacks are evaluated. The solvable problems are separated from the unsolved ones. The POC scope, architecture, counterparty models, and success criteria are laid out.

None of this requires us specifically to build it. Anyone with the right smart contract and account abstraction experience could pick up this document and execute the POC. The standards are live (7702, 7715, 7710, 7579, 4337, Permit2). The prediction market protocols are deployed. The design space is mapped. We may build all of it, some of it, or none of it — but the contribution of this document is that now we know exactly what needs to be built, why it doesn't exist yet, and what the first working version looks like.

The gap in the market is clear: everyone is building parlays inside their own protocol. Nobody is building the cross-protocol layer with a unified permission and execution model. Whether it's us or someone else, this is what the architecture looks like.

We also believe that building this will expand what is possible with onchain permissions beyond parlays. The permission patterns required here — scoped delegation across multiple contracts, batched execution under one authorization, time-bound and value-capped access — are not parlay-specific. They are general-purpose. If we can get a user to grant one permission that atomically executes across Polymarket, Azuro, and a settlement contract, that same pattern works for any cross-protocol workflow: DeFi strategies across lending and DEX protocols, multi-step DAO governance, coordinated NFT operations. Parlays are the use case. The permission layer is the infrastructure.

1. product definition

account abstraction (aa) is a meaningful step forward for onchain users — but the more accounts a user accumulates, the harder their onchain existence becomes — and the irony is they need offchain accounts to access most of their onchain ones. a universal account manager starts where aa leaves off — not at the account level, but at the graph level: the complete surface of who you are online, onchain and off.

this document defines requirements for a standalone tool that serves as the single place a user manages any set of accounts, and any type of accounts they control — onchain and off. it captures new accounts as they're created, maps the credentials that protect them, monitors their security over time, propagates changes across chains and services, and models what breaks if something goes wrong.

not a wallet. not a dapp browser. not a password manager replacement (though it layers on top of one). a new category: the account graph. the prototype is a desktop extension.

key features

try the prototype

2. user

power user who manages multiple online identities, credentials, and accounts across web2 (offchain) and web3 (onchain). maintains eoas, smart contract wallets, passkeys, hardware keys, session keys, multisig configs, and traditional web2 logins. operates across multiple chains and services.

3. goals

users managing online and onchain accounts share five goals — whether they hold two accounts or two hundred, and on one chain or many.

4. how user experience is today

web2 credentials live in a password manager. web3 keys live in wallet apps, sometimes backed up as seed phrases. smart wallet signer configs live onchain per deployment per chain. session keys are granted per dapp and tracked nowhere. recovery setups are configured per wallet per chain with no unified view.

when the user creates a new web2 account, the password manager catches it. when the user creates a new web3 account onchain, nothing catches it.

5. bad outcomes

today, users navigating web2 and web3 accounts face a set of failures that no single wallet or password manager or aa infrastructure prevents.

6. problems

these problems aren't just security risks — they're productivity losses. without situational awareness across accounts and credentials, users spend time on manual tracking, miss exposures, and can't act on changes efficiently.

7. causes

each problem traces to a root cause — tools that were built for one side of the user's identity and never designed to see the other.

8. solutions

a universal account manager addresses each cause with a corresponding solution — bridging the gap between web2 and web3 tooling into one surface.

9. object model

the core object is an account — a relationship between the user and a service, chain, or protocol.

10. non-requirements

11. scope

the prototype was built iteratively across four versions.

• v1 established the core data model and browsing.

• v2 added security awareness.

• v3 introduced write operations

• v4 extended the model toward identity interoperability — verified credentials with w3c vc fields, correlation tracking across shared credentials, profile creation, and import/export using the w3c universal wallet 2020 spec.

  each version built on the last without replacing it.

12. prototype

the prototype simulates a chrome extension side panel running alongside a web page. the demo loads a simulated metamask portfolio page — token balances, tabs, a connected address — to show how the extension detects the current site and offers to capture or update account data in context.

clicking the extension icon in the toolbar opens the side panel directly. the prototype is a single HTML file built with react and typescript, deployed to github pages.

all data is local and simulated — no backend, no chain calls, no real credentials. write operations like rotate and revoke simulate the walletconnect signing flow with progress animations.

the prototype is meant to demonstrate the interaction model, not the infrastructure.

try the prototype

crypto should be your daily driver. not a vault. not something you check once a quarter. something you actually spend.

but crypto is hard to spend. you can't hide your balance. you can't separate your money from your identity. one breach drains everything. building credit is impossible.

machines fixes this. we give you control over what you have and credit for what you do. what is machines? virtual Visa credit cards with private payments — for humans and agents to spend and build credit.

who this is for

you already use crypto. you have multiple wallets. you farm, you earn, you trade, you run agents. you want to spend without exposing yourself. you want to build credit without going into debt.

the problem with spending crypto

exposed with public payments: when you share an address to pay someone, you're sharing your balance, your history, and your future activity. nobody wants to pay for coffee and accidentally leak their bank statement.

at risk mixing saving and spending: mixing funding and spending is dangerous. your wallet doubles as a spend account. one breach, one malicious dapp, one compromised extension—all your money is gone. reusing the same wallet or card links everything together. your activity becomes searchable.

time kills convenience: your money is scattered across accounts. you have to worry about bridging. converting. funding new accounts. it all takes time. there's no way to organize, automate, or separate.

lock-in is the default: neobanks, wallets, payment apps—they all sit in the middle. they hold your money. they manage the rails. they act on your behalf. you're dependent on them.

the solution for spending crypto

we separate what you have from what you spend.

privacy with relays. every deposit goes to a unique, single-use address. from there it relays to a separate spending account. your main wallet stays hidden. when you withdraw, the money goes to a new single-use address and relays to wherever you want it. the blockchain can't link your spending to your savings.

security with separation. create unlimited virtual visa cards. set spend limits per card. assign each card to different activities. one breach doesn't drain everything. one card compromised doesn't expose the rest. you control the blast radius.

productivity with ease. use any crypto. btc, monero, zcash, sol, tron, usdt, usdc, eth—whatever you hold. the system swaps it automatically. spend in seconds. recurring payments are one-tap. organize with labels and reminders. search by merchant or amount. track your spending. it just works.

control without lock-in. your existing wallet signs every critical action. machines doesn't hold your money. machines doesn't authorize on your behalf. you stay in control. for spending, not saving.

the problem with credit

banks own it. $250 billion in credit card interest flows to banks every year. users can't access it. users can't earn from it. credit is bundled—ownership, capital, risk pricing. there's no modular entry point. you can't use just the parts you want.

debt is the price. building credit requires underwriting. underwriting requires lending risk. lending risk requires debt. credit reporting requires carrying a balance. you have to go into debt to prove you're creditworthy. it's broken.

onchain credit doesn't exist. income signals don't work onchain. credit scoring is built for humans, not agents. there's no way to verify cashflow from multiple sources. credit only works in the traditional system.

the solution is open credit

machines doesn't lend. capital is external and permissionless. anyone can supply capital and earn yield. behavior, income, and capital are separated and programmable. this is open infrastructure, not a closed system.

credit without debt. every transaction uses a credit line. repayment is immediate. you build credit history without carrying a balance, without interest, without going into debt. we verify your cashflow onchain to size your credit line (Metro 2 compatible). no credit pulls. no damage to your score. no debt.

credit for humans and agents. we combine your card behavior and your onchain yield streams as verified income. the system is programmable. it works for you whether you're trading, farming, or running agents.

try machines

machines is for people who already use crypto. we're not here to convince you to use it. we're here to make it actually usable. spend without exposing yourself. build credit without going into debt. stay in control.

architecture

infrastructure

features

Table of Contents

1. TLDR

   • custody is never absolute

   • where we are today

   • what to do then

2. DETAILS

   • onchain user experience

   • access and control

   • users have to go online to go onchain

3. Services, Apps, Accounts, Wallets

   • services

   • apps

   • accounts (internet + onchain)

   • wallets (types and roles)

4. Secrets

   • secrets

   • key actions

   • seed phrases

     • lifecycle

     • properties

5. Abstraction Layers

   • account types (internet, eoa, multisig, smart contracts, aa)

   • addresses

   • networks

6. User Problems

   • key management problems

   • access issues

   • control issues

   • layers of friction

   • secret formats

7. User Needs

   • access needs

   • control needs

8. Key Management Principles

9. Mix and match example method for stronger custody

10. Who actually needs this?

    • comparison to Apple’s advanced data protection

TLDR

here is a way to think about self-custody as you create products for users, market products to users, and consider products yourself as a user.

nothing in life is 100% — happiness, uptime, health, or security. custody can’t be either.

where are we today?

• ethereum requires externally-owned accounts (EOAs) to initiate transactions. each EOA is tied to a single key pair. every abstraction still depends on that one signer — it can’t rotate, can’t revoke, and never expires.

• wallets use a seed phrase to derive every child key and address. the seed phrase cannot change and if leaked all sub accounts are lost. it’s also 12-24 words that must be input in the correct order.

• smart wallets don’t let you export a smart account into another wallet. a smart account you cannot port is vendor lock-in and high risk— the opposite of smart, and actually worse than an eoa.

• smart wallets distribute keys with providers: with Privy for shamir secret sharing, and with others for MPC. shares often sit in Amazon or other clouds. they still call this self custody. it’s more like distributed and shared custody.

• recovery is fragile. in self-custody you must re-import your seed phrase exactly — lose it and it’s gone. in provider custody you wait for reset approval, locked out until they say yes.

• recovery providers also rely on apple and google app stores; aws nitro and other tee. if delisted, your account gets even harder to reach.

what to do then?

don’t rely on a single eoa key that never rotates. don’t rely on a smart wallet you cannot port.

use pure eoas for burners or daily spenders. don’t use them for anything seriously of financial or emotional value.

for real security, consider some mix of eoa, mpc/tss, and smart wallets because you will have and need them all in some way.

DETAILS

onchain user experience is account management is key management is access and control. the user journey in crypto is based on keys, that are really just secrets protecting user accounts from unauthorized access and control, and guaranteeing users access and control of their accounts.

access and control

every screen tap or click first authenticates (access) with a secret and authorizes (control) the action. users tap screens and press buttons with secrets—device pins, passwords, oauth tokens, seed phrases. each tap requires access, then control.

key management covers all these secrets, not just onchain seed phrases. creating, storing, rotating, and recovering passcodes, passwords, tokens, keys, and account metadata is core to both productivity and security. doing this takes more than a wallet and more than steps. it takes devices, networks, services, and apps—layers.

users have to go online to go onchain

users connect, sign in, and use services to reach onchain transactions. they move from being online to executing onchain transactions through layers.

services

to reach onchain, users must: connect to a network, unlock a device, launch an os and data-sync service, open a wallet app or extension, and reach an identity provider.

apps

software delivers these services, secured by credentials and profile metadata. apps run on devices or browsers for email, storage, messaging, browsing, and more. each app requires its own account and secret.

accounts

each service requires its own account—isp profile, device login, apple/google id, cloud-storage login, wallet login, oauth account. every account needs at least one secret: device pin or biometric, account password, oauth token, seed phrase, or private key.

users need distinct accounts for every service and every onchain address. accounts hold usernames, settings, permissions, and metadata. users create, import, recover, and export accounts across chains.

• internet (offchain) accounts: network provider, os, data-sync, wallet app, identity provider. secured with pins, passwords, oauth. recovery depends on the service.

• onchain accounts: ethereum, bitcoin, solana, and others use externally owned accounts (eoas). an eoa is one static key pair from a seed phrase. only eoas can initiate and pay for transactions. eoas cannot rotate or revoke keys if compromised.

wallets

all wallets are apps. all apps have accounts. therefore wallets are not accounts. wallets let users control accounts.

wallets generate, store, and use cryptographic secrets to bridge users into onchain accounts. they store seed phrases or private keys and provide interfaces to sign transactions, view balances, update settings, and recover access.

wallet types include:

• digital wallets (offchain): apple wallet, google wallet, no blockchain keys

• software wallets: mobile, desktop, web

• hardware wallets: air-gapped key storage

• multisig wallets: multiple keys per transaction

• smart-contract wallets: recovery, limits, role permissions, tied to eoa

• watch-only wallets: monitor balances without keys

secrets

every account relies on at least one secret: pin, password, oauth token, seed phrase, or private key.

key actions:

• create when setting up

• store in secure location (enclave, vault, manager)

• rotate to limit exposure

• back up and recover to prevent loss

seed phrases

a seed phrase is a 12–24 word bip-39 mnemonic that backs up your single master key and drives every onchain account you create. each word represents 11 bits of entropy from a fixed list of 2,048 words. words are easier to write, read, and speak aloud than raw numbers.

wallets use a seed phrase to derive every child key and address via hierarchical deterministic paths. you generate the phrase, derive keys and addresses, encrypt and store your keys, access your account by importing the phrase or keystore, unlock keys for signing, and use your private key to sign onchain transactions.

a seed phrase is not magic words—it is a human-readable encoding of a binary number (your entropy). instead of a 256-bit string like:

5f2b8c9a3d4e1f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0

you get 12–24 words like:

tiger battery emerge puzzle until flash track whale among happy tail

seed phrase lifecycle

• generate: create the 12–24 word bip-39 mnemonic

• derive: run pbkdf2 + bip-32/44 to produce master and child private keys and addresses

• store: encrypt keys locally; back up the seed phrase manually or in the cloud

• access: import or recover your wallet using the seed phrase or encrypted keystore

• control: unlock keys for signing and other key-management tasks

• sign: use the private key to produce an onchain signature

seed phrase properties

• immutable: phrase never changes once created

• sole secret: one mnemonic backs up every derived key and address

• hierarchical: one seed generates all sub-accounts via defined derivation paths

• multi-chain: same phrase works across every supported blockchain

• no metadata: encodes entropy only, no chain or account labels

• manual transcription: must write or type all 12–24 words exactly

• sequential entry: recovery prompts for each word in order

• phishing risk: typing or pasting the phrase exposes it to malicious sites

abstraction layers

developers wrap extra logic around static-key models—masking but not solving rotation and single-point-failure risks. smart-contract logic and offchain services simplify ux, but they don’t change the blockchain’s core rules. underlying keys stay static, so rotation is impossible and single points of failure remain.

account types

• internet account: use oauth/pki keys for offchain login → can’t initiate onchain transactions

• externally owned account (eoa): one static key → no rotation, same key forever

• multisig: multiple static keys for threshold signing → still no native rotation

• smart-contract account: wrap eoa in a contract, require onchain calls for auth → still depends on one eoa key

• smart-contract wallet: bind eoa to one app; add recovery, limits, permissions → can’t export or import between wallets

• erc-4337 (account abstraction): add user-ops, bundlers, paymasters to abstract gas and execution → underlying keys remain static

• eip-7702 (set code for aa): embed a temporary smart account per transaction → eoa key still controls everything

• eip-7701 (native aa): separate signing and fee payment into protocol modules → not yet in core protocol

addresses

onchain addresses are public identifiers for sending and receiving assets. each address derives from a private key or seed phrase via a defined path. generating a seed phrase creates a hierarchy of addresses across chains. managing addresses requires tracking which seed produced each address, verifying them before use, and backing up the seed phrase to recover all addresses.

networks

each blockchain applies its own derivation paths and transaction rules to addresses. ethereum, bitcoin, solana, and others use distinct formats and paths, but they can share the same seed phrase.

wallets apply network-specific rules (bip-44, custom prefixes) to derive valid addresses. users must select the correct network, know which keys and paths apply, and store network configurations alongside their seed to ensure they sign with the right key on the right chain.

user problems

key management problems

seed phrases are bad because they secure all sub accounts. they are worse because that seedphrase can’t rotate. they are harder to use for access and easier to lose control of sub accounts.

access

• hard to use online: seed phrases are long, unusual text strings—difficult to type, copy, paste, or enter securely. usage is manual and error-prone.

• no familiar login options: users expect to sign in with email, phone, or social accounts—not a random phrase.

• no metadata or context: seed phrases carry no account info, labels, or preferences. apps and wallets can’t display context without external metadata.

• no secret manager: no decentralized account or secrets manager exists for crypto users, who manage secrets for multiple accounts across different tools and storage methods. 1password does have a crypto wallet field.

control

• single point of failure: one phrase controls all accounts. if lost or stolen, user loses access or attacker gains control of everything.

• no rotation: the phrase never changes. you can’t issue new keys without starting over. every use increases exposure.

• lifecycle risk: the phrase is used to create, store, recover, and sign. exposure at any step compromises all tied functions.

• no transaction privacy: all transactions from one key are publicly visible and linkable—no way to split or shield identities.

• no message encryption: private key signs transactions but doesn’t encrypt messages or data. apps can verify authenticity but not protect content.

• must start over: if compromised, users must create a new phrase, migrate funds, and reset every account and integration.

layers

1. go online to go onchain: each step adds friction and risk—network, device, login, app

2. services: repeated authentication across services

3. apps: secrets and settings stored locally, fragmented across platforms

4. wallets: combine app, account, and key roles—hard to separate, confusing to manage

5. accounts: each isolated; create, recover, and manage independently

6. secrets: manual backup and protection required; one leak compromises all

7. seed phrases: hard to use, easy to lose, never change—exposing all accounts

8. abstraction layers: wrappers improve ux but static-key risks remain

9. addresses: users don’t control derivation or reuse. no metadata, no grouping

10. networks: each chain has different formats and paths—reuse is risky, recovery is complex

secret formats

• seed phrase: single point of failure; loss or leak compromises all accounts

• private key: hard to store securely, manual management, easy to leak or paste

• keystore (json): requires strong password and secure storage; format can be misused or corrupted

• passkey: tied to platform ecosystems (icloud, google); limited portability and recovery

• oauth token: often stored in browser memory; hijacking or theft risk

• pin / passcode: easy to guess or reuse; device compromise exposes access

• biometric (face id): convenient but non-revocable; spoofing or hardware failure can block access. sunlight can increases error rate and time to use

user needs

access

users need a consistent way to reach accounts and services across devices—without resetting credentials or repeating logins.

• connect to wi-fi or mobile data → public networks are risky; devices and sessions are easy to hijack. users need a private connection that avoids public wi-fi risks.

• unlock phone or laptop → pins and biometrics can be weak or shared. users need strong local auth that only works for them.

• log into cloud or os account → these logins hold secrets but aren’t designed for that. users need system auth that treats os and cloud sign-in as part of key security.

• open an app and sign in → every app has its own login; nothing carries over. users need at least one identity they can use across wallets and apps.

• launch a session and use wallet → sessions don’t persist; users get logged out. users need persistent sessions that keep state alive without sacrificing security.

• recover an account or app → recovery requires hunting down codes or phrases. users need built-in recovery through trusted devices or contacts.

control

users need a safe way to manage secrets and use accounts across apps—without exposing a single key or starting over.

• write down a seed phrase → one phrase controls everything; if lost or exposed, everything’s gone. users need scoped secrets that are replaceable and limited.

• store secrets on devices or in the cloud → easy to misplace or expose; no standard way to do it. users need reliable, automatic, encrypted backups.

• sign a transaction → every signature uses the full key; nothing rotates or expires. users need rotating keys with temporary or scoped authority.

• share access with someone → no safe way to share; it’s all or nothing. users need delegated access without full exposure.

• import or export an account → seed phrases don’t rotate; sub-accounts can’t move. users need portable accounts that can import, export, and isolate.

• copy and paste addresses → addresses are long, confusing, and error-prone. users need human-readable identifiers that are safe and verifiable.

• switch devices or wallets → nothing transfers cleanly; users must start over. users need continuity so accounts, secrets, and sessions move across devices.

key management principles

• no seed phrase required, ever

• your key is split into secure shares using mpc

• shares are never stored whole and never reconstructed

• you can import, upgrade, or recover at any time

• you can rotate in place and keep the same address

• you can sign online and offline, on device and off device

• you can have custody on devices with no provider holding shares

• you can have custody on network with no devices holding shares

• you have choice—you can move up and down the custody spectrum

no system is perfect and so you’ll likely mix and match. for example, here is one method for getting closer to self custody without a seed phrase.

• start w single key pair eoa bc ofc you have one. upgrade it to mpc. use a protocol that lets you import seedphrase and upgrade to mpc and export to private key.

• use an mpc protocol has threshold signature schemes, and that’s lets you rotate in place, like dkls23

• find a provider that allows users to sign online and offline, add devices and remove providers, like dkls23, with Silent Shard by Silence Labs; and used in production by VultiSig.

• then, run N ceremonies till you get to your mathematically acceptable level of security, online and offline, on device and off device, same address or new address. there you go.

• now, export to private key if you wish, no seedphrase. choose your own methods for handling the exported private key, rinse and repeat before securing the account.

  who actually needs all this? ask Apple, they have a version too. Advanced Data Protection and Recovery Keys “With Advanced Data Protection enabled, Apple doesn't have the encryption keys needed to help you recover your end-to-end encrypted data. If you ever lose access to your account, you’ll need to use one of your account recovery methods.” and “Your account recovery methods are never shared with or known to Apple.”