Login & account, in plain language
A typical real-money skill-game login follows a four-step flow: enter a mobile number, receive a one-time password (OTP), set or enter a PIN, then optionally enable biometric unlock. The desk describes the flow at a generic level. The operator-specific flow is the source of truth and must be verified on the operator’s own published material before any credential is entered.
The four-step login flow in plain language
A typical real-money skill-game login follows a four-step flow: enter a mobile number, receive a one-time password (OTP), set or enter a PIN, then optionally enable biometric unlock. The desk describes the flow at a generic level. The operator-specific flow is the source of truth and must be verified on the operator’s own published material before any credential is entered.
The first step is the mobile number. The sign-in surface asks for the registered mobile number. The number is the account anchor; the desk has not seen a published flow that allows email-only sign-in for real-money play. The second step is the OTP. A one-time password is sent to the registered number via SMS. Validity windows vary by operator; the desk has read windows ranging from 5 to 15 minutes on the published flows. The third step is the PIN. A four- to six-digit PIN or a longer password is set during first sign-up. The PIN unlocks the wallet, the deposits and the withdrawals. The desk flags any operator that does not separate the PIN from the OTP. The fourth step is biometric. On supported devices, fingerprint or face recognition may replace the PIN at sign-in. The PIN remains the recovery path; biometric is a convenience layer on top.
The desk does not run a wire-feed of operator-specific flows. The published flow on the operator’s own page is the source of truth. Where the operator publishes a number, a window or a document list, the desk records it; where the operator does not, the desk records the gap. The reader verifies the operator’s current page before relying on any figure listed in the editorial chapter.
A 5-minute OTP window is the desk’s published baseline; a 15-minute window is the upper bound the desk has read on the published flows. A window shorter than 5 minutes is recorded as a red flag in the comparison ledger because it materially raises the cost of a transitory connection drop on the reader’s device. A window longer than 15 minutes is recorded with a separate flag because it materially raises the window in which a stolen OTP could be replayed by a third party.
A 4-digit PIN is the desk’s published baseline; a 6-digit PIN is the upper bound the desk has read on the published flows. A PIN shorter than 4 digits is recorded as a red flag because the brute-force search space is too small. A PIN longer than 6 digits is recorded with a separate flag because the desk has read published research showing the marginal entropy gain beyond 6 digits is materially eroded by reader behaviour (writing the PIN on the device, repeating the PIN across accounts, etc.).
What to verify before signing in
Confirm the operator domain is the operator’s own published domain before entering the mobile number. A typosquat is the most common credential-harvest route. If the login is reached via an installed app, confirm the developer name on the app-store listing matches the operator’s own published entity. Before signing in, verify the account-recovery flow. A flow that demands an extra OTP for password reset is a positive sign; one that does not is a red flag.
A published session timeout of 10 to 15 minutes of inactivity is the desk’s baseline expectation. Anything longer is flagged in the comparison ledger. The desk also flags any operator that does not publish a session timeout at all. The published timeout is the reader’s protection against an unattended device being used by a third party. The session timeout is independent of the OTP validity window; the OTP is the credential, the session timeout is the device-side guard.
The desk flags any operator that stores the PIN in plain text on a server. A PIN is salted and hashed before it leaves the device. The reader cannot verify the salt or the hash from outside the device, but the operator’s published security page should describe the protection. A security page that does not mention hashing, salting or a published cipher suite is a red flag and is recorded in the comparison ledger with the gap listed.
Editorial boundary
Login & account, in plain language on boltfantasy.com is editorial guidance, not legal or financial advice. The desk reads published operator material and records the desk’s own test tickets where the operator publishes a verifiable flow. Where the operator publishes a number, a window or a document list, the desk flags it; where the operator does not, the desk records the gap. The reader verifies the operator’s current page before relying on any figure listed here.
The desk does not publish personal recommendations for any specific platform beyond the editorial pick on the homepage. The desk does not verify any operator’s licence beyond the licence number the operator publishes on its own material. The desk does not interpret any state gaming act; the reader verifies the local rule before playing.
A credential-harvesting surface is a sign-in surface that does not match the operator’s published domain. The desk flags any sign-in surface reached through a link the operator did not publish, an app the operator did not publish, or a domain the operator did not publish. The reader verifies the operator’s own published material before entering any credential. The comparison ledger records the credential-harvesting surfaces the desk has read against a published primary source.
A published sign-in flow is the operator’s own flow on the operator’s own page. The desk flags any sign-in flow that demands a fee before the OTP is sent, a fee before the PIN is set, or a fee before the biometric is enabled. The reader verifies the operator’s own published material before entering any fee. The comparison ledger records the fee surfaces the desk has read against a published primary source.
Operational reference for this page
The pages on boltfantasy.com are written by the editorial desk. Each page walks through the published material on a single topic; the operator-specific UI is the source of truth and must be verified on the operator’s own published material before the reader commits a rupee. The pages are not legal or financial advice; the pages are editorial guidance on the published rules, the published drop ladder, the published chip math, the published safety surface and the published comparison dimensions. The reader verifies the operator’s current page before relying on any figure listed here.
A published number is a number the operator has published on the operator’s own page. The desk has read the published numbers on a small set of operators; the desk does not synthesise or extrapolate. Where the operator publishes a number, a window or a document list, the desk records it; where the operator does not, the desk records the gap. The reader uses the desk’s record to make their own comparison; the desk does not publish a winner.
A published window is a period the operator has published on the operator’s own page. The desk has read the published windows on a small set of operators; the desk does not synthesise or extrapolate. The reader verifies the operator’s own page before relying on any window listed in the editorial chapter. The comparison ledger records the windows the desk has read against a published primary source.
A published document list is a list the operator has published on the operator’s own page. The desk has read the published document lists on a small set of operators; the desk does not synthesise or extrapolate. The reader verifies the operator’s own page before relying on any document list listed in the editorial chapter. The comparison ledger records the document lists the desk has read against a published primary source.
A restricted-state list is a list the desk has read against a published primary source. The restricted states for real-money rummy, as of the desk’s last review (Edition 342, 06 Aug 2026), include Telangana, Andhra Pradesh, Assam, Odisha, Sikkim, Nagaland, Meghalaya and Tamil Nadu. The desk’s list is a desk record, not a legal interpretation. The reader verifies the local state gaming act before playing. A state change to the restricted list is recorded in the news register with the source date and the desk’s verification status.
A support line is a contact the desk has read against a published primary source. The desk does not operate a support line; the desk links to the published support lines operated by recognised public-health bodies. The reader is encouraged to contact a support line if the play has stopped being a leisure activity. The chapter’s last review date is recorded on the page footer.
A review cadence is the desk’s published review window. The desk reviews each chapter on a quarterly cadence. The chapter’s last review date is recorded on the page footer; the reader verifies the local rule before relying on the chapter’s published figures. A chapter that has not been reviewed in the last quarter is flagged in the chapter’s footer; the reader verifies the operator’s current page before relying on the chapter’s published figures.
A red flag is a published signal the desk has read against a primary source. The desk flags any operator that does not publish a deposit cap, a session timeout or a self-exclusion switch. The desk flags any operator that publishes a dispute window shorter than the desk’s published baseline. The desk flags any sign-in surface that does not match the operator’s published domain. The comparison ledger records the red flags the desk has read against a published primary source.
A primary source is a document the operator or regulator has published on its own page. The desk reads the primary source and records the desk’s own test ticket where the operator publishes a verifiable flow. The desk does not synthesise or extrapolate. The reader verifies the operator’s own page before relying on any figure listed in the editorial chapter.
A chapter cross-reference is the link between chapters on a single topic. The format-split chapter is referenced from the games hub, the strategy hub and the reviews hub. The drop-vs-show chapter is referenced from the strategy hub and the games hub. The dispute-handling chapter is referenced from the reviews hub and the safety hub. The reader uses the cross-references to navigate to the chapter that matches the decision they are facing. The cross-references are not commercial links; the cross-references are the desk’s own editorial navigation.
A reading order is the desk’s recommended sequence for a reader who is new to the chapter. The reader starts with the chapter’s first section, walks through the published material, and finishes with the operational reference. The reading order is not a personal recommendation; the reading order is the desk’s own editorial sequence. The reader may skip sections they are already familiar with; the reader verifies the operator’s current page before relying on any figure listed in the chapter.
A glossary entry is the desk’s published definition of a term used in the chapter. The glossary entries are linked from the chapter’s operational reference; the reader uses the glossary to look up an unfamiliar term without leaving the chapter. The glossary is not exhaustive; the glossary covers the terms the chapter uses most often. The reader uses the desk’s broader editorial chapters to look up terms the chapter does not define.