Atomic Multi-Recipient Settlement for Sponsored Transactions

Core Blockchain
1

I was diving deeper into sBTC sponsored transactions and became interested in the possibility of enabling a broader sponsorship market. I found some good discussions around this idea already, particularly the direction of leaving dynamic sponsorship markets to third-party infrastructure.

What I realized, however, is that a meaningful sponsorship market may require a small but important improvement to the transaction flow: the ability for a user to atomically send funds to multiple recipients in a single sponsored transaction.

This would allow a sponsored transaction to seamlessly settle the actual payment while also reimbursing the sponsor/operator—and potentially a protocol or service fee—without requiring additional transactions or infrastructure from the user.

This led me to the idea of Atomic Sponsored Multi-Recipient Settlement.

1.1 Context & Purpose

The current sponsored transaction model already provides an important primitive: a user can authorize a transaction while a separate sponsor pays the Stacks transaction fee.

The missing piece for a potential sponsorship market is the settlement mechanism between the user and the sponsor.

For example, imagine a user wants to send 100 sBTC:

100 sBTC
├── 98.00 sBTC → Recipient
├── 1.50 sBTC  → Sponsor / Operator
└── 0.50 sBTC  → Protocol / Service

Ideally, the user should only need to sign one transaction.

The sponsor would pay the required STX fee, while the transaction itself atomically executes all required sBTC transfers.

Conceptually:

User
 │
 │ signs settlement
 ▼
Sponsored Contract Call
 │
 ├── sBTC → Recipient
 ├── sBTC → Sponsor / Operator
 └── sBTC → Protocol
 │
 │ Sponsor signs fee authorization
 ▼
Stacks

This could allow a third-party sponsorship market to operate without requiring users to:

  1. Hold STX.
  2. Make a separate reimbursement transaction.
  3. Pay the operator through a separate transaction.
  4. Make a separate protocol-fee transaction.
  5. Coordinate multiple transactions with the sponsoring service.

From the user’s perspective, the experience could remain simply:

Send 100 sBTC.

The underlying transaction would contain the complete economic settlement.

This could be implemented through a contract-call based model rather than necessarily introducing a new transaction type. The key question is whether existing sponsored transaction authorization, Clarity execution, token transfers, and post-conditions are sufficient to provide this functionality efficiently and safely.

Why this matters for sponsorship markets

A dynamic sponsorship market could look like:

User
 │
 │ request sponsorship
 ▼
Operator / Sponsor
 │
 │ quote
 ▼
User signs transaction
 │
 │
 ├── payment → recipient
 ├── reimbursement → operator
 └── fee → protocol
 │
 ▼
Sponsor pays STX fee
 │
 ▼
Stacks

This would allow infrastructure such as a relay/network to focus on:

  • sponsor discovery;
  • pricing;
  • operator selection;
  • STX liquidity;
  • reimbursement policies;
  • availability;
  • reputation;
  • routing.

The underlying sBTC/Stacks transaction mechanism would remain neutral to any particular sponsorship marketplace.

This also seems complementary to previous discussions around dynamic sponsorship markets: if sponsorship markets are expected to be built by third parties, having a native, composable way to atomically settle the sponsor’s reimbursement could significantly reduce the infrastructure required around them.

2. Technical Details

The proposal is to investigate whether an existing sponsored contract-call can support an atomic multi-recipient settlement pattern.

A conceptual interface could look like:

settle(
    asset,
    recipients
)

where recipients represents an arbitrary list of destination/amount pairs:

[
    { to: recipient_1, amount: amount_1 },
    { to: recipient_2, amount: amount_2 },
    { to: recipient_3, amount: amount_3 },
    ...
]

For example:

settle(
    sBTC,
    [
        { to: Recipient, amount: 98.0 },
        { to: Operator, amount: 1.5 },
        { to: Protocol, amount: 0.5 }
    ]
)

Resulting in:

User's asset balance
        │
        ▼
Settlement contract
   ├──→ Recipient
   ├──→ Operator
   ├──→ Protocol
   └──→ Recipient N

The settlement interface itself would remain agnostic about the purpose of each recipient. A destination could represent a merchant, another user, an operator, a protocol, a treasury, or any other participant.

Sponsorship would remain a property of the transaction authorization layer rather than being encoded into the settlement interface. The user signs the complete transaction, while the sponsor separately authorizes the transaction as the fee payer.

The sponsor should therefore be able to verify exactly:

  • the settlement contract and function;
  • the asset being transferred;
  • every recipient;
  • every amount;
  • the total settlement amount;
  • the transaction fee;
  • the nonce and other relevant authorization data.

This means the sponsor does not need to trust the user or a relayer to perform any subsequent reimbursement or settlement transaction.

Atomicity

The desired behavior is that all transfers within the settlement succeed or fail together.

For example:

Recipient transfer A    ✓
Recipient transfer B    ✓
Recipient transfer C    ✓
                         ↓
                      SUCCESS

If any required transfer fails:

Recipient transfer A    ✓
Recipient transfer B    ✗
Recipient transfer C    —
                         ↓
                  Entire settlement
                      fails

This should be evaluated against existing Clarity transaction semantics, asset-transfer behavior, and post-condition guarantees.

The key property is that a single user-authorized transaction should be able to express and atomically execute the complete multi-party settlement, while sponsorship remains independent from the settlement’s economic semantics.

Potential UX improvement

The current approach to implementing a sponsorship market could require additional coordination between the application, user, sponsor and settlement mechanism.

A multi-recipient settlement primitive could reduce this to:

1. User requests quote
2. Operator accepts
3. User signs
4. Operator signs sponsorship
5. Transaction is broadcast

The user does not need to acquire STX or execute a separate reimbursement transaction.

Potential efficiency considerations

A contract-call may introduce additional execution and transaction costs compared with a native token-transfer transaction.

Therefore, the proposal should explicitly measure whether:

additional contract execution cost

is outweighed by:

eliminated reimbursement transactions
+ simplified sponsorship infrastructure
+ improved UX

The investigation should also determine whether multiple transfers can be performed efficiently enough to make this practical for high-volume sponsorship providers.

Generalization

Although the immediate use case is sBTC, it may be worth considering whether the settlement mechanism should be compatible with arbitrary SIP-010 fungible tokens.

This could make the primitive useful for:

  • sBTC;
  • stablecoins;
  • payments;
  • subscriptions;
  • DEX interactions;
  • applications requiring gas abstraction;
  • future sponsorship markets.

The implementation should not, however, require a particular sponsorship marketplace or operator model.

Security considerations

The investigation should cover at least:

  • User authorization of the complete settlement.
  • Sponsor verification before paying the STX fee.
  • Protection against changing settlement parameters after user signing.
  • Replay protection.
  • Transaction nonce handling.
  • Post-condition compatibility.
  • Sponsor denial-of-service considerations.
  • Contract upgradeability.
  • Malicious settlement contracts.
  • Unexpected token transfers.
  • Operator reimbursement manipulation.
  • Failure behavior when one recipient transfer cannot execute.

2.1 Acceptance Criteria

  • Demonstrate a sponsored sBTC contract-call where the user does not hold STX.
  • Demonstrate atomic transfer of sBTC to the intended recipient and reimbursement to a sponsor/operator within the same transaction.
  • Demonstrate an optional third transfer to a protocol/service address.
  • Verify that the user signs the complete settlement before sponsorship.
  • Verify that the sponsor can independently validate all settlement parameters before signing.
  • Verify that the sponsor cannot modify recipient, payment amount, or reimbursement after user authorization.
  • Verify atomic failure behavior if any required settlement condition fails.
  • Evaluate whether existing post-conditions provide sufficient protection.
  • Measure transaction size and STX fee compared with a conventional sponsored sBTC transfer.
  • Measure additional Clarity execution cost.
  • Compare the cost of atomic settlement against separate reimbursement transactions.
  • Evaluate whether the mechanism can support multiple recipients efficiently.
  • Evaluate replay and double-reimbursement risks.
  • Determine whether existing Stacks primitives are sufficient.
  • Determine whether any Stacks-core or sBTC-specific changes are required.
  • Produce a minimal proof of concept demonstrating the complete flow.
  • Document whether this primitive could support future third-party sponsorship markets without requiring protocol-level knowledge of a specific operator or marketplace.

3. Related Issues and Pull Requests

Originally published at: [Feature]: Atomic Sponsored Multi-Recipient Settlement for sBTC · Issue #2100 · stacks-sbtc/sbtc · GitHub

**What do you think could be next steps for making that R&D go forward?

How can we get into consensus for opening doors to a safe Sponsorship Market for sBTC, stablecoins and assets?**