<p>My suspicion is as follows:</p>
<ul>
<li>You saw the tx in block <code>3681998</code> (which must have been the chain tip).</li>
<li>Another block (competing with <code>3681998</code>) was chosen by the consensus algorithm that did not contain that tx.</li>
<li>Block <code>3682001</code> was added that included that tx.</li>
</ul>

CC BY-SA 4.0
2022-07-05T13:20:02.583Z
Thanks for your answer. Maybe that's what happened. Did you notice block `3681998` is empty? How can I check if the block wasn't chosen?
LACE pool
CC BY-SA 4.0
2022-07-05T14:29:33.277Z
Sometimes there are empty blocks. There is no way to check *why* a block wasn't chosen. This is the normal operation of a distributed ledger / blockchain. Read up on how bitcoin chooses blocks.
Erik de Castro Lopo
CC BY-SA 4.0
2022-07-04T22:16:34.457Z
2022-07-06T08:52:17.140Z
2022-07-06T08:52:17.140Z
Erik de Castro Lopo
<p>The latest blocks in the blockchain generally can change for a while until further blocks are created on top and push your transaction down the chain. The &quot;deeper&quot; it gets, the more likely it is not to change.</p>
<p>The two blocks you're pointing to are just ~3 minutes apart, so there doesn't seem to be anything abnormal about it. Here's a good read on these <a href="https://docs.cardano.org/core-concepts/chain-confirmation-versus-transaction-confirmation" rel="nofollow noreferrer">confirmation times / settlement windows</a>.</p>

CC BY-SA 4.0
2022-07-05T09:23:01.983Z
Thanks for your quick response! I should have added to my question that I am aware blocks only become truly immutable after 129600 slots. My question is more about how this specific case occurred. Sorry if I wasn't clear.
LACE pool
CC BY-SA 4.0
2022-07-05T18:55:50.393Z
Ah okay, I don't know of a way to get the data for this specific case unfortunately. But the first block holding your transaction was probably orphaned for a reason that is described nicely in this article: https://www.beaver-stake-pool.net/post/slot-battles-height-battles-and-orphaned-blocks
sean
CC BY-SA 4.0
2022-07-04T22:22:58.017Z
2022-07-04T22:22:58.017Z
sean
<p>Earlier today I submitted a transaction on the Testnet. Shortly after I checked it using blockfrost and got the info my tx is included in block <a href="https://testnet.cardanoscan.io/block/3681998" rel="nofollow noreferrer">3681998</a></p>
<p>A few hours later I checked again, but now the tx is included in block <a href="https://testnet.cardanoscan.io/block/3682001" rel="nofollow noreferrer">3682001</a>.</p>
<p>I am seeking for an explanation how that happened.</p>
<p>Thank you!</p>

<transaction>
How can a transaction first be included in block A, then in block B
# How can a transaction first be included in block A, then in block B

(Asked by: username_0 on 2022-07-04)

Earlier today I submitted a transaction on the Testnet. Shortly after I checked it using blockfrost and got the info my tx is included in block [3681998](https://testnet.cardanoscan.io/block/3681998)

A few hours later I checked again, but now the tx is included in block [3682001](https://testnet.cardanoscan.io/block/3682001).

I am seeking for an explanation how that happened.

Thank you!

**Tags:** transaction

---

## 2 answers

### Answer by username_1 on 2022-07-04. Score: 3 | Accepted answer

My suspicion is as follows:

* You saw the tx in block `3681998` (which must have been the chain tip).
* Another block (competing with `3681998`) was chosen by the consensus algorithm that did not contain that tx.
* Block `3682001` was added that included that tx.

> **Comments:**
> **username_0**: Thanks for your answer. Maybe that's what happened. Did you notice block `3681998` is empty? How can I check if the block wasn't chosen?  
> **username_1**: Sometimes there are empty blocks. There is no way to check *why* a block wasn't chosen. This is the normal operation of a distributed ledger / blockchain. Read up on how bitcoin chooses blocks.  

---

### Answer by username_2 on 2022-07-04. Score: 2

The latest blocks in the blockchain generally can change for a while until further blocks are created on top and push your transaction down the chain. The "deeper" it gets, the more likely it is not to change.

The two blocks you're pointing to are just ~3 minutes apart, so there doesn't seem to be anything abnormal about it. Here's a good read on these [confirmation times / settlement windows](https://docs.cardano.org/core-concepts/chain-confirmation-versus-transaction-confirmation).

> **Comments:**
> **username_0**: Thanks for your quick response! I should have added to my question that I am aware blocks only become truly immutable after 129600 slots. My question is more about how this specific case occurred. Sorry if I wasn't clear.  
> **username_2**: Ah okay, I don't know of a way to get the data for this specific case unfortunately. But the first block holding your transaction was probably orphaned for a reason that is described nicely in this article: https://www.beaver-stake-pool.net/post/slot-battles-height-battles-and-orphaned-blocks  

---

