Design Decisions
This page is a curated overview of the core decisions behind LOOTCoin. It is not a whitepaper. It is a map of tradeoffs: what was chosen, why it was chosen, and what it enables next.
Jump to
Security and trustPlayer state modelGameplay validationWeb3 choicesUX and productScalability and evolutionWhat LOOTCoin optimizes for
- Real players over automated farming
- Simple UX over complicated onboarding
- Gameplay-first token distribution, not passive rewards
- Modular systems that can evolve without rewrites
What LOOTCoin avoids
- Identity checks that feel like KYC when they do not need to
- Spreading “player truth” across multiple systems
- Overbuilding features before the core loop is strong
- Security as an afterthought
Security and trust
The main threat model is incentives. If value exists, automation will try to extract it. That means anti-bot and anti-duplicate design has to be part of the foundation, not a patch later.
- Liveness is required to raise the cost of botting and multi-account abuse.
- Session tokens are issued only after liveness, then required for sensitive dApp actions.
- Short-lived sessions reduce replay risk and limit the blast radius of abuse.
- Security is layered: liveness, sessions, rate limits, and server-side validation.
Player state model
As systems grow, “player info” can drift into a dozen places. That creates bugs, inconsistency, and fragile features. LOOTCoin uses a dedicated player object as the single source of truth.
- One player object holds equipment, modifiers, detection range, and derived stats.
- Consistency beats convenience: systems read from one place, not many.
- Faster iteration: new gear and modifiers plug into the player object instead of scattering logic.
Gameplay validation
When rewards exist, client-only logic becomes a target. The design leans toward server-validated actions for state changes that matter. The client stays fast and responsive, but the backend enforces integrity.
- Client UI is optimistic where safe, with clear feedback when confirmation is needed.
- Backend verifies state-changing actions tied to sessions and player state.
- Cheat resistance by design, not by pretending the client is trustworthy.
Web3 choices
Web3 should feel like an advantage, not homework. The goal is to keep the experience approachable while still delivering real ownership where it matters.
- Wallet abstraction reduces friction for new players.
- Gasless interactions protect the core loop from fee anxiety.
- Tokens and NFTs are used intentionally, not as decoration.
UX and product
Most players will never read a whitepaper. They will judge the product in seconds. UX work is not cosmetic. It is what makes the system usable, and therefore real.
- Mobile-first is treated as a constraint, not a future task.
- Consistency in layout and feedback reduces confusion and churn.
- Fewer steps beats clever flows, especially before launch.
Scalability and evolution
The project is designed to evolve. Some things are built as foundations because they are hard to retrofit. Other things are intentionally deferred until the core loop proves itself.
- Security foundations now: liveness, sessions, validation.
- Modularity: player model and systems that can expand without rewrites.
- Defer wisely: only scale what the product proves is worth scaling.
If you are reading this pre-launch, this page is meant to answer one question: Is this being built deliberately? The answer should be visible in the decisions, not promised in slogans.