# Account abstraction for parlays across prediction markets *Cross-protocol permissions with EIP-7702 and EIP-8141 frames* By [accountless.eth](https://paragraph.com/@accountless) · 2026-05-09 --- 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): ![](https://storage.googleapis.com/papyrus_images/28be404d2bdcfc282647001ade298fb2a1e9f6e028817718adea4b9c5b8f06cd.png) User goals (account): ![](https://storage.googleapis.com/papyrus_images/8cffe27d91f6b53eba73833d758f30ca3d24c59503905eb86c655245013144e1.png) * * * 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: ![](https://storage.googleapis.com/papyrus_images/ee2fa92b9867daa94d8c04590f9c1d21f7d70f17c0a3b58a553c1ee2b0c28f87.png) $20 stake → $73 return vs. ~$38 on a single leg. The more legs, the lower the joint probability, the higher the multiplier. A 4-leg parlay at even odds is roughly 16:1. * * * **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. ![](https://storage.googleapis.com/papyrus_images/1f37e17d7bfb3e6beea064737204e54f88997dc3d44525a4aa154487f97b29d4.png) The house wraps all of this — it's the entity that prices, accepts, and settles the parlay. 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). ![](https://storage.googleapis.com/papyrus_images/5ef934ab2adc47dd10bc6de2b0e1d3bbddcd3c040cf403232db3aa63e69c0613.png) **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. ![](https://storage.googleapis.com/papyrus_images/5bdb10fd13735e0b0811a864c6f5123cb3a342736551fa7cbd6d50355a412291.png) Atomic Units Each step in the user journey maps back to one or more atomic units: ![](https://storage.googleapis.com/papyrus_images/6ef99a8811834d66fd935b1a3d087c17dc3817d97e7d990da0ab4230d37d2b5d.png) 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. ![](https://storage.googleapis.com/papyrus_images/c552b6e44226fdd0b2054bdf935df96551fb52fe2347ea872a83c545413c636d.png) * * * #### **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). ![](https://storage.googleapis.com/papyrus_images/8b583340b4aee04b16e8c570a432de687fd90accc5b9e68c5659339ea523928f.png) 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. ![](https://storage.googleapis.com/papyrus_images/de810d0c6c9fe4bb560c341fc52175275ff8352abefab0d23b652bcced96c7f3.png) * * * #### **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. ![](https://storage.googleapis.com/papyrus_images/84f3a39bac4382e33891c9e55ef8c32c93c20b4f8c9c0800da71a39d68f2fc82.png) **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)** ![](https://storage.googleapis.com/papyrus_images/048f5ce12c250b006bc5a312695accccd9a643cde652473b1e948dd34fd8cb42.png) **Option B: Frames / EIP-8141 (draft, Hegota H2 2026)** ![](https://storage.googleapis.com/papyrus_images/e3922a7763e1995240ae665268aa0c2e4a69e2bb37a50af69da49bcf8dd8a5f2.png) **Comparison:** ![](https://storage.googleapis.com/papyrus_images/78892aaa6d22cd36331be8d98d00bef7ad27719b6c739d06837115db15a00cca.png) **Unsolved in both:** ![](https://storage.googleapis.com/papyrus_images/5c7eaf278baf51ec597d56bb90ad1ff304c7c1bf10ce1073b7575c301bf3fd82.png) * * * **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:** ![](https://storage.googleapis.com/papyrus_images/b65416c8524f5b58c3051b2a1e669e128bf2faf7bb9d5868ecd39f9b42404d62.png) **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. ![](https://storage.googleapis.com/papyrus_images/cd7debb5b5e9476c8e7015874382f620d95d9f04066bcb980aa2e7b3420eea63.png) **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: ![](https://storage.googleapis.com/papyrus_images/b1c5eba2c3640007c1eb33cddbecaee3d0ecbf02d0e955c81f1fbf8e61ce7edf.png) 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: ![](https://storage.googleapis.com/papyrus_images/a64a0d7d37794bcb402f4aca52e9c9f4e6a0bd6916737164981ebdac6cb09bc6.png) 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:** ![](https://storage.googleapis.com/papyrus_images/6e92add3eab570e98786a823abee0fcd0e5ba79a2e82d47730151fda0fc09dd4.png) **Architecture the POC will explore — Option A (7702 + Smart Sessions):** ![](https://storage.googleapis.com/papyrus_images/0cbc3ec5b8b7425adb45c26b3e443d6bf7d4a6395c47569c98fb10813dd8aee1.png) **Architecture the POC will explore — Option B (Frames / EIP-8141):** ![](https://storage.googleapis.com/papyrus_images/a881fb1f8a895c5f489fc17df22860c352ee818575bdc1ddabb81c918f924428.png) **Settlement contract (shared by both options):** ![](https://storage.googleapis.com/papyrus_images/41870f29970450d5687ff3595f7dc55301c46f172fd7f4d8ff6eb8b2292a1b5b.png) **Success criteria:** ![](https://storage.googleapis.com/papyrus_images/ee24bd8b3019bd2fa738ca702766a7e1071982c10fede5d0a55a1573097d0d87.png) #### **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. --- *Originally published on [accountless.eth](https://paragraph.com/@accountless/account-abstraction-for-parlays-across-prediction-markets)*