Allow miners to post direction specific rates#7
Merged
Conversation
A miner could claim a third-party tx to the user's dest address as their own fulfillment. Store miner_dest_address on the swap struct at initiation and validate tx_info.sender against it during dest-side verification.
Miners can now post separate rates for each swap direction (e.g., 340 TAO/BTC for BTC->TAO, 350 TAO/BTC for TAO->BTC) to capture tx fee asymmetry. Commitment format bumped to v3 with two rate fields. Backend unchanged — each swap still stores one rate, selected by direction at initiation time.
Replace TAO-centric assumptions with canonical chain ordering so any pair (including non-TAO pairs like BTC-ETH) works correctly. TAO is preferred as the rate denomination when present, otherwise alphabetical ordering is used as a deterministic fallback. - Add canonical_pair() to chains.py with TAO-preference ordering - Rename rate_reverse → counter_rate across all files - Change get_rate_for_direction(source_is_tao) to accept chain name - Rename rate.py params: source_is_tao → is_reverse, tao_decimals/asset_decimals → dest_decimals/source_decimals - Filter miners with rate=0 for the desired direction (CLI + validator) - Fix test_scale.py swap encoding (missing miner_source_address, miner_dest_address, rate) - Fix float comparison for rate display → use string comparison - Add 5 unit tests: canonical_pair, direction after normalization, direction-specific rate calc
- Allow counter_rate=0 (miner only supports one direction) - Auto-select destination chain when only one option remains - Add context to chain prompts (you receive/send on this chain) - Display "not supported" for disabled directions in status/summary - Add 2 unit tests for single-direction parsing and normalization
- Use "send X, get Y" format for rate confirmation and swap summary - Split miners table into explicit BTC→TAO / TAO→BTC columns - Show "—" for disabled directions (rate=0) in tables - Use "not supported" label for disabled directions in status
Verify that chains sorting after "tao" alphabetically (e.g. "thor") still get TAO as dest, not alphabetical ordering.
Verifies the full defense-in-depth: get_rate_for_direction returns 0 for disabled direction, validator guard catches it, and calculate_dest_amount produces 0 as a fallback (contract rejects InvalidAmount).
- Swap rates during normalization when positional args used in non-canonical order (e.g. alw miner post tao ... btc ... 340 360) - Fix display showing "get 0" in green when forward rate is disabled - Consistent — in view_rates for rate=0 (matches view_miners)
anderdc
approved these changes
Apr 7, 2026
anderdc
added a commit
that referenced
this pull request
Jun 22, 2026
…vation, admin cancels, shared validation - consolidate tunables.rs into constants.rs (economic-levers section) - open_or_request: gate on 1.10x required_collateral at pool entry so an under-collateralized miner can't strand a user at vote_initiate (#1) - vote_deactivate: forbid deactivating a busy miner (busy => active invariant), so resolve_pool never arms a reservation on an inactive miner (#3) - restore admin cancel_pool / cancel_reservation, clearing busy_until (#4) - admin setters reject contradictory min/max bounds (#6) - set_quote charges the churn fee on creation too, closing the remove_quote + set_quote dodge (#7) - validate.rs: shared Config-field validators used by initialize + setters so the two write paths can't diverge (#8) - DEFAULT_FULFILLMENT_TIMEOUT_SECS = 14400 (4h) canonical deploy default - tests: 12 new (entry gate, busy deactivation, cancels, bounds, quote fee); LiteSVM 67/67, e2e.sh 24/24
LandynDev
pushed a commit
that referenced
this pull request
Jun 22, 2026
* fix(solana): PR review — entry over-collateral gate, busy-lock deactivation, admin cancels, shared validation - consolidate tunables.rs into constants.rs (economic-levers section) - open_or_request: gate on 1.10x required_collateral at pool entry so an under-collateralized miner can't strand a user at vote_initiate (#1) - vote_deactivate: forbid deactivating a busy miner (busy => active invariant), so resolve_pool never arms a reservation on an inactive miner (#3) - restore admin cancel_pool / cancel_reservation, clearing busy_until (#4) - admin setters reject contradictory min/max bounds (#6) - set_quote charges the churn fee on creation too, closing the remove_quote + set_quote dodge (#7) - validate.rs: shared Config-field validators used by initialize + setters so the two write paths can't diverge (#8) - DEFAULT_FULFILLMENT_TIMEOUT_SECS = 14400 (4h) canonical deploy default - tests: 12 new (entry gate, busy deactivation, cancels, bounds, quote fee); LiteSVM 67/67, e2e.sh 24/24 * refactor(solana): separate subnet-revenue Treasury PDA from the collateral Vault Collateral and subnet revenue no longer share an account. The Vault holds ONLY miner collateral (trustless — leaves only via the owning miner's withdraw or a slash to the wronged user); a new Treasury PDA holds ONLY subnet income. - new Treasury { total, bump } PDA (seeds [b"treasury"]); Vault loses treasury_total - confirm 1% fee, reservation fee, and quote churn fee all accrue to the Treasury - timeout slash still pays the user from the Vault (never the treasury) - withdraw_treasury drains the Treasury PDA (admin-only, caller-chosen recipient) - split invariants: vault.lamports == rent + total_collateral; treasury.lamports == rent + total Anti-flash fee follows the #488 mechanism (creation free; charge on remove_quote): - set_quote creation is free again; updates still pay the decaying churn fee - remove_quote charges the same decaying fee -> Treasury, closing the remove+recreate dodge without taxing first-time quotes Tests updated for the split + new fee semantics. LiteSVM 67/67, e2e.sh 24/24. * fix(solana): address pre-PR code-review findings - cancel_reservation: require an active reservation (reserved_until != 0) so it can't clear busy_until on a miner whose pool is still open — that could let the miner be deactivated mid-contest and resolve_pool match a removed miner against a user (fund-safety regression caught in review) - resolve_pool: restore the inactive-miner backstop (reset pool, never arm a reservation or busy lock for an inactive miner) - vote_initiate: defensive active-miner check before initiating - remove_quote: document the deliberate "removal can cost the churn fee" stance - fix stale vault->treasury doc comments (confirm_swap, set_quote, lib, constants) - tests: cancel_reservation open-pool rejection + treasury lamport conservation LiteSVM 68/68, e2e.sh 24/24. * refactor(solana): drop cancel_pool/cancel_reservation; rely on TTL self-expiry No permanent stuck state exists: resolve_pool is permissionless (always progresses an open pool) and a reservation's reserved_until is always now + reservation_ttl, so a miner abandoned in a reservation self-frees at the TTL. The admin cancel ops were only early-clear accelerators and were the sole paths that cleared busy_until manually — the exact footgun behind the fund-safety bug. Removing them restores a clean busy => active invariant without a resolve_pool backstop. - remove cancel_pool / cancel_reservation instructions, their events + tests - resolve_pool: no active check (documented invariant); vote_initiate keeps its defensive active check as the funds-commit backstop LiteSVM 65/65, e2e.sh 24/24.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Miners post a single bilateral rate that applies to both swap directions. But tx fees are asymmetric across chains — sending BTC costs more than receiving it. A single rate forces miners to average out that cost, meaning users get a worse rate on the cheap direction.
This adds direction-specific rates so miners can price each direction honestly (e.g., 340 TAO/BTC for BTC->TAO, 350 TAO/BTC for TAO->BTC). The spread captures the tx fee differential.
Approach
Commitment format bumped to v3 with two rate fields. The correct rate is selected based on swap direction at initiation time. The entire backend (validator verification, miner fulfillment, smart contract, voting) is unchanged — each swap on-chain still stores one rate, it's just the right one for that direction now.
Test plan
Reviewer experience
Start the dev environment and explore these flows:
Post a pair with directional rates (as miner):