# XIP-57: Messaging fee collection

**URL:** <https://improve.xmtp.org/t/xip-57-messaging-fee-collection/876>\
**Category:** Final XIPs\
**Created:** [February 26, 2025, 5:49pm UTC](https://improve.xmtp.org/t/xip-57-messaging-fee-collection/876 "2025-02-26T17:49:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![fbac](https://improve.xmtp.org/user_avatar/improve.xmtp.org/fbac/32/1006_2.png) [@fbac](https://improve.xmtp.org/u/fbac)\
**Post date:** [February 26, 2025, 5:49pm UTC](https://improve.xmtp.org/t/xip-57-messaging-fee-collection/876/1 "2025-02-26T17:49:51Z")

</div>

> <https://github.com/xmtp/XIPs/blob/main/XIPs/xip-57-messaging-fee-collection.md>

---

<div class="post-metadata">

**Author:** ![Javier\_SL](https://improve.xmtp.org/user_avatar/improve.xmtp.org/javier_sl/32/1110_2.png) [@Javier\_SL](https://improve.xmtp.org/u/Javier_SL)\
**Post date:** [August 26, 2025, 6:19pm UTC](https://improve.xmtp.org/t/xip-57-messaging-fee-collection/876/2 "2025-08-26T18:19:08Z")

</div>

As the 2025 roadmap sets this XIP for summer, I can’t really tell how far this XIP is in the development process, since it’s still tagged as XIP Stage 1: Drafts in community forums. Still, I’d like to ask: Why was this approach preferred to a subscription-based model?

---

<div class="post-metadata">

**Author:** ![nick](https://improve.xmtp.org/user_avatar/improve.xmtp.org/nick/32/466_2.png) [@nick](https://improve.xmtp.org/u/nick)\
**Post date:** [August 26, 2025, 8:26pm UTC](https://improve.xmtp.org/t/xip-57-messaging-fee-collection/876/3 "2025-08-26T20:26:55Z")

</div>

You’re right that we should update the status. This has been implemented and is in recent releases of [`xmtpd`](https://github.com/xmtp/xmtpd/releases).

There’s two reasons we prefer “pre-fund your account” to subscriptions

1. Allows for “pay for what you use” pricing, which is the fairest and hardest to game. You get exactly what you pay for, with no extra costs for unused credits. You can withdraw any excess funds at any time.
2. Smart contracts still aren’t great for implementing pull based subscription models.