Offline, Payment Gateway Design Discussion- Input Needed

General
1

First of all, thank you to the ZCG for the thoughtful feedback on our SA-SMS proposal. The concerns raised about the current form of our solution are valid, and I’d like to follow up on Hanh’s suggestion to involve the community in designing a more robust architecture.

The goal of this post is to collaborate with the community to design a Shielded Aid Gateway system that aligns with the Foundation’s SAI principles. Our mission remains unchanged: building a decentralized, censorship-resistant, and privacy-preserving distribution network.

Our core constraint is clear the system must function in regions with zero internet connectivity at the point of transaction.

@Hanh , I’d really value more insight into the “proper solution” you envision for users with no internet access.
Is it primarily FROST-based? Does it require a ZK-ID layer for sybil resistance?

We’re eager to work with the community to design a tool that can genuinely serve this need.

1 Like
2

What about satellite tx broadcasting? like GitHub - Blockstream/satellite: Blockstream Satellite :slight_smile:

2 Likes
3

That’s a great suggestion @decentrathai, thank you. I just did a quick research and it. Just so I’m clear on your vision: are you suggesting we explore integrating with an existing service (like a Blockstream API bridge), or are you envisioning the community building a native Zcash broadcast layer?

A satellite broadcast would definitely solve the downlink problem (knowing you received funds). However, my concern remains the ‘Uplink’ problem and the Z3 data requirements:

  1. The Triangulation Risk: From my understanding Zcash requires a Witness like the borrow checker in WASM so even if a user can receive data from space, they still have to ‘shout back’ to spend it. In high-risk zones, any active satellite or radio transmission creates a physical triangulation risk that could compromise the user’s location.

  2. Z3/NU7 State Size: With the move to the Z3 stack, a wallet needs to stay synced with a significant amount of shielded data to create valid proofs. Broadcasting this volume of data over narrow-band satellite might be too slow for practical aid distribution.

This brings me back to my current understanding of FROST v3 (ZIP-312). If we can’t trust the ‘uplink’ (Satellite or SMS) because of signal tracking, perhaps the solution is ‘Delayed Relay.’ The user signs a transaction fragment offline, and that fragment is carried out of the danger zone physically or via a low-power mesh. I wonder if the community see FROST as the primary solution for this ‘last mile’ in the SAI? Specifically, a theoretical design where viewing keys never leave the device, even when using an untrusted relay?

1 Like
4

Frost has multiple “rounds”, multiple sets of messages have to be exchanged between participants over secure channels.

1 Like
5

Could we utilize FROST Pre-processing (generating the Round 1 nonces in advance while the user does have a moment of connectivity) so that the ‘Offline’ part only requires a single round?

regarding ‘Secure Channels,’ if we use the Noise Protocol (like the Foundation’s reference implementation) to encrypt the fragments before they are sent via the gateway, would that satisfy the security concerns for an untrusted relay?

6

What if we’ll use not pure satellite but more like hybrid: satellite for downlink only (passive receive, no RF from user and no triangulation), and something like LoRa mesh (Meshtastic) for uplink. There’s a project called btcmesh that relays Bitcoin raw transactions over Meshtastic. Interesting as a concept, but Zcash shielded transactions are way bigger than BTC (Orchard proofs and coming ZIPs are thousands of bytes, LoRa packets max around 228 bytes). The chunking overhead might make it impractical. Would need someone to actually run the numbers.

1 Like
7

Seems like we are getting close to a solution. The hybrid model definitely solves the triangulation worry for the downlink, but you’re also spot on about the ‘Zcash is too fat’ problem. One concern with the LoRa mesh is the hardware barrier. Since phones don’t have native LoRa support, every aid recipient would need a secondary node (like a Meshtastic device) paired via Bluetooth.

If a single Orchard spend is ~3KB-9KB, trying to chunk that into 200-byte LoRa packets over a multi-hop mesh is a recipe for high packet-loss and frustration. Which keeps bringing me back to FROST v3, hahaha. I believe If we use the ‘Delayed Relay’ model then we won’t just be sending raw transactions. It would be with FROST signature fragments.

Then the ‘fragment’ size can be optimize to fit inside a few LoRa packets, we might solve the chunking overhead. Plus, with the Z3 stack and Zaino, the user only needs to receive the specific data for their coins from the satellite, not the whole chain.

To be honest I believe requiring extra individual hardware would be a kiss of death for a a project like this for the primary demographics.

1 Like
8

Interesting problem.

If the constraint is zero internet at point of transaction, then the hard question is: where does state live and how does it update?

A few thoughts, operator-style:

  • If the gateway has intermittent connectivity (not the user), then you’re basically building an offline signing + delayed broadcast model. That’s doable.

  • If nobody has connectivity at transaction time, you’re dealing with voucher / pre-authorization mechanics, not real-time settlement.

On your questions:

FROST?
FROST makes sense if you’re worried about a single gateway holding too much signing power. Threshold signing across distributed operators could reduce custody risk. But it doesn’t solve offline state sync by itself.

ZK-ID / Sybil resistance?
If this is aid distribution, yes some form of identity constraint matters. Otherwise offline vouchers get farmed fast. ZK-based identity proofs could help, but they add complexity and onboarding friction.

The real design tension is:

  • Privacy

  • Sybil resistance

  • Offline usability

  • Custody risk

You probably can’t maximize all four.

If I were sketching it high-level:

  • Pre-mint shielded vouchers

  • Distribute via SMS/QR

  • Redeem through semi-trusted gateways with periodic settlement on-chain

  • Threshold keys (FROST-style) for treasury control

But the key question back to you:

Are you trying to eliminate trust in the gateway entirely, or reduce it to an acceptable operational level?

Because fully trustless + fully offline is a very high bar.

1 Like
9

You’re right, trying to maximize all four would be a massive undertaking. If I had to realistically compromise I would rather have it be acceptable operationally, as long as it allows users in areas where the internet has been disrupted to still have access to the funds. A fully trustless, fully offline system would be perfect, but in a crisis zone, we can accept a model where the Gateway/aid station is a semi-trusted entity that uses FROST style to minimize custody risk as long as it maintains offline usability.

My current thinking:

State Management: Treat the Gateway as the temporary source of truth. The user’s “state” is updated via a signed receipt (FROST fragment) that the Gateway syncs to the chain whenever it gets even a 2G/satellite heartbeat.

FROST + SMS: Since a signature fragment is only ~64 bytes, it fits within the constraints that we’re working with.

ZK-ID: I agree on the friction, I’m not sure what a workaround would be, it would quickly get abuse without some sort of sybil resistance. Any thoughts?

10

This is getting into the kind of design space where Zcash is actually philosophically aligned, but the constraints are brutal.

First: I agree with your compromise.
In a crisis zone, “acceptable operational trust” > theoretical purity. If the goal is resilient aid distribution under network disruption, usability dominates.

Now on your updated model:

:one: Gateway as temporary source of truth

Treating the gateway as the interim state holder + periodic settlement anchor is realistic.

But here’s the sharp edge:

If the gateway is the temporary ledger, your biggest risk isn’t custody it’s double redemption during offline windows.

Even with FROST-style threshold custody, you still need:

  • A local, append-only log

  • Deterministic voucher IDs

  • Replay protection logic

  • Clear settlement rules once connectivity resumes

Otherwise, two offline redemptions of the same voucher across different semi-isolated gateways becomes your failure mode.

So the real question becomes:
Are gateways federated (shared state sync between them), or isolated nodes?

That determines your Sybil and replay threat model.

:two: FROST + SMS feasibility

FROST-style threshold signing is elegant here.

Entity reference: FROST

Using it for treasury control makes sense. It reduces:

  • Insider risk

  • Key seizure risk

  • Single point compromise

But FROST doesn’t help with:

  • Identity uniqueness

  • Double-spend detection offline

  • Voucher farming

It protects fund custody, not distribution fairness.

Your architecture distinction should be:

  • FROST → treasury integrity

  • Voucher system → distribution integrity

Different layers.

:three: The Sybil problem (this is the real dragon)

You’re right: without identity constraints, vouchers get farmed immediately.

But full ZK-ID in crisis zones is heavy:

  • Key management

  • Recovery

  • UX friction

  • Device assumptions

Instead of jumping to full ZK identity, consider layered Sybil resistance:

Option A: Human friction > cryptographic friction

In disaster zones, often the strongest Sybil control is physical:

  • In-person distribution

  • Local NGOs as introducers

  • One-time physical token issuance

  • SIM-bound registration

It’s not trustless. But it’s operationally robust.

Option B: Device-bound lightweight proofs

Instead of full ZK-ID, use:

  • SIM-bound hash commitments

  • Device keypair generated on first interaction

  • Rate limits per device

  • Time-based issuance windows

It’s weaker than ZK identity, but massively simpler.

Option C: Blind-signed eligibility tokens

Before crisis (or at first connectivity window):

  • User gets blind-signed eligibility credential

  • Credential used to mint vouchers offline

  • Gateway verifies signature, not identity

This preserves privacy while limiting minting to pre-authorized participants.

That may be the sweet spot.

:four: Important structural tension

Your system is balancing:

  • Privacy (shielded, minimal data)

  • Offline usability

  • Sybil resistance

  • Gateway trust minimization

The moment you increase Sybil resistance, you increase:

  • Friction

  • Metadata

  • Operational complexity

In a crisis system, simplicity is survival.

:five: A More Brutal but Honest Framing

You’re not building:

A censorship-resistant global payment system.

You’re building:

A resilient humanitarian distribution rail under degraded connectivity.

Those are different engineering priorities.

If I were sketching a pragmatic V1:

  • Pre-minted shielded pool on-chain

  • FROST-controlled treasury

  • Blind-signed eligibility tokens issued during connectivity

  • SMS/QR voucher redemption

  • Local gateway ledger with strict replay protection

  • Periodic settlement anchoring to Zcash chain

  • Public audit transparency for aggregate flow (not identities)

That keeps:

  • Privacy at the user layer

  • Treasury security via FROST

  • Sybil resistance via pre-issued credentials

  • Offline capability via voucher mechanics

The real question for you:

Are users expected to have smartphones?

Because the architecture changes radically between:

  • Feature phone + SMS environment

  • Smartphone with local key storage + QR support

That one constraint determines whether ZK-lite is feasible or whether you must lean more heavily on physical-world trust.

Curious what environment you’re optimizing for.