Implementation / limitations / roadmap
The sportsbook.
The facts.
SPORTSBEEP is a centrally operated sportsbook application with Cardano wallet integration and approved-token balances. Wagers and account balances are managed by the application; supported deposits and withdrawals use Cardano transactions.
This document describes the current implementation, not a certification of production readiness. Implemented means functionality exists in the application. Incomplete identifies work still required. Research is not an operating feature or a delivery commitment. Availability depends on deployment configuration, providers, and legal requirements.
Implemented architecture
What SportsBeep is
A sportsbook-focused web application, not a fully decentralized betting protocol.
- Application layer: Accounts, wager records, token balances, and administrative tools are maintained by the server and its database.
- Cardano integration: Wallet ownership verification and transaction services connect the application to Cardano. A blockchain transaction is not created for every wager or internal balance update.
- Operator responsibility: The platform operates the application, controls its treasury processes, configures enabled assets, and depends on external services for blockchain and sports data.
- Current scope: Sportsbook only. MLB and NFL fantasy functionality is disabled and deferred. Historical records are retained; a future rebuild is separate from the current launch.
Implemented interface / incomplete coverage
Sports & availability
A league tab or team logo does not establish that real betting markets are available.
- Existing sportsbook interface: MLB, NFL, NBA, and NHL sections exist. The current ESPN polling service fetches MLB; complete live-market coverage across the other sports is not established.
- Directory-only sections: MMA, NCAA Football, NCAA Men's Basketball, MLS, English Premier League, and Bundesliga (Germany) display league information and available branding. Wager submissions for these sections are currently blocked.
- MMA coverage: The directory currently identifies UFC as a promotion within MMA. It does not represent all promotions or a verified fighter roster.
- Names and logos: Team directories are sourced snapshots, not fixture schedules. Missing source logos are not replaced with invented branding. Listings do not imply league or team endorsement.
Implemented components / launch restrictions
How wagering works
The application records a wager against an available in-app balance. Wallet holdings alone are not an available stake.
- Existing components: The interface includes moneyline, spread, and total selections, a bet slip, and a My Wagers view. Parlay-related code also exists; complete parlay settlement is unfinished.
- Stake accounting: Approved-token wagers use the balance for the selected enabled asset. The application records the stake, selection, odds, and potential payout; a displayed potential payout is not a guaranteed payment.
- Acceptance must be verified: Reliable provider-backed prices, server-side market validation, and rejection of unavailable or stale selections are launch requirements. The current interface alone does not establish those guarantees.
- Not yet supported: The new directory leagues must remain unavailable for wagering until their markets and outcome rules are supported. Soccer draws and MMA bout outcomes cannot simply inherit another sport's grading rules.
Implemented flows / operational verification required
Wallets, balances & custody
Connecting a personal wallet does not make deposited platform funds self-custodied.
- Connect: The browser-wallet flow requests a signed challenge to verify control of an address. Wallet compatibility must be tested for each supported browser and wallet version. The platform should never request a user's recovery phrase.
- Deposit: The on-chain deposit flow builds a transfer to the configured platform treasury for wallet approval. Confirmation processing verifies deposits before crediting the internal balance. A submitted transaction is not the same as a confirmed deposit.
- Custody: Tokens sent to the platform treasury are controlled through the platform's treasury signing infrastructure, not held in a per-wager user-controlled escrow contract. The internal balance is a platform accounting record, not a separate wallet address.
- Winnings: Settlement can credit the in-app balance. An internal credit does not itself transfer tokens to the user's external wallet.
- Withdrawal: The on-chain withdrawal flow requests a treasury payment and tracks its status. Execution depends on configuration, sufficient token and ADA funding, provider availability, and chain confirmation. Instant withdrawals are not guaranteed.
- Uncertain transactions: A timeout is not proof that a transfer failed. Reconciliation and safe handling of unresolved payouts remain essential operational work; duplicate payments or premature refunds must be prevented.
Implemented asset controls / disclosures pending
$BEEP & approved tokens
$BEEP is part of the platform's token model. Enabled assets are administrator-configured; not every Cardano token is accepted.
- Asset identity: A ticker or logo is not sufficient identification. Cardano native assets must be matched by policy ID and asset name, with the correct decimal precision.
- Balances: Approved assets have separate in-app balances. Holding an unrelated token with the same displayed ticker does not establish eligibility or credit.
- Disclosures still required: Publish verified $BEEP identity, supply, minting restrictions, allocations, vesting, treasury arrangements, and any confirmed liquidity arrangements before relying on them in launch materials. This document does not assert values that have not been verified.
- Fees: No fixed 1% treasury fee is established by this whitepaper. Platform charges and Cardano transaction costs must be documented accurately and disclosed before approval; the earlier illustrative fee is not a current commitment.
- No investment promise: Token support does not imply guaranteed liquidity, appreciation, yield, governance rights, or a right to platform revenue.
Incomplete / launch blockers
Odds, results & settlement
The existence of a bet slip and score-grading code does not establish an end-to-end, reliable sportsbook.
- Known pricing limitation: Legacy code can generate random fallback prices or matchups when real data is absent. These are not verified betting markets. Removing this behavior and refusing unavailable markets is a prerequisite for genuine wagering.
- Existing settlement logic: Score-based routines can grade supported wagers, credit wins, and refund pushes. Database locking and status checks help prevent repeated settlement; they do not validate the external result itself.
- Results pipeline: Authoritative final results, stable event identifiers, correction handling, and scheduled settlement need completion and operational verification. This whitepaper does not promise fully automatic payouts.
- Rules still required: Define and implement postponements, cancellations, abandoned events, no contests, draws, overtime treatment, pushes, and parlay outcomes for each supported market.
- Disputes and corrections: Document the result source, settlement timing, correction policy, and support process before launch. Unresolved cases must not be silently treated as final.
Implemented safeguards / assurance pending
Security & operator control
Cardano confirms on-chain transfers; it does not independently verify the platform's odds, database balances, or sports results.
- Application safeguards: Account authentication, wallet ownership checks, token-specific balance validation, and transaction records are implemented components. They are not proof that the entire platform has passed an independent security audit.
- Administrative access: Administrators manage enabled tokens and operational settings and can inspect user, wager, wallet, and financial activity. These are centralized powers, not token-holder governance.
- Operational work: Treasury access policies, signing-key protection, permissions, backups, recovery drills, reconciliation, monitoring, and incident response need documented procedures and verification.
- Assurance limits: This document makes no claim of audited betting smart contracts, guaranteed reserves, insurance, formal verification, or uninterrupted service.
Legal review & enforcement required
Eligibility & user risks
Wallet ownership does not prove age, location, identity, or legal eligibility to gamble.
- Jurisdiction: Required authorization and permissible markets depend on where the operator and users are located. The presence of a website or a league listing does not establish permission to accept wagers there.
- Launch requirements: Obtain jurisdiction-specific legal review and implement the resulting age, location, identity, and other applicable controls. No operating Identus verification or comprehensive compliance system is claimed here.
- Responsible gambling: Appropriate limits, self-exclusion, access restrictions, and support procedures must be defined and implemented where required. This document does not represent these protections as already complete.
- Financial risk: Wagered funds may be lost. Tokens may lose value or become illiquid. Treasury shortfalls, software errors, compromised credentials, provider failures, and chain delays can affect access to funds.
- Terms and privacy: Published terms, settlement rules, privacy practices, and dispute procedures must match the deployed service. A general disclaimer cannot replace those obligations.
Planned / no guaranteed release dates
Development roadmap
Release decisions should follow verified functionality and applicable approvals, not an assumed launch calendar.
- Market integrity: Remove synthetic fallback data, validate available markets and prices server-side, and establish dependable provider coverage.
- Settlement readiness: Complete final-results ingestion, scheduling, sport-specific grading, parlay and exceptional-event rules, and auditable correction procedures.
- Funds and operations: Verify deposits, withdrawals, uncertain-payment handling, treasury reconciliation, account recovery, and production monitoring.
- Launch controls: Complete required legal review, eligibility enforcement, responsible-gambling controls, security review, and token and fee disclosures.
- League expansion: Enable directory-only leagues individually after their data, market rules, and settlement paths are ready. Branding alone does not satisfy this milestone.
- Later work: MLB and NFL fantasy remain deferred until after sportsbook launch and a separate decision to rebuild. Research below does not alter the current sportsbook-only scope.
Research only / not integrated
Cardano research appendix
These ideas are optional investigations, not current platform capabilities, partnerships, funding awards, or promised releases.
- Identus: Potential credential-based identity research; not an implemented age or location verification system.
- Marlowe and Plutus / Plinth: Possible contract-design research. Current wagering and grading run in the application, not deployed betting validators.
- Midnight: Potential privacy research; no integrated private-wager or zero-knowledge verification feature is claimed.
- Catalyst: A possible funding avenue, with no grant award or application outcome asserted.
- Daedalus and other wallet tooling: Possible development and testing tools, not user requirements. Browser-wallet support is a separate integration and testing concern.
- RealFi: Historical lending research only. Borrowing to wager and automated loan repayment are not current sportsbook features.
The operating standard
Clear claims.
Verified capabilities.
SPORTSBEEP's priority is completing the sportsbook and making its rules, limitations, and handling of funds understandable. Future features belong on the roadmap until they are implemented and verified.