Skip to content

Separate core and Bitcoin concerns, move BTC state to dynamic field#338

Open
Bridgerz wants to merge 3 commits intohashi-refactor-phase1from
hashi-refactor-phase2
Open

Separate core and Bitcoin concerns, move BTC state to dynamic field#338
Bridgerz wants to merge 3 commits intohashi-refactor-phase1from
hashi-refactor-phase2

Conversation

@Bridgerz
Copy link
Contributor

@Bridgerz Bridgerz commented Mar 23, 2026

Summary

Builds on #337. Restructures the Hashi package to separate core MPC/auth infrastructure from Bitcoin-specific logic, then moves BTC state out of the Hashi struct into a dynamic field.

Config split

  • Monolithic config.move split into generic config (version gating, pause, upgrade cap) and btc_config (deposit fees, withdrawal params, dust limits)
  • BTC defaults injected at init rather than hardcoded in core

Directory reorganization

  • Move sources split into core/ (committee, config, treasury, proposals, reconfig, validator, tob, threshold) and btc/ (deposit, withdraw, utxo, btc_config, queues)

BitcoinState dynamic field

  • New bitcoin_state module with BitcoinState / BitcoinStateKey structs holding deposit_queue, withdrawal_queue, utxo_pool
  • Hashi struct slimmed to chain-agnostic fields; BitcoinState attached via df::add in init
  • borrow_bitcoin_state() / borrow_bitcoin_state_mut() accessors on Hashi
  • All BTC entry functions access state through the dynamic field
  • commit_withdrawal_tx sequences borrows: bridge ops, then treasury burn + config read, then re-borrow for insert
Hashi (shared object)
├── committee_set   ← MPC committee management
├── config          ← version gating, pause, upgrade cap
├── treasury        ← generic coin mint/burn (shared across chains)
├── proposals       ← governance
├── tob             ← threshold-of-broadcast certificates
└── [dynamic field: BitcoinStateKey]
    └── BitcoinState ← deposit_queue, withdrawal_queue, utxo_pool

Rust: move_types::Hashi slimmed to match; scrape_hashi fetches BitcoinState via list_dynamic_fields on the Hashi object.

Test plan

  • sui move build — clean
  • sui move test — 63 tests pass
  • cargo check — compiles
  • cargo test -p hashi --lib — 154 tests pass
  • cargo clippy / cargo fmt --check — clean
  • Move formatting (prettier) — clean

@Bridgerz Bridgerz requested a review from bmwill as a code owner March 23, 2026 23:29
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch from 3f7739b to e72d8f2 Compare March 23, 2026 23:36
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase1 branch from b0855be to 24d7817 Compare March 23, 2026 23:41
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch from e72d8f2 to 9f2a54e Compare March 23, 2026 23:41
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase1 branch 2 times, most recently from 3edb7ce to 7d8b5bd Compare March 23, 2026 23:45
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch from 9f2a54e to 8a53192 Compare March 23, 2026 23:45
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase1 branch from 7d8b5bd to 23362fa Compare March 23, 2026 23:47
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch 2 times, most recently from b88c5e9 to 339f678 Compare March 23, 2026 23:54
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase1 branch from 23362fa to ad5e451 Compare March 24, 2026 00:09
Decouple BTC-specific fee parameters and calculation functions from
the core Config module to prepare for multi-chain support.

- Create btc_config.move with all BTC-specific constants (dust threshold,
  fee rates, vbyte calculations), config accessors (deposit_fee,
  withdrawal_fee_btc, max_fee_rate, etc.), and calculation functions
  (worst_case_network_fee, withdrawal_minimum, deposit_minimum)
- Slim config.move to core concerns: paused state, version management,
  upgrade management, and generic get/upsert (now public(package))
- Config still holds BTC key names in is_valid_config_entry for
  UpdateConfig proposal validation (pragmatic: avoids circular deps)
- BTC defaults initialized via btc_config::init_defaults, called
  separately from config::create
- Update all consumers to use btc_config:: qualified calls
Pure file moves — no logic changes. Makes the auth/bridge separation
visible in the file system.

core/ — protocol-agnostic authentication, signing, and governance:
  committee/, config, config_value, threshold, tob, cert_submission,
  validator, reconfig, treasury, proposal/

btc/ — Bitcoin bridge logic:
  btc, btc_config, utxo, utxo_pool, deposit, deposit_queue,
  withdraw, withdrawal_queue

hashi.move remains at the root as the shared object aggregating both.
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch from 339f678 to 9f2bdbf Compare March 24, 2026 00:09
Extract deposit_queue, withdrawal_queue, and utxo_pool from the Hashi
struct into a BitcoinState struct stored as a dynamic field. This
decouples chain-specific state from the core Hashi object, allowing
future chains to be added without modifying the shared object layout.

Move side: new bitcoin_state module with BitcoinState/BitcoinStateKey,
Hashi accessors borrow_bitcoin_state/borrow_bitcoin_state_mut, updated
all BTC entry functions and tests.

Rust side: slimmed move_types::Hashi deserialization, scrape_hashi now
fetches BitcoinState via dynamic field derivation.
@Bridgerz Bridgerz force-pushed the hashi-refactor-phase2 branch from 9f2bdbf to 5cb3fb3 Compare March 24, 2026 00:17
@Bridgerz Bridgerz changed the title Move Bitcoin state to dynamic field on Hashi Separate core and Bitcoin concerns, move BTC state to dynamic field Mar 24, 2026
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