[Discuss] Should we add the `resourceFee` in `sorobanData` to the `fee`?

[overcat]

Describe the bug
Currently, when we call TransactionBuilder.builder, regardless of whether sorobanData exists or not, the way we calculate the fee is op_count * baseFee. However, the meaning of the fee is the maximum stroops willing to be paid for this transaction. So I wonder if we should add the resourceFee in sorobanData to the fee?

What version are you on?

c4f9989

To Reproduce
See

js-stellar-base/src/transaction_builder.js

Lines 579 to 681 in c4f9989

	/**
	* This will build the transaction.
	* It will also increment the source account's sequence number by 1.
	* @returns {Transaction} This method will return the built {@link Transaction}.
	*/
	build() {
	const sequenceNumber = new BigNumber(this.source.sequenceNumber()).plus(1);
	const fee = new BigNumber(this.baseFee)
	.times(this.operations.length)
	.toNumber();
	const attrs = {
	fee,
	seqNum: xdr.SequenceNumber.fromString(sequenceNumber.toString()),
	memo: this.memo ? this.memo.toXDRObject() : null
	};
	if (
	this.timebounds === null ||
	typeof this.timebounds.minTime === 'undefined' ||
	typeof this.timebounds.maxTime === 'undefined'
	) {
	throw new Error(
	'TimeBounds has to be set or you must call setTimeout(TimeoutInfinite).'
	);
	}
	if (isValidDate(this.timebounds.minTime)) {
	this.timebounds.minTime = this.timebounds.minTime.getTime() / 1000;
	}
	if (isValidDate(this.timebounds.maxTime)) {
	this.timebounds.maxTime = this.timebounds.maxTime.getTime() / 1000;
	}
	this.timebounds.minTime = UnsignedHyper.fromString(
	this.timebounds.minTime.toString()
	);
	this.timebounds.maxTime = UnsignedHyper.fromString(
	this.timebounds.maxTime.toString()
	);
	const timeBounds = new xdr.TimeBounds(this.timebounds);
	if (this.hasV2Preconditions()) {
	let ledgerBounds = null;
	if (this.ledgerbounds !== null) {
	ledgerBounds = new xdr.LedgerBounds(this.ledgerbounds);
	}
	let minSeqNum = this.minAccountSequence || '0';
	minSeqNum = xdr.SequenceNumber.fromString(minSeqNum);
	const minSeqAge = UnsignedHyper.fromString(
	this.minAccountSequenceAge !== null
	? this.minAccountSequenceAge.toString()
	: '0'
	);
	const minSeqLedgerGap = this.minAccountSequenceLedgerGap || 0;
	const extraSigners =
	this.extraSigners !== null
	? this.extraSigners.map(SignerKey.decodeAddress)
	: [];
	attrs.cond = xdr.Preconditions.precondV2(
	new xdr.PreconditionsV2({
	timeBounds,
	ledgerBounds,
	minSeqNum,
	minSeqAge,
	minSeqLedgerGap,
	extraSigners
	})
	);
	} else {
	attrs.cond = xdr.Preconditions.precondTime(timeBounds);
	}
	attrs.sourceAccount = decodeAddressToMuxedAccount(this.source.accountId());
	// TODO - remove this workaround for TransactionExt ts constructor
	// and use the typescript generated static factory method once fixed
	// https://github.com/stellar/dts-xdr/issues/5
	if (this.sorobanData) {
	// @ts-ignore
	attrs.ext = new xdr.TransactionExt(1, this.sorobanData);
	} else {
	// @ts-ignore
	attrs.ext = new xdr.TransactionExt(0, xdr.Void);
	}
	const xtx = new xdr.Transaction(attrs);
	xtx.operations(this.operations);
	const txEnvelope = new xdr.TransactionEnvelope.envelopeTypeTx(
	new xdr.TransactionV1Envelope({ tx: xtx })
	);
	const tx = new Transaction(txEnvelope, this.networkPassphrase);
	this.source.incrementSequenceNumber();
	return tx;
	}

Expected behavior
See above.
Additional context
N/A

[Shaptic]

This is an interesting callout, sorry it took a literal year to get around to this. This would remove the need for some of the code in assembleTransaction, but it'd be a pretty significant breaking behavioral change that downstream would need to adapt to or risk double-paying.

[overcat]

I implemented a design in the Python SDK and Java SDK that automatically adds resourceFee to maxFee. Then, a user referenced the JS example to write Java code, which led to double-paying because the JS example manually added resourceFee to baseFee. If you're interested, you can take a look at this discussion.

[VyuduInc]

Hey Overcat,

This is a spicy one — the resourceFee question is basically the Soroban tax collector sneaking around the baseFee formula like “yo, don’t forget me.” Right now, TransactionBuilder is keeping it simple with op_count * baseFee, but if the goal is to represent max stroops willing to burn, that resourceFee absolutely deserves a seat at the table.

I’d love to jump in and help unpack this... maybe prototype a version that folds in sorobanData.resourceFee conditionally or flags it with a warning if it's missing. Could even open the door to smarter fee estimates that better reflect Soroban-powered workloads.

Been in the blockchain space since 2017: Forbes Tech Council writer, investor, and dev. Obsessed with clean abstractions and making SDKs smarter without the chaos.

Portfolio if you wanna see the receipts: https://vyudu-links.netlify.app/

Would love to help crack this fee logic wide open,,,

Cheers,