Leonardo Alvarez Boscan

Been heads down building for a while. Figured it's time for me to record some code and talk over it for you guys. Walked through a few of the core modules we're working on at 5ive Privacy: → ZK proof generation layer → Authentication and security scoping → On-chain to private balance routing We're getting close to launching $FIVE. 📘

Something I've been thinking about a lot lately is how we handle the fragmentation math. It sounds simple split a deposit into random pieces. But the randomness actually matters a lot more than people realize. If you just split $1,000 into four even chunks of $250, that's a pattern. Anyone watching the chain can see four identical amounts hit within minutes and guess they came from the same source. So our fragments have to be genuinely random with different sizes, different timing, no repeatable ratios. We generate the split ratios per deposit using a CSPRNG. Every chunk has to be at least $3 so it clears the mixer floor, but beyond that the sizes are completely unpredictable. Then each chunk gets its own random delay before it moves to the next stage. One might go in 60 seconds, another in 3 minutes. There's no schedule and there's no pattern for anyone to model against. By the time those pieces land in the pool, they look like completely unrelated transactions from completely unrelated users. That's the whole point. Small stuff like this is what separates real privacy from privacy theater. The details matter.

Just shipped Telegram integration for 5ive Privacy. You can link your account from the dashboard and do everything right from the chat. Get notified the second a deposit settles. Check your balance with /balance. Send privately with /send. Like "/send 50 USDC to alex.5ive" and it just works. Wanted this to feel like your wallet lives in your pocket without needing to open the app every time something moves.

Last post for the night. This is just the beginning and we're not slowing down. GN. See you tomorrow.

Just added full observability to the mixing pipeline. Quick breakdown on what that means. Every deposit moves through stages, detected, fragmented, mixed, credited. We now have a metrics layer watching all of it in real time. How many deposits are sitting in each stage, throughput over the last hour and day, how long each step takes, and an automatic flag for anything that looks stuck or overdue. The important part is it doesn't touch the money path at all. Zero new writes, zero changes to how funds move. It just reads data we already store. Pure visibility, no added risk. If something ever slows down, we see it before you do. That's the whole point.

@5ivePrivacy 👏

This isn't a sprint. It's a long build with a team that's not going anywhere. And having a community that gets that makes all the difference. Thank you. Seriously. Let's keep going. $FIVE | 5iveprivacy.com

Just shipped Proof of Innocence on 5ive Privacy. You can now prove your funds aren't tied to any OFAC sanctioned sources directly from your dashboard. It generates a clean-funds attestation you can share with anyone who needs to see it exchanges, counterparties, whoever. This was important to get right. Privacy without compliance is a dead end. We've seen what happens when protocols ignore that. So we built both into the same system. Your transactions are private by default, but when you need to prove your funds are clean, it's one click.

Just shipped something important for how our backend handles your money. Attached a video of me walking through the code if you want to see it. So our system runs background jobs every minute checking for new deposits, mixing funds, crediting balances. The issue is sometimes a job takes longer than expected and the next one starts before the first one finishes. Now you've got two jobs trying to move the same money at the same time. Bad. The fix is simple. Before a job starts, it grabs a lock. If another job shows up and sees the lock is taken, it backs off and waits. If a job crashes, the lock expires on its own so nothing gets stuck. On top of that, every single transaction already has its own safeguards so nothing can ever get processed twice. Belt and suspenders. Lottery-level privacy!!!

Just pushed a guided first-run experience for new users. Wanted to make sure nobody's first interaction with 5ive Privacy felt confusing.

Just shipped something small but important. You can now export your full activity history as a CSV directly from the dashboard. Runs entirely client-side. Your data never leaves your session, never touches the transaction path. Privacy by default, now easier to account for.

The tech is live and working. Go try it yourself. Connect your wallet, deposit USDC or USDT, and watch your funds get fragmented, delayed, mixed, and paid out from the pool. Your wallet never touches the other side. Five link-breaks between you and your transaction, all happening in real time. Don't take our word for it. Go see lottery-level privacy for yourself.

We're not building 5ive Privacy as a standalone app. We're building it as infrastructure that plugs into everything. Luxury merchants who don't want competitors watching their sales volume. DeFi protocols processing hundreds of millions. Payroll providers sending salaries across borders. Treasury teams moving institutional capital. All of it currently sitting on a public ledger for anyone to see. A few lines of code to integrate. Deposit goes in, clean USDC comes out, no on-chain trail between the two. Whether you're a freelancer getting paid $500 or an enterprise settling $100M in quarterly payroll.

It feels like something is coming today?!!

gn future 5ive community!

Quick breakdown on how fragmentation works. Your deposit gets shattered into random pieces, a $10k transaction might become 7 fragments that are all different sizes. Each fragment enters the batch processor independently, gets mixed with other users transactions, and delayed by a random interval. By the time they hit the ZK pool, there's no mathematical relationship between the fragments anymore. Pedersen commitments lock the values, Groth16 proves validity, and the chain sees nothing but a proof. Then the relayer submits the withdrawal from a completely separate wallet.

Five privacy layers. Tor routed. ZK proven. Every transaction fragmented, batched, delayed, and withdrawn through decentralized relayers. No trace. No link. No way back to you. We've been building this in silence. Tomorrow we go loud. $FIVE launches tomorrow on @Base. 5iveprivacy.com

Yeah exactly. The ZK stuff works, that part is solid.

@Veilyn_Labs Yeah exactly. The ZK stuff works, that part is solid.

@AlvarezBoscan Pedersen for the value and Groth16 for exit validity is the sane split. The hard part is policy plumbing: ranges, nullifiers, and verifier surfaces people can actually integrate

So the way the ZK layer works, when you deposit USDC into the protocol, your amount gets committed using a Pedersen commitment. The commitment hides the value but still lets us prove it's valid. Then when you withdraw, a Groth16 proof gets generated that basically says "yes, this person has funds and yes, the amount is correct" without ever revealing who they are or what the amount is. The chain only ever sees the proof. Nothing else touches the ledger. That's layer 4 and it's probably the most important piece of the whole stack.