I’m part of a team building a non-custodial P2P fiat on/offramp that lets people buy and sell crypto directly using local payment methods, without depositing assets on a centralized exchange.
The goal is to remove friction many people face today: giving up custody, heavy reliance on centralized KYC, slow deposits and withdrawals, and limited support for local payment methods.
We’re building a multi-network onramp and believe Zcash would be a strong fit because of its focus on financial privacy and shielded addresses/pools. We’d want to support shielded receiving natively.
Who’s the right person or team to speak with about a potential integration? Happy to share more details.
The Zcash compute layer is essentially the memo field, 512 bytes per tx. And you view it with a view key or spending key. That’s currently all you’ve got to work with. What ideas do you have for the architecture of this thing? because I actually have no idea how you would do it currently in a non-custodial fashion.
Hi, thanks for the question. We’re reaching out because we’d like input on a non-custodial design for the Zcash side, and we’d rather work it out with people who know the protocol.
Our starting idea is a 2-of-3 shielded escrow using FROST (ZIP 312), split between buyer, seller and an arbitrator, with the arbitrator running as an automated co-signer. Viewing keys would let the arbitrator confirm the deposit without being able to spend it, and the memo would only carry a trade reference.
Is FROST escrow workable with today’s tooling on Ironwood, or is there a better approach?
I also came across Quorum (GitHub - Fatihmaull/zcash-multisig · GitHub), which looks like early work on threshold custody for shielded funds. Is anyone else building this? It looks like something we could reuse or contribute to rather than duplicate.
As far as I can tell, Peer settles in USDC on Base, which is a public chain, so there’s no shielded option on the on-chain leg. In our view that leg is where P2P users tend to lose privacy, and it’s why we’re focused on shielded ZEC.
We also think people shouldn’t have to download another app. Zodl already offers swaps inside the wallet, and buying and selling with local payment methods could work the same way. A wallet could then do more than send and receive, and earn revenue from those trades instead of that value going to centralized exchanges.
That repo is somewhat new. It looks like it came from one of the recent hackathons, early frost would be a year or two ago. Work on it may have stalled(?) because of the inherent complexity of this thing, We don’t have smart contracts so whatever the theoretical smart contract was going to do, you have to set up to function with other programs that will likely not ever directly touch but (and if you want it non custody, or maybe shared custody, at least) will require coordination to attain the desired automation of this extra logic. An arbiter would be a good fail-safe in case the swap fails and the funds in the frost address need to be returned (they would otherwise be stuck forever). In a 2 of 3 with just a view key, that would likely be their only function. also, because of the inherent differences in the chain, things would take a little bit of time in order to fully complete and confirm, this would not be instantaneous. funds would likely have to sit in holding addresses for short periods of time before they would be released to their owners, and so you’ve got to figure out how to keep them from doing that before you want them to (or at all with another chain idk) and also somehow not have custody.
On Quorum, it looks active right now, but it’s tied to a hackathon, so we’ll see whether work continues. It targets organizational custody, so we’d only look at reusing the FROST layer.
I agree with you that the arbiter is the fail-safe for returning funds. In our design the arbiter would be a signing party, not just a view-key holder, so it can co-sign a refund with one other party if a trade fails. The view key would only let them confirm the deposit.
We looked at what’s public: Zkool lists FROST multisig support, and ZIP 312 covers the signing. Two things we couldn’t find answers to:
Is there a way to enforce a refund timeout on shielded funds without smart contracts, such as a pre-signed refund that only becomes valid after a certain height, or does it have to be coordinated off-chain?
Does FROST signing work for Ironwood spends with the current tooling, or is that still waiting on release candidates?
There is a mechanism called nLockTime imported as-is from Bitcoin, which renders the transaction invalid until it hits a certain block height or time. But without locks, frontrunning is trivial; the “pre-signed refund” is useless since the money is liquid and can just be redirected by bribing a miner (rendering your pre-signed transactions a double spend and thus invalid)
There is also transaction expiry, which invalidates the transaction after it reaches a certain block height.
Transactions can be constructed much earlier on and signed at some later time and then broadcast at some later time, this would all depend on said expiry height. I can’t remember the default offhand, but it comes to about two hours.
The main issue I see with this is collusion risk between either party and the arbitrator. The arbitrator can be bribed, or the arbitrator can bribe one of the parties.
Say the arbitrator signs a share on a transaction that says 50% of the $5 grand locked goes to the buyer (who paid the $5k in the first place, and will soon be getting the $5k-equivalent product). The buyer obviously has an interest to sign their share, creating a full signature. The moment the seller does his thing, the buyer now has $5k-equivalent of goods, and broadcasts the signature. Buyer now has $2.5k ZEC and $5k-equivalent, arbitrator has $2.5k ZEC, seller has nothing.
Now, sure, the arbitrator is supposed to be automatic, but the disk (and therefore its keys) are still held by SOMEONE, and that someone can choose to intervene at any time.
@strahncryptography, Thanks, you make strong points. What do you think of splitting the arbiter’s share across several independent arbitrators, so bribing one isn’t enough or having bonded arbitrators with a stake that can be slashed, as well as capping trade size for new users and newly added arbitrators with keeping the arbitrator out of the normal path, so it only signs in disputes, perhaps even increasing the amount of arbitrators needed in a case of dispute.
Is there a cleaner way to constrain what an arbitrator can sign than relying on software they run themselves?
That’s great, it’s a useful reference for us, and we can learn from their approach. Also, thanks for the API link.
Do you know if Peer specifically supports shielded ZEC transactions? From what I read, the ZEC side is converted to USDC before the Peer order is settled on Base, so the escrowed asset is USDC rather than shielded ZEC.
Our interest is in whether the onramp can deliver ZEC directly to a shielded address, so the acquisition itself doesn’t require an intermediate transparent ZEC leg.
Well, THORChain, via their Bifrost protocol, does the same thing. You just have to ensure that the value of the stake required is bigger than the biggest trade the validators will be handling. Such as Ethereum’s PoS has ~$240B of stake for ~$60B TVL. THORChain has $64.2M staked.
Yeah, that makes sense. Thanks for the feedback, we’ll look into it. If anything else comes to mind that you think would be useful for us to consider, please let me know.
There is also the idea of liberated payments or basically transferring some utxo(s) (likely via the seed or key). it is also inherently tricky. Works better just for tipping because it requires the receiver to transact the funds away for their purposes. Otherwise, the tipper need not do anything else besides continue to have the funds if they never actually get spent. I remember a service that sort of orchestrated something like this a while back, but haven’t heard anything about it since, I assume possibly because it was not fully non custodial idk (again, I wonder about how feasible that actually is at all vs getting pretty close and it actually works).
I was not aware shielded ZEC had programmable UTXOs. It relies on “note commitments”, which cannot be locked or otherwise “given away” afaik- if you pay its paid, atomic.
You do have to give spend auth so you can allocate an amount into a separate account (works best with multi-acct wallets I guess that allocate seeds per acct, some don’t I just thought of that) and give somebody the seed to it, that’s it as far as tipping goes. Rendering that into a functioning up-down thing with another chain is gonna take some work.