Yeah just finished reading through the River whitepaper from 
One thing that stood out to me ( its another sidechain) do we actually need a separate sidechain or validator set for this, or could most of it live directly on Hive as a metaprotocol / shielded pool?
Hive already gives us the ordered reconstructible history that River relies on. So the public pieces (commitments, nullifiers, the ZK proofs themselves, withdrawal certificates) could just go into custom_json ops. Any River node or indexer watches the chain, rebuilds the note tree and nullifier set, verifies the proofs, and ignores anything invalid. Same model as the whitepaper, just without an extra consensus layer.
For the private side (the actual note contents) Hive’s existing memo encryption already does ECDH + AES. You can stick the ciphertext in a transfer memo or pack it into the same custom_json. Only the recipient with the memo key decrypts it. Public chain sees the verifiable crypto objects, nothing about amounts or ownership.
Deposits would be a normal HIVE/HBD transfer (or specially tagged custom_json) that mints a corresponding private note. Withdrawals publish a proof that authorizes the release back to public form. Keeps the liability accounting clean exactly like RHIVE/RHBD in the paper.
Practical limits are real though. Custom_json is capped at 8 KiB so bigger proofs will often need to be split across multiple ops, compressed, or use recursive/aggregated proofs. On top of the size limit there’s also a rate limit: roughly 5 custom ops per account per block (about every 3 seconds). That means high-volume private transfers can’t just spam the chain from one account; you’d need multiple accounts, careful batching, or longer intervals between publishes. RC cost also scales directly with the payload size and frequency, so heavy usage burns through resource credits fast.
( could be a problem but nothing that can be solved relatively easy)
And that’s actually one of the stronger arguments for doing it this way. Right now a lot of Hive RC gets spent on low-value social spam or tiny game actions. A real shielded pool would create sustained demand for RC on something that actually moves value privately. People who want to transact privately would need to hold more Hive Power (or get RC delegated) just to keep the throughput going. That turns HP into something closer to bandwidth for private finance instead of just curation power, which should put more real economic weight behind the token. More demand for HP to pay for private transfers = stronger long-term utility for HIVE itself.
I’m still wondering whether the current design deliberately left room for a pure on-chain approach, or whether the validator quorum and side components handle something Hive simply can’t do cleanly on its own. Either way this feels like a strong fit for the tools we already have.
Compared to spinning up a full sidechain it looks more efficient on several fronts: no extra consensus overhead, no separate set of validators to incentivize or secure, no bridge risk or liquidity fragmentation between the main chain and the private layer, and finality stays at Hive’s normal ~3 seconds. Everything settles against the same history everyone already trusts. You trade a bit of throughput (because of the 8 KiB and rate limits) for much simpler security assumptions and tighter integration with the existing token economy. For a privacy layer that mostly needs reliable ordering and public verification, that trade-off seems worth it.
Anyweay just an idea. I am a big fan of ZK and IMO thats the future of Blockchain. Privacy is something needed to make it fun. You dont want ( even if its cool to verify) everyone to know what you have. A problem 
Social and Finance is still a big thing ( and the future we already see on X and co). Payments with social media is giga bullish. But ZK ( not even full ZK, a opt in) is needed IMO.
I think Onchain it would add a very good usecase for RC and encrypted memos ( we have all, we only need to use it).