Moth Pass has been updated. AI Pack and Private Payroll are now available on Duskmoth.
AI Pack 1 pass per generated plan Turn your instructions into a SOL or USDC payment plan. Review the recipients and amounts before using it AI does not move your funds.
Private Payroll 1 pass per batch Pay up to 20 recipients from your existing private balance through Privacy Cash. Review fees and recipient amounts before running the batch. Confirmed payments are not repeated when you resume.
Burn $DMOTH to get Moth Passes. Passes are optional Duskmoth’s core sending, shielding, and withdrawal features remain available without them.
Before Duskmoth shows up inside anyone else’s wallet, a few things have to be true.
Screening has to work every time, and fail closed when it can’t. Fees have to be shown in full before the user confirms, with nothing added later. The trust model has to be labeled honestly, because a ZK pool and a hardware-based rollup are not the same thing, and users deserve to know which one they’re using. And every payment needs a receipt that can be checked on Solscan.
If we can’t meet all of that inside a wallet flow, we won’t ship it there. A rushed integration would hurt the wallet’s users and our reputation at the same time.
Here’s the flow we’re sketching for a Duskmoth route inside a wallet. Nothing shipped, just the design.
The wallet asks us for a quote. We answer with the full cost, the estimated time, and which engine would run it: the ZK pool for SOL or the private rollup for USDC.
If the user picks our route, we screen the destination first. If screening can’t run, we return nothing and the wallet simply doesn’t offer us.
If it passes, we hand back an unsigned transaction. The user signs it in their own wallet like any other send. We never touch keys, and the wallet can check the status with us until it settles on Solana.
Same rules as the Duskmoth app, just a different front door.
Quick breakdown of how @solflare Privacy Aggregator works, because it’s a smart design.
You pick a recipient and an amount. The wallet compares the available privacy providers, shows you the fee and an estimated time from the best one, and you confirm. Private Send is off by default and you turn it on per transaction.
It’s basically what DEX aggregators did for swaps, applied to privacy: providers compete, the user gets the best route without leaving the wallet.
Solflare has said it’s opening this to qualified privacy protocols. We’re looking closely at what it would take for Duskmoth to offer a route there.
Most people will never download a separate privacy app. That’s just reality.
They open the same wallet every day, send to the same friends, pay the same freelancers. If privacy lives somewhere else, they won’t use it, no matter how good the tech is.
That’s why wallet-native privacy is the direction we care about most. Solflare already took the first step with its Privacy Aggregator, where Private Send is an option you can switch on for a single transaction.
We think that’s the right model. The question we’re working on is what a better private route could look like inside it.
The stack we’re building toward:
📱 Wallets, where users already are
🦋 Duskmoth, the same flow for every payment
🔐 Privacy engines: ZK pool + private rollup
⛓ Solana, verifiable settlement
Privacy shouldn’t need a new habit. It should meet you where you are.
Payroll in USDC, without publishing everyone’s salary.
Private USDC payroll is live in beta on Duskmoth. Approve once, settle on Solana.
Join the beta 👉 https://t.co/jLPqEW8tqe
The stack we’re building toward:
📱 Wallets, where users already are
🦋 Duskmoth, the same flow for every payment
🔐 Privacy engines: ZK pool + private rollup
⛓ Solana, verifiable settlement
Privacy shouldn’t need a new habit. It should meet you where you are.
Our Telegram is open
A place to talk private payments, ask questions, report bugs, and help shape what Duskmoth builds next.
→ talk directly with the dev
→ early looks at what we’re testing
→ feedback that actually shapes the roadmap
Join the discussion 👇
https://t.co/mvkBOqBQPh
Dev log: where Duskmoth’s infra is now, and where I’m taking it 🛠
Today
→ wallet signs every tx, unsigned txs verified client-side
→ AI Pack writes plans, never signs
→ screening fails closed, Moth Pass checked before execute
→ router picks the engine by asset: ZK pool for SOL, @magicblock private rollup for USDC (beta)
→ backups, cross-tab lock and check-only recovery so nobody gets paid twice
Next (exploring)
→ single-signature batches: N payments, one approval
→ split and timed payouts for payroll
→ a Route API so wallets can offer Duskmoth routes natively
→ multisig approval + more engines as they hit mainnet
The flow stays the same. The engines underneath get better.
I’ll post progress as each piece ships.
Next frontier: private payments right inside your wallet.
@solflare Privacy Aggregator already compares private routes for users. We’re exploring what a Duskmoth route could look like there: screening first, full cost upfront, ZK or private rollup underneath.
Research direction, not a launch.
Beta doesn’t mean careless.
Before: you see the maximum upfront cost, including network, program and account setup fees
During: every operation is backed up, and cross-tab protection stops overwrites
After: unresolved payments get a Check, never an automatic resend
Small details. They matter when it’s your money.
Duskmoth now runs two privacy engines:
🟢 SOL → ZK shielded pool
🟣 USDC → private rollup (TEE)
The flow you use doesn’t change: prepare, screen, review, approve. The router picks the engine by asset, and shows you which one before you sign.
No silent rerouting. Ever.
How private USDC works on Duskmoth:
Your wallet signs once on Solana
USDC moves into a private rollup
Transfers run inside trusted hardware, not broadcast publicly
Funds settle back on Solana, with receipts on Solscan
Honest note: this is hardware-based privacy (TEE), not zero-knowledge. It reduces linkability; it doesn’t make you invisible.
@magicblock@PiccoGabriele
Private USDC is live in beta on Duskmoth 🦋
One panel, four private actions:
→ send USDC privately
→ deposit & withdraw
→ Private Payroll, up to 20 recipients
→ load USDC plans from AI Pack
Powered by @magicblock Private Ephemeral Rollup. Your wallet signs everything. Beta, start small.
Spent the week shipping the MagicBlock beta. Here’s the full write-up of how it all fits together: the router, both privacy engines, and the recovery logic that stops double payments.
Questions welcome, I’ll answer in the replies 👇
MagicBlock v1.0 is live on Solana after a year and a half of building
Apps can run in real time, prove every outcome is fair, and keep payments private, without leaving Solana
Read the full Validator v1.0 release: https://t.co/Wb3vjQ0CUt
Where the AI stops in Duskmoth 🤖
The AI turns your instruction into a structured plan: recipients, amounts, asset. That’s its whole job.
Everything after that is ordinary code:
→ validation checks balances and limits
→ screening checks destinations
→ your wallet signs
No keys, no approvals, no shortcuts. If the AI is down, a rule-based parser takes over.
The SDK follows the same boundary: it builds and reviews, it never signs.
Dev here.
Real-time and private, without leaving Solana. This is the direction we’re taking Duskmoth.
What I’m working on:
→ Duskmoth prepares, screens and shows the full cost
→ you approve once
→ payments run in a private rollup with split and timed payouts
→ funds settle back on Solana
More integrations and tech upgrades are coming to Duskmoth. I’ll keep sharing progress here as it ships
This is the flow I’ve been sketching for Duskmoth payroll 👇
Start on mainnet → run privately → settle on mainnet, with one signature from the user.
Duskmoth handles the part people actually see: the plan, screening, full fees and one approval. A private rollup handles execution: split payouts, timed releases, settled back on Solana.
Exploring it now. Will share what works and what doesn’t.
What happens if your browser crashes in the middle of payroll? ⚙️
Every payment in a batch has a state:
✅ Confirmed: found on-chain, skipped on resume
⏳ Pending: not sent yet, safe to send
❓ Uncertain: sent but not confirmed, checked on-chain before anything else happens
Uncertain payments are never resent blindly. That one rule is what prevents paying someone twice.
How a Moth Pass can’t be tied to the burn that created it 🔏
You burn $DMOTH on-chain (public)
Your browser “blinds” a random token before sending it to us
We sign it without seeing it (RSA blind signatures, RFC 9474)
You unblind it and get a valid, signed pass
When you redeem, we can verify our signature, but we can’t tell which burn it came from.
We know a pass is real. We don’t know whose it is.
Why private withdrawals go through a relayer 🛰
Every Solana transaction needs a fee payer. If your fresh wallet pays its own fee, you first have to fund it with SOL, and that funding can link it right back to you.
So the relayer submits the withdrawal and covers the network fee. You pay it back from the withdrawn amount: about 0.006 SOL, plus the protocol’s 0.35%.
The relayer can’t redirect your funds. The proof locks the recipient.