Security and operator permissions
Lots' security proposition is a set of bounded, inspectable rules: fixed recipes, complete backing before issuance, protected liquidity principal, signed route limits and separate fee and recovery accounting.
Those are intended properties. These docs do not establish a completed audit or verify a live deployment. Security depends on the actual integrated contracts, their configuration and external assets.
The intended protections
| Protection | Constraint it is intended to enforce | What it does not establish |
|---|---|---|
| Fixed meme issuance | No later supply inflation by minting | A stable price or broad ownership distribution |
| Immutable basket recipe | No discretionary component substitution or rebalancing | Diversification, issuer solvency or unrestricted transfers |
| Funded minting | No basket receipt before complete actual deposits | Protection from later impairment |
| Permanent principal lock | No creator/operator withdrawal or equivalent indirect removal | Unlimited liquidity or an exploit-free contract |
| Atomic route bounds | No successful partial settlement outside the signed output choice | A transaction cannot revert or consume gas |
| Separate fee escrow | One recipient's failure does not block other claims or swaps | Collected tokens always have liquid dollar value |
The platform should expose contract, vault, pool, position and version identities so these boundaries can be checked independently.
The operations wallet
Approved operational actions require two of three independent signers. The wallet can manage asset/route permissions, affected new-launch or basket-issuance restrictions, verified restarts, authorized recovery transitions and reviewed versions for new launches. No mandatory waiting period is specified for these actions.
This is not unrestricted ownership of user assets. Permissions do not authorize backing loans or seizure, protected-principal withdrawal, recipe edits, retroactive fee changes or discretionary reassignment of recovery rights.
A threshold wallet is only as strong as its actual configuration and execution paths. Safe documents threshold approvals as well as modules that can introduce alternative execution authority; validating the entire configuration matters. This is background, not confirmation of a deployed Lots Safe. Safe architecture.
No discretionary pool trading pause
MVP policy excludes an operator-controlled emergency switch for official-pool buys or sells, including during a serious vulnerability or exploit. The same prohibited power must not be recreated through a hook, registry, upgrade or mandatory router.
This preserves the approved boundary on operator interference, but limits emergency containment options. Approved issuance, new-launch and platform-route controls still exist. Disabling an official service route is distinct from stopping the pool contract itself.
Trading can nevertheless fail because of ordinary transaction guards, exhausted liquidity, issuer restrictions or chain problems. “No administrative pool pause” does not mean “all trades always succeed.”
Ownership handovers and signer changes
Every operations-owned contract, including the hook, factories and fee/LP locker, requires two-step ownership transfer. The current 2-of-3 wallet nominates a nonzero successor; that successor explicitly accepts and must preserve the approved independent 2-of-3 authority.
Until acceptance, the current owner retains authority and the nominee has none. The current owner can cancel or replace a nomination. Unauthorized acceptance and ownership renunciation are prohibited, including equivalent abandonment paths. Public records cover nominations, cancellations and completion.
Two current signers can separately approve replacing a signer while preserving three independent signers and the threshold. Neither type of change rewrites existing launch economics. A creator fee-wallet change has its own authorization process.
Website and issuer boundaries
Moderators can hide content, but have no contract-signing powers by virtue of their moderation role. Wallet authentication, safe uploads, access checks and API security also need review. A correct vault cannot prevent a malicious interface from requesting an unsafe signature.
Stock-token issuers retain their own controls. The issuer prospectus describes mechanisms including address blocking, pausing, freezing and seizure under its terms. Wrapping a token in a Lots basket does not remove those controls. RHJ Base Prospectus, terms on PDF pages 124–126.
Evidence required before real funds
The PRD requires an independent contract audit and focused web/API security review, closure of critical/high findings, verified permission boundaries and testing of the actual integrated implementation. Reference-protocol audits cannot stand in for that evidence.
The status page records the unresolved launch, routing, recovery, ownership and security work. Publishing this documentation does not close it.