Skip to content

fix(stacking): add pox-5 support for Epoch 4.0 hard fork#412

Open
arc0btc wants to merge 1 commit into
aibtcdev:mainfrom
arc0btc:feat/pox-5-support
Open

fix(stacking): add pox-5 support for Epoch 4.0 hard fork#412
arc0btc wants to merge 1 commit into
aibtcdev:mainfrom
arc0btc:feat/pox-5-support

Conversation

@arc0btc

@arc0btc arc0btc commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Summary

  • stacks-core 4.0.1 activates the Epoch 4.0 hard fork: pox-5 replaces pox-4, Clarity 6 added. StackingService hardcoded POX_4 for stack-stx, stack-extend, stack-increase, delegate-stx, revoke-delegate-stx, and get-stacker-info — these will fail/no-op against an inactive contract post-activation.
  • Added a POX_5 contract constant (src/lib/config/contracts.ts, mainnet + testnet, same boot-contract address as pox-4 following the pox-2/3/4 pattern).
  • StackingService now resolves the active PoX contract dynamically at call time via the node's /v2/pox contract_id field, falling back to the static POX_5 constant if that lookup fails — avoids hardcoding either version and future-proofs against the next PoX bump.

Investigation: stackspot.app pot contracts (read-only, no code change)

Checked the deployed Genesis pot contract (SPT4SQP5RC1BFAJEQKBHZMXQ8NQ7G118F335BD85.Genesis, used by skills/stacks-stackspot) via Hiro's contract-source endpoint:

(define-constant pox-data (contract-call? 'SP000000000000000000002Q6VF78.pox-4 get-pox-info))
(as-contract (contract-call? 'SP000000000000000000002Q6VF78.pox-4 allow-contract-caller 'SPMPMA1V6P430M8C91QS1G9XJ95S59JS1TZFZ4Q4.pox4-multi-pool-v1 none))

This pot contract hardcodes pox-4 and calls allow-contract-caller, a function pox-5 removes entirely. Since it's already-deployed, immutable Clarity code, this can't be patched — stackspot.app would need to deploy a new pot contract against pox-5. This repo's code can't fix that; filing a follow-up to watch for stackspot.app's migration and pause stackspot auto-join if it doesn't land before activation.

Test plan

  • bun run typecheck passes clean
  • CI (existing test suite)
  • Manual verification against a pox-5 testnet/mainnet activation once live (contract addresses in this PR are unverified — no deployed pox-5 exists yet per current release notes)

Note: not urgent — hard-fork activation height has not been reached yet per stacks-core 4.0.1 release notes, but this should land before activation to avoid silent stacking failures.

stacks-core 4.0.1 activates pox-5 in place of pox-4. StackingService
hardcoded pox-4 for stack-stx/stack-extend/stack-increase/delegate-stx/
revoke-delegate-stx/get-stacker-info, which will fail post-activation.

Add a POX_5 contract constant (same boot-contract address as pox-4,
following the pox-2/3/4 pattern) and resolve the active PoX contract
dynamically at call time via the node's /v2/pox contract_id, falling
back to the static POX_5 address if that lookup fails. This avoids
another hardcoded-version cliff on the next PoX bump.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant