Co-signing and pre-funding

There are two ways to sponsor someone.

Co-signing. The sponsee writes a transaction and names the sponsor in it. Both sign the same transaction. The sponsor sees each one and can refuse any of them. This suits a sponsor who wants tight control.

Pre-funding. The sponsor sets up a budget in advance, like a prepaid card. The budget has two parts:

• An amount of XRP for fees.
• A count of reserves the sponsee may use, for example five items.

After that, the sponsee sends transactions that name the sponsor. The sponsor does not sign each one. The sponsee spends from the budget until it runs out.

The sponsor keeps guardrails on a pre-funded budget:

• A cap on the fee for any one transaction.
• The power to add to the budget or reduce it.
• An option to require the sponsor's signature for fees, for reserves or for both.

The sponsee cannot change these terms or spend more than the budget allows.

Both flows protect the sponsor's signature. In co-signing, the sponsor signs the whole transaction, including the sponsee's account and sequence number. That signature cannot be reused on a different transaction.

Either side can close a pre-funded budget. Unused fee XRP goes back to the sponsor.

Co-signed flow. The transaction carries Sponsor, SponsorFlags and SponsorSignature. SponsorSignature holds SigningPubKey and TxnSignature, or a Signers array when the sponsor multi-signs. With the fixCleanup3_4_0 amendment, sponsor signatures must use role-specific hash prefixes. A standard transaction signature is rejected.

Pre-funded flow. A Sponsorship ledger entry records the arrangement.

Flags on the entry:

• lsfSponsorshipRequireSignForFee (0x00010000): each fee use needs the sponsor's signature.
• lsfSponsorshipRequireSignForReserve (0x00020000): each reserve use needs the sponsor's signature.

With both flags off, the entry's existence is the sponsor's consent.

SponsorshipSet creates, updates or deletes the entry.

• The sender names the other party: Sponsee when the sponsor sends, CounterpartySponsor when the sponsee sends. Exactly one is required.
• FeeAmountDelta moves XRP into the fee budget when positive and back to the sponsor when negative.
• RemainingOwnerCountDelta adds or removes pre-funded owner reserves.
• Deltas add to the stored values. Omitting one leaves that budget unchanged.
• An entry must keep some fee budget or some reserve budget. An empty one fails with tecNO_PERMISSION.
• tfDeleteObject (0x00100000) deletes the entry. Either party can send it. A sponsee can use SponsorshipSet only to delete.

The entry sits in both parties' owner directories. It blocks account deletion for both until removed.

Deleting the entry ends the budget only. Objects created earlier with sponsored reserves keep their Sponsor field. Changing those takes a SponsorshipTransfer.

A Sponsorship entry is optional. A sponsor can co-sign without ever creating one.

Related: Permission delegation, Batch transactions.