Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
126 lines (101 sloc) 4.54 KB

Preamble

CAP: 0015
Title: Bump Fee Extension
Author: OrbitLens <orbit.lens@gmail.com>
Status: Draft
Created: 2018-11-26
Updated: 2019-02-13
Discussion: https://groups.google.com/forum/#!topic/stellar-dev/ckzBRlfr2VU
Protocol version: TBD

Simple Summary

This CAP introduces the concept of the "Bump Fee Extension" (BFE) to allow paying transaction fees by arbitrary account.

Abstract

There are a few cases that require charging transaction fees to the account balance other than source account:

  • Games, exchanges, and other applications willing to pay user fees.
  • Pre-signed transactions in case of the base_fee increase.
  • Coordinated multi-sig transactions with insufficient fees.
  • Fee optimization services that can ensure transactions execution in fee racing conditions.

This CAP introduces the way for paying fees for any transaction by extending TransactionEnvelope XDR.

Motivation

The problem of paying fees for another account has been discussed multiple times. Current solutions are based on multi-sig with source account replacement or direct fees "refund" for user accounts. However, both approaches are not ideal and require multi-sig coordination. With the proposed transaction envelope extension users can sign and submit transactions to the application server endpoint which automatically modifies the envelope to allow paying fees from another account.

In the case of base_fee protocol parameter increase, long-lived preauthorized transactions may become invalid because of insufficient fees. Currently, we have no mechanism that would allow changing fees for such transactions, or "pushing" them to the ledger in any other way.

Specification

We introduce three new fields in the TransactionEnvelope XDR:

  • replaceFeeSourceAccount represents the sponsor account for charging fees
  • replaceFee is a maximum fee the sponsor account is willing to pay
  • replaceFeeSignatures contains signatures for the sponsor account
struct TransactionEnvelope
{
    Transaction tx;
    DecoratedSignature signatures<20>;

    union switch (int v)
    {
    case 0:
        void;
    case 1:
        struct
        { 
            // Account ID to charge fees
	        AccountID replaceFeeSourceAccount;
            // the max fee the replaceFeeSourceAccount will pay
            uint32 replaceFee;
            // signatures from replaceFeeSourceAccount signers
            DecoratedSignature replaceFeeSignatures<20>;
       
            union switch (int v)
            {
                case 0:
                    void;
            } ext;
        } v1;
    }
    ext;
};

To confirm the intention to pay fees for the specific transaction on behalf of the sponsor account, replaceFeeSignatures should contain valid signatures from signers of the sponsor account and their total weight should satisfy the low_threshold.

The structure for signing should contain the following fields:

  • transaction hash
  • replaceFee value
  • replaceFeeSourceAccount value

Whenever the validator receives an envelope with replaceFee value set, it loads the account specified as replaceFeeSourceAccount and checks the signatures. If the signatures are valid and low threshold for the replaceFeeSourceAccount is met, the validator adds the replaceFee amount to the original transaction fee bid.

Fee charging logic for such transactions follows general CAP-0005 convention. For the envelopes with bump fee logic, validators should increase the minfee by the base_fee amount to prevent intentional BFE spamming. Envelops with replaceFee amount lower than current base_fee are to be discarded.

Rationale

The proposed solution requires minimum protocol changes and covers a wide range of potential use-cases leaving a room for the possible future modifications. It also resolves the problem of long-lived preauthorized transactions.

Transaction envelops with bump fee extension follow the standard lifecycle, do not require new operations or fundamental changes in ledger entities. Fees for any transaction envelope can be set at any time and resubmitted more than once, for example, in case if the replaceFee amount was not enough.

The transaction fee can be updated implicitly, without any interaction with a user, which provides a consistent user experience. At the same time, the fee sponsor account retains full control and is able to refuse sponsoring fees in any particular situation.