#42896 [BC-High] attackers can exploit sequence number tolerance mechanism to to cause movement network da lightnode loose money for submitting failed blocks to celestia

#42896 [BC-High] Attackers can exploit sequence_number tolerance mechanism to to cause Movement Network DA Lightnode loose money for submitting failed blocks to Celestia

Submitted on Mar 28th 2025 at 14:18:07 UTC by @perseverance for Attackathon | Movement Labs

• Report ID: #42896

• Report Type: Blockchain/DLT

• Report severity: High

• Target: https://github.com/immunefi-team/attackathon-movement/tree/main/protocol-units/execution/maptos/opt-executor

• Impacts:

  • Direct loss of funds

  • Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments

Description

Background Information and Vulnerability Details

sequence_number tolerance

When users submit transactions to mempool, it is allowed that the sequence number is in range from commited_sequence_number (that is sequence number of the last succesfull transaction of the user) + 1 to commited_sequence_number + TOO_NEW_TOLERANCE ( = 32) .

The sequencer node check for valid sequence number in submit_transaction function.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/execution/maptos/opt-executor/src/background/transaction_pipe.rs#L267-L272

	async fn submit_transaction(
		&mut self,
		transaction: SignedTransaction,
	) -> Result<SubmissionStatus, Error> {
	// SNIP 
	let sequence_number = match self.has_invalid_sequence_number(&transaction)? {
			SequenceNumberValidity::Valid(sequence_number) => sequence_number,
			SequenceNumberValidity::Invalid(status) => {
				return Ok(status); // @note if the sequence number is invalid, we return the status immediately without adding the transaction to the mempool
			}
		};
	// 

The check for sequence number can be seen in the function has_invalid_sequence_number

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/execution/maptos/opt-executor/src/background/transaction_pipe.rs#L179-L218

// this checks that the sequence number is too old or too new
		let committed_sequence_number =
			vm_validator::get_account_sequence_number(&state_view, transaction.sender())?;

		debug!(
			"Used sequence number: {:?} Committed sequence number: {:?}",
			used_sequence_number, committed_sequence_number
		);
		let min_used_sequence_number =
			if used_sequence_number > 0 { used_sequence_number + 1 } else { 0 }; 

		let min_sequence_number = (min_used_sequence_number).max(committed_sequence_number);

		let max_sequence_number = committed_sequence_number + TOO_NEW_TOLERANCE;

		info!(
			"min_sequence_number: {:?} max_sequence_number: {:?} transaction_sequence_number {:?}",
			min_sequence_number,
			max_sequence_number,
			transaction.sequence_number()
		);

		if transaction.sequence_number() < min_sequence_number {
			info!("Transaction sequence number too old: {:?}", transaction.sequence_number());
			return Ok(SequenceNumberValidity::Invalid((
				MempoolStatus::new(MempoolStatusCode::InvalidSeqNumber),
				Some(DiscardedVMStatus::SEQUENCE_NUMBER_TOO_OLD),
			)));
		}

		if transaction.sequence_number() > max_sequence_number {
			info!("Transaction sequence number too new: {:?}", transaction.sequence_number());
			return Ok(SequenceNumberValidity::Invalid((
				MempoolStatus::new(MempoolStatusCode::InvalidSeqNumber),
				Some(DiscardedVMStatus::SEQUENCE_NUMBER_TOO_NEW),
			)));
		}

		Ok(SequenceNumberValidity::Valid(committed_sequence_number))
	}

So 1 user can submit maximum 32 transactions with sequence number from commited_sequence_number + 1 to commited_sequence_number + 32.

Validation separate transaction before commiting to the mempool

Please note that when user submit a transaction to the mempool, the transaction is validated against the latest state view of the blockchain. Each transaction is validated separately. The behavior is seen in the code as following.

As comment and the code show that each transaction is validated with re-creation with latest database.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/execution/maptos/opt-executor/src/background/transaction_pipe.rs#L250-L253

async fn submit_transaction(
		&mut self,
		transaction: SignedTransaction,
	) -> Result<SubmissionStatus, Error> {
    // SNIP
    // Pre-execute Tx to validate its content.
		// Re-create the validator for each Tx because it uses a frozen version of the ledger.
		let vm_validator = VMValidator::new(Arc::clone(&self.db_reader));
		let tx_result: aptos_types::transaction::VMValidatorResult = vm_validator.validate_transaction(transaction.clone())?;

    // SNIP
}

So if each transaction passed the validation then it is included in the mempool.

Lifecycle of a transaction

The transactions passed validation from the mempool ==> included in the mempool ==> submit (or batch_write) to DA Lightnode

Then the transactions are included in blocks and sent from DA Lightnode to Celestia. Code is here: https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/sequencing/memseq/sequencer/src/lib.rs#L101-L131

/// Waits for the next block to be built, either when the block size is reached or the building time expires.
	async fn wait_for_next_block(&self) -> Result<Option<Block>, anyhow::Error> {
		let mut transactions = Vec::with_capacity(self.block_size as usize);

		let now = Instant::now();

		loop {
			let current_block_size = transactions.len() as u32;
			if current_block_size >= self.block_size {
				break;
			}

			let remaining = self.block_size - current_block_size;
			let mut transactions_to_add = self.mempool.pop_transactions(remaining as usize).await?;
			transactions.append(&mut transactions_to_add);

			// sleep to yield to other tasks and wait for more transactions
			tokio::task::yield_now().await;

			if now.elapsed().as_millis() as u64 > self.building_time_ms {
				break;
			}
		}

		if transactions.is_empty() {
			Ok(None)
		} else {
			let new_block =
				self.build_next_block(block::BlockMetadata::default(), transactions).await?;
			Ok(Some(new_block))
		}
	}

So this function wait_for_next_block batch the transactions to build the block the DA Lightnode batch maximum 10 transactions to a block and build blob to send to Celestia.

The blob will be signed and pay for gas by DA Lightnode.

Executor get / read Blocks from Celestia and execute blocks.

The cost of submitting blob Data is covered by Movement Team and is higher than the cost of a transaction

Gas Unit Price

For the Gas Unit Price Analytics show that users usually submit transactions with the Gas Unit Price from 100 to 125 Octas.

See analytics here: https://explorer.movementnetwork.xyz/analytics?network=mainnet

So the gas unit price is in range from 100 to 200 Octas Move.

Suppose the cost is 200 Octas Move

MOVe price = 0.54 USD

Gas Fee of a simple transfer would be = 0.000402 MOVE = 40_200 Octas MOVE let's assum maximum to be 50_000 Octas

=> Cost of gas fee for a simple transfer : 0.0005 MOVE * 0.54 = 0.00027 USD

Cost of submitting blobs to Celestia

So take some example transactions in celestia, https://celenium.io/tx/9b00e984362bfd0db1b67906608829cf3d9d6a6994e36178bc2de2a9781f9044?tab=messages

The cost of gas on Celestia is 0.034763 for 1019 Bytes => TIA Price = 3.66 ( https://coinmarketcap.com/vi/currencies/celestia/) => Cost for 1 transaction: 0.05 * 3.65 = 0.183 USD

The maximum size of a blob is 2 MB. The blob of blocks that can maximum contains 10 transactions. So the data probably can be bigger and cost more gas, but let's take 0.183 USD as sample for this

So you can notice that the gas pay by users is much less than the gas pay by DA Lightnode.

Attack Scenario

So attacker can submit a transaction 32 transactions as followed

Attacker_Account_1 current sequence number is commited_sequence_number 

Attacker_Account_1 has balance of 1 MOVE 

Transaction 1: Attacker  from Attacker_Account_1 transfer 0.9995 MOVe to Attacker_account2 with sequence number = `commited_sequence + 1`

Attacker_Account_1 has balance big enough to cover the gas fee for 2nd and other transactions, let's say: 1 MOVE

Transaction 2: Attacker_Account1 create a transaction with maximum payload size with Sequence number = `commited_sequence + 2`. The payload maximum is 64 Kbytes. For example, a transaction to create a big smart contract. 

...

Transaction 32: Attacker_Account1 create a transaction with maximum payload size with Sequence number = `commited_sequence + 32`. The payload maximum is 64 Kbytes. For example, a transaction to create a big smart contract. 

The attacker create 31 transactions with maximum payload data to cause maximum gas pay by DA Lightnode to submit blobs to Celestia.

Attack Analysis

So the attacker sent all of this transactions to the mempool in 1 seconds, so all the transactions entered the mempool.

Each transaction will be validated separately. So each transaction will pass validation. So each transaction is included in the mempool.

They will be sent to DA Lightnode.

The transactions will be included in at least 4 blobs. because each blob can contain only maximum 10 transactions.

When the executor get the blob and execute the transactions in sequence.

• Transaction 1 will pass. After transaction 1, Attacker_Account_1 sent 0.9995 MOVe and spent 0.0005 Move for gas.

Attacker_Account_1 balance = 0 Attacker_Account_2 balance = 0.9995 MOVe

Governed_gas_pool of Movement received 0.0005 Move

• After transaction 1, Attacker_Account_1 balance = 0 so all other transactions will fail

The Movement Network received nothing.

But the Movement DA Lightnode need to spend gas to submit to Celestia for at least 3 blobs.

=> Cost for 1 transaction: 0.05 * 3.65 = 0.183 USD

=> Cost for 3 transactions: 0.183 * 3 = 0.549 USD

Cost of attack and Impact analysis

So the cost for attacker: 0.0005 Move = 0.00027 USD

The damage for the Movement project: 0.549 USD - 0.00027 USD = 0.54873

The the cost attack ratio per damage is 1 : 2032 that is quite huge number.

So suppose the cost for attacker is 1000 USD => The damage for project: 1000 * 2032 = 2_032_000 USD

The cost for Movement Network can be bigger when take into calculation the actual payload size of blob. In above calculation, I took the gas paid for a simpe small payload of 1019 Bytes.

With this huge ratio, then if the attacker can gain some profit to cover the cost, then he is likely to execute the attack.

Severity Assessment

Bug Severity: Critical

Impact:

• Loss of funds for Movement Project

• Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments

Impact:

• Caused DA Lightnode to spend much gas to pay for failed transactions

• Resource waste: The sequencer and executor executed almost failed transactions.

• Severe degredation quality of service since other transactions of valid users can have some delay

Likelihood:

• High as No special privileges required

• Can be executed by any user with very cheap cost of attack

The cost of attack vs the damage for project is 1: 2032 ratio

So the cost to cause total denial of service of Movement for 1 day is can be just 7.5 USD depends on how much spam transactions. It is very cheap.

the cost to cause total denial of service of Movement for 1 month is just 224 USD . It is very cheap.

So suppose the cost for attacker is 1000 USD => The damage for project: 1000 * 2032 = 2_032_000 USD

Proof of Concept

Proof of concept

The following attack scenario demonstrate the bug.

Step 1: Setup.

Attacker_Account_1 current sequence number is commited_sequence_number = 0 

Attacker_Account_1 has balance of 1 MOVE 

Transaction 1: Attacker  from Attacker_Account_1 transfer 0.9995 MOVe to Attacker_account2 with sequence number = `0`

Attacker_Account_1 has balance big enough to cover the gas fee for 2nd and other transactions, let's say: 1 MOVE

Transaction 2: Attacker_Account1 create a transaction with maximum payload size with Sequence number = `1`. The payload maximum is 64 Kbytes. For example, a transaction to create a big smart contract. 

...

Transaction 32: Attacker_Account1 create a transaction with maximum payload size with Sequence number = `31`. The payload maximum is 64 Kbytes. For example, a transaction to create a big smart contract. 

Step 2: The attacker sends 32 transactions within 1 seconds, and these transactions enter the mempool. To bypass the rate limit, can send transactions from different machines, IPs

Step 3: Repeat the attack to continue. Can create more accounts if needed

Exact attack scenario can be refined with more test, but can be easily done.

Attackers can create a script to execute this attack.