iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Midnight private state is kept locally by the user or application; public ledger state remains visible on-chain. A zero-knowledge proof can let validators check a computation that uses private inputs, but it does not hide data deliberately published to the ledger. In Midnight.js, developers manage local state separately from public chain data, so storage, account isolation, disclosure, and recovery all need to be designed explicitly.
What counts as private state in Midnight?
Midnight separates public ledger state from private state held locally by a user or application. In Compact, the developer defines which fields synchronize to the public ledger. Public fields and transactions designated public are visible on-chain; private inputs can be used in contract logic to produce zero-knowledge proofs that validators check without receiving the raw inputs. The proof protects the inputs used to establish a result, not any output the contract intentionally makes public. Midnight’s overview describes the public/private model.
Think of privacy as a boundary you define, not a property that automatically applies to every value in a contract. A value already written to the ledger does not become secret because later logic reads it privately. Conversely, information derived from private witness data can be disclosed deliberately; Midnight’s FAQ identifies Compact’s disclose() operation for this purpose. Confirm its exact syntax and behavior against the Compact version used by your project. Midnight FAQ
Where does Midnight.js store private state?
Midnight.js uses separate providers for local private state and public chain data. The documented privateStateProvider stores encrypted local application state; the publicDataProvider queries public chain state through the indexer. Other provider roles handle ZK artifacts, proof generation, wallet operations, and transaction submission. The API reference documents initialization with initialPrivateState and separate queries for private and public states. These details are from the Midnight.js API reference labeled v4.0.4; check the project’s support matrix for the versions that apply to your build. Midnight.js API reference
#1 Best Overall
- Hardware encrypted drive
- Simple to use pin access. RPM-5400
- Administrator password feature
- Bus powered
- Utilizes Military Grade FIPS PUB 197 Validated Encryption Algorithm
| Execution context | Documented storage behavior | Design implication |
|---|---|---|
| Browser | The deployment guide says browser builds use browser storage. | Private state depends on the user’s local browser environment; do not treat it as a server-side backup. |
| Server-side context | The deployment guide says server-side contexts resolve to native LevelDB. | Review server routes and other server execution paths for unintended access to or persistence of private state. |
The storage behavior above is described in Midnight’s deployment and operations guide. The execution context matters: code that appears to use the same provider interface may resolve to different storage backends depending on where it runs.
How should you define the privacy boundary?
Before implementing state, classify each field according to whether it must be public, must remain private, or should be disclosed only as a deliberate result. That classification should inform both the Compact contract and the application code that supplies private inputs. Check every output and transaction path: a private computation can still produce a public result.
Rank #2
- Utilizes Military Grade FIPS PUB 197 Validated Encryption Algorithm
- Super fast USB 3.0 Connection - Data transfer speeds up to 10X faster than USB 2.0
- Software Free Design - With no admin rights needed
- Sealed from Physical Attacks by Tough Epoxy Coating
- Brute Force Self Destruct Feature
- Public: treat ledger fields and public transaction data as visible to observers, even when private logic later consumes them.
- Private: keep sensitive inputs in local private state and use proofs to establish the required rules without exposing the raw inputs.
- Disclosed: make disclosure intentional, limited to what the application needs, and verified against the Compact version in use.
Use this classification during contract design and review, rather than assuming that a value is private because it originates on a user’s device.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How do you protect local state in Midnight.js?
Isolate state by account
The documented LevelDB provider requires an accountId; the deployment guide describes this as a safeguard against state leaking across accounts. Use a stable identifier that matches the wallet and account model in your application, and do not reuse one store namespace across users. Confirm that the account identifier is supplied wherever the provider is initialized. Deployment and operations guide
Rank #3
- Slim durable design to help take your important files with you
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- Back up smarter with included device management software[2] with defense against ransomware
- Help secure your important files with password protection and hardware encryption
- 3-year limited warranty
Encrypt data and manage the credential deliberately
The API reference identifies AES-256-GCM encryption at rest. The deployment guide’s password guidance is version-sensitive: it specifies at least 16 characters and at least three of these categories—uppercase letters, lowercase letters, digits, and special characters. The guide recommends deriving the password from wallet credentials or a key management system instead of hardcoding it in source code. Treat the encryption credential as a secret and plan how the application will make it available when the user needs to unlock state. API reference, v4.0.4; deployment and operations guide
Keep private-state handling on the intended client path
Because browser and server-side execution can resolve to different storage backends, keep private-state handling in the intended client code and inspect server, API-route, and edge execution paths for accidental reads or writes. This is both a privacy and an account-isolation concern; a browser storage assumption does not hold automatically in server-side execution.
Rank #4
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Align package versions
Follow the compatibility support matrix for the compiler, runtime, and SDK versions in a project. The deployment guide warns that duplicate copies of ledger packages can create incompatible TypeScript types. Recheck the matrix and generated artifacts when changing compiler or SDK versions rather than treating the v4.0.4 API reference as a timeless specification. Deployment and operations guide
Recommended Free Tools
How should you plan backup and recovery?
Local encrypted state is not automatically backed up. Losing a device or browser data can remove state the application needs, and a wallet seed phrase does not necessarily restore shielded notes or contract-specific private data. The official FAQ says a seed phrase restores unshielded addresses and assets, but may not restore those local private-state items. If required data is missing, a user may be unable to generate proofs needed to access or spend shielded assets. Midnight FAQ
Design backup around the actual state your application requires and the threats it must address. Explain what is backed up, how it can be restored, and what cannot be reconstructed from a seed phrase alone. Do not describe a wallet seed phrase as a universal backup for application state.
What failure modes should you test?
- Wrong encryption password: the deployment guide warns that an incorrect password may not surface until encrypted state is first decrypted, potentially deep in a transaction flow. Its documented canary pattern can detect a wrong password at unlock time. Provisioning and verification should be separate steps; do not accept a missing canary as proof that the password is valid. Deployment and operations guide
- Missing or shared account identifier: the documented LevelDB provider requires
accountId. Test initialization for each account and verify that one account cannot load another account’s state. - Unexpected server execution: verify which backend resolves in each deployment context and check that private-state operations run only where intended.
- Incomplete recovery: test restoration using the backups your application actually provides, not only a wallet seed phrase.
- Version drift: check the support matrix after compiler, runtime, SDK, or generated-artifact changes, and watch for duplicate ledger package copies.
These checks address different failure classes: credential errors, account boundaries, execution context, recovery coverage, and compatibility. Passing one does not establish that the others are safe.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
