Devnet Stacks node stalls at PoX boundary

[fabohax]

Description

On Linux with Clarinet devnet, the Stacks node repeatedly stops processing burn blocks at height 179. Bitcoin continues advancing, but valid application transactions remain unconfirmed in the Stacks mempool.

This reproduced on two fresh devnet chainstates.

Environment

• Clarinet: 3.23.1
• Stacks node: 4.0.1 (62e03cc)
• Docker client/server: 29.1.3
• OS: Linux 6.8.0-136-generic, x86_64
• Network: Clarinet devnet
• Stacks epoch 4.0 configured at burn height 162

Steps to reproduce

1. Start a fresh Clarinet devnet:

clarinet devnet start --no-dashboard --use-on-disk-deployment-plan

2. Wait until the Stacks node is synchronized.

3. Deploy two Clarity contracts, including a SIP-010 token and a contract that dynamically calls its transfer function.

4. Submit several contract calls, waiting for confirmation between calls.

5. Advance burn blocks until crossing the next PoX boundary. For accelerated reproduction:

bitcoin-cli \
  -rpcuser=devnet \
  -rpcpassword=devnet \
  -regtest \
  generatetoaddress 1 <DEVNET_MINER_ADDRESS>

6. Submit another valid contract-call transaction.

7. Compare Bitcoin and Stacks heights:

bitcoin-cli \
  -rpcuser=devnet \
  -rpcpassword=devnet \
  -regtest \
  getblockcount

curl http://localhost:20443/v2/info

8. Query the submitted transaction:

curl http://localhost:20443/v2/transactions/unconfirmed/<TXID>

Actual result

Bitcoin continues advancing, while the Stacks node remains at:

{
  "burn_block_height": 179,
  "stacks_tip_height": 80,
  "tenure_height": 70,
  "is_fully_synced": true
}

At the same time, Bitcoin reached height 199.

Valid transactions remain in the Stacks mempool and sender nonces do not advance.

Example pending transaction:

ba8797b95977a4269f0b704b79dfab5ea6792939a3044705e309af8a7f3fa604

The behavior reproduced after deleting the devnet chainstate and starting again.

Expected result

The Stacks node and signer should continue processing new Bitcoin blocks across the PoX boundary, and valid mempool transactions should eventually anchor.

Additional context

Clarinet initially generated Docker networking settings using host.docker.internal. On this Linux environment, the following changes were required:

[[events_observer]]
endpoint = "clarinet-observer-proxy:20445"
events_keys = ["*"]

[burnchain]
peer_host = "bitcoin-node.<project>.devnet"
rpc_port = 18443
peer_port = 18444

The PoX stall still reproduced after applying those networking corrections.

Manual block generation may be a contributing factor. It would be useful to confirm whether the signer fails because burn blocks are generated faster than it can process them, or whether the same stall occurs at Clarinet’s normal mining cadence.

Contracts available for testing:

github.com/fabohax/cholo-token/contract