Security practices used by Penny Stonks
This page describes controls implemented in the platform code. Security is a continuous process, not a guarantee that incidents can never occur.
Cryptographically chained ledger
Transactions are linked with SHA-256 hashes. Live integrity checks process the ledger in memory-efficient batches and report broken links or invalid fingerprints.
Serialized ledger writes
New ledger entries use a database-level named lock so concurrent transactions do not independently read the same previous hash and accidentally break the chain.
Administrative audit logs
Sensitive actions such as approvals, rejections, manual credits, withdrawals, settings changes and ledger repairs can be recorded with actor, timestamp and contextual details.
Rate limiting and bot protection
Public endpoints, sign-in attempts, registration, trade actions and business-feed posting use configurable rate limits. Cloudflare Turnstile support can be enabled for public authentication flows.
Permission and nonce checks
Administrative and authenticated actions use WordPress capability checks and nonces where applicable to reduce unauthorized cross-site requests.
Repair safeguards
The ledger repair flow uses an exclusive lock, backup records, an InnoDB transaction, non-hash checksums, post-repair verification and rollback if safety checks fail.
Independent checkpoints
Penny Stonks can publish daily ledger checkpoint hashes to a separately configured external endpoint. When active and accompanied by a public receipt, this creates an outside reference that is harder to rewrite together with the primary database.
Responsible disclosure and limitations
No website, plugin, database or operational process is risk-free. Cryptographic consistency does not guarantee business performance or eliminate application, hosting, dependency, account-compromise or infrastructure risks.