Midnight gives builders two ways to recover a Merkle path. If the leaf position is known, pathForLeaf() can rebuild the path directly. If the app lost that position, findPathForLeaf() has to search for the leaf, and Midnight notes that this can require an O(n) scan of the tree.
That difference is where private membership starts feeling less like cryptography and more like product discipline.
A user opens an app and tries to take a membership-gated action without revealing which member they are. The hidden set exists. The circuit is ready. The witness should pull the path, feed it into the proof, and let the action move. But if the app did not persist the insertion-position metadata when that member was added, the flow slows down before the proof even starts doing the interesting work. The button is pressed. The app pauses. The witness falls back to findPathForLeaf(). Now the product is searching the tree for data it should already have kept.
That is the bottleneck that changed how I read Midnight.
Midnight already gives builders the right proof-side pieces: MerkleTreePath, merkleTreePathRoot, and witness helpers that recover the path and pass it into the circuit. The weak point is earlier. Did the app save enough off-chain state to make private membership cheap when the user comes back later, or did it leave the witness to rediscover placement the product already created once?
That builder duty feels more important than it first looks. When a hidden member is inserted, the app has to persist the leaf position and keep that mapping available for the next action. It cannot treat placement as temporary UI memory. It has to survive reloads, retries, and return sessions. If that discipline is loose, private membership does not fail cryptographically. It degrades operationally. The proof is still possible. The product just becomes slower, messier, and more fragile because lookup was treated as an afterthought.
That is why @MidnightNetwork started feeling more serious to me through this exact angle. Its MerkleTree and HistoricMerkleTree pattern does not just enable hidden membership. It exposes the quiet support work privacy depends on. The chain can keep the set hidden. The circuit can keep the proof anonymous. But the app still has to remember where the member sits inside that hidden structure, or the user ends up paying for privacy through recovery work that should never have appeared in the first place.
That is also where $NIGHT becomes more concrete to me. A membership action can have the DUST it needs, the transaction can be fully funded, and the proof can still feel slow because the app lost the index data that makes recovery cheap. The user is not waiting because execution lacks resources. The user is waiting because the product forgot the metadata that should have let the witness rebuild the path directly. Funded execution is still clumsy when indexing discipline fails upstream.
The pressure-test question I keep coming back to is simple.
Can @MidnightNetwork help builders make this burden disappear before O(n) recovery starts getting treated as normal privacy overhead? Because if not, the first visible cost of private membership will not be some abstract debate about privacy design. It will be a user pressing once, then waiting while the app searches for what it should have remembered.
On Midnight, hiding who is in the set is only half the job.
The harder part is not forgetting where they are.
#night $NIGHT @MidnightNetwork
