Services charging fees in ZEC?

Currently transaction fees in ZEC only contribute to funding miners and dev fund. But what about services that want to charge a native ZEC fee for their services?

As an example, many exchanges generate profit through fees for each transaction. Sometimes these fees are:

  1. Implicit through a spread.
  2. Explicit using one side of the pair as the fee currency.
  3. Explicit using an exchange specific token (that may have been intially sold to investors. e.g. ICO token).
  4. Explicit using the native blockchain currency (e.g. BTC, ETH, ZEC…).

With the development of ZSAs well underway I imagine in the first instance exchanges will charge fees through a spread. Have we thought into what features Zcash would need to enable for 2, 3, and 4?

Exchanges aren’t the only service that may want to enable this kind of business model. Maybe a point of sales system wants to subsidise hardware costs by charging a small on-chain transaction fee. Maybe a crowdfunding site wants to be explicit about their fees. I’m not 100% sure what this looks like but it feels a little “atomic ops”. Also as stated in the exchanges example I think it’s beneficial for ZEC if we allow exchanges to charge an extra ZEC fee rather then only allowing service providers to charge fees in the underlying ZSA exchange pair. Thoughts?

P.S. I’m well aware we probably don’t want to contribute negatively to the privacy of Zcash by adding this fee publically to the blockchain transaction fee so maybe it’d have to make it private as part of the transaction…?

1 Like

Wouldn’t this be enabled at the service provider side, by creating a Payment URI with multiple recipients of the transaction? This way one of the outputs could go to the exchange for fees, directly from the end-user(sender).

1 Like

Sure a simple multi input/output would work :+1:. Definitely one option.

Multi input/output transaction (URI)

Pros

  • Already exists
  • Easy for service provider to implement

Cons

  • User/bot has to interact with a centralised point for URI distribution
  • Hard to return funds if fee isn’t paid or doesn’t match amount required
  • No way for service provider to notify programmatic algorithms/bots that interact solely with blockchain if fee/transaction structure requirements change

Comparisons

  • ETH users/bots can interact solely with blockchain (no centralised URI distribution)
  • ETH smart contracts can fail and/or return funds
  • ETH users/bots get real-time feedback when things don’t work/change/fail

How is a unified interaction point bad? Maybe I need to understand the kind of architecture you are thinking of.

The user has control over what goes in the memo, the contract can require the bots/users to add a reply-to address for interaction.

Yeah, more work needs to be done to plan out a Shielded DEX.

ETH is a transparent Account-based system that has its own trade-offs.

1 Like

Yep URI + memo based system is a good suggestion too.

Multi input/output transaction (URI + Memo reply-to)

Pros

  • Uses already existing tech
  • Easy for services to support
  • Can return funds to reply-to address, including memo describing why

Cons

  • User/bot has to interact with centralised point for URI distribution

Optional

  • On-chain marker that tells wallets which address expect a reply-to address in memo

Compare

  • ETH users/bots can interact solely with blockchain (no centralised URI distribution required)

Correct me if your wrong but I think your suggesting below. Another good suggestion.

Multi input/output transaction (Static address + Memo reply-to + Memo api)

Pros

  • Uses already existing tech
  • Easy for services to support
  • Can return funds to reply-to address, including memo describing why
  • Once address is know user/bot can interact with API, no ongoing distribution URI required

Cons

  • No way to revoke an address

Optional

  • On-chain marker that tells wallets which address expect a reply-to address and/or API endpoint in memo
1 Like

Wouldn’t this be a pro? Shielded Address provides privacy and may not require address change for a specific contract transaction.

1 Like