Skip to content

Conversation

@freddiecoleman
Copy link
Contributor

No description provided.

@freddiecoleman freddiecoleman force-pushed the 39_fee_service branch 2 times, most recently from bca97a3 to 04c9fd9 Compare December 17, 2024 11:00
@danieljperry
Copy link
Contributor

This CHIP is a Draft. It proposes a standard way for a service to include fees with transactions. Feel free to leave a review here, or to comment in the #chips channel of our Discord.

@Yakuhito
Copy link
Contributor

Great CHIP! I can see some situations where services might need a few mojos to start a transaction. For example:

  • Minting singletons (e.g., vaults/NFTs) requires 1 mojo
  • Minting CATs currently requires 1000 mojos/CAT
  • A 'subset' of minting CATs is finishing bridging operations, where one needs to provide the mojos needed to mint the wrapped tokens

Would it make sense to have the same services be able to provide a one-sided offer to get the mojos required to build transactions with? This is what I did for the warp.green welcome kits. The fee could very well still be attached at the end (when the final spend bundle is available), but could also be included in the initial offer if the app knows what fee it'll need. That way, you also remove some trust in the service, as the dApp itself can push the spend bundle to the mempool.

@danieljperry
Copy link
Contributor

Great CHIP! I can see some situations where services might need a few mojos to start a transaction. For example:

* Minting singletons (e.g., vaults/NFTs) requires 1 mojo

* Minting CATs currently requires 1000 mojos/CAT

* A 'subset' of minting CATs is finishing bridging operations, where one needs to provide the mojos needed to mint the wrapped tokens

Would it make sense to have the same services be able to provide a one-sided offer to get the mojos required to build transactions with? This is what I did for the warp.green welcome kits. The fee could very well still be attached at the end (when the final spend bundle is available), but could also be included in the initial offer if the app knows what fee it'll need. That way, you also remove some trust in the service, as the dApp itself can push the spend bundle to the mempool.

This is certainly something that could be added to a fee paying service, but I'm not sure if it belongs in the CHIP. Let's plan to have a public zoom call to discuss this, and other ideas pertaining to the CHIP, early in 2025.

@danieljperry
Copy link
Contributor

We had a discussion of this CHIP, with several ideas for improving it and implementing it.
https://youtu.be/kWXT4WXtkC4

@danieljperry
Copy link
Contributor

This CHIP has had a working implementation in production for several months. It is now in Review. Please leave your reviews here.

@danieljperry
Copy link
Contributor

This CHIP is now in Last Call. If no changes are required in the next two weeks, it will be moved to Final status.

@danieljperry
Copy link
Contributor

This CHIP is now Final. No further changes are allowed, other than adding errata. Thanks @freddiecoleman !

@danieljperry danieljperry merged commit 0c510dc into main Nov 21, 2025
5 checks passed
@danieljperry danieljperry deleted the 39_fee_service branch November 21, 2025 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants