feed supra_rule for BUCK and USDSUI (deploy before the rollout tx)

[JustaLiang]

Adds BUCK and USDSUI to MAINNET_SUPRA_COIN_TYPES, so aggregatePrices starts appending supra_rule::feed<T> for them alongside Pyth.

⚠️ Deploy this BEFORE the rollout transaction, not after

Their pair ids and their aggregator weights now ride in a single PTB (pnpm rollout:apply in v2-move-contracts/scripts/rollout), so this release has to be live first.

1. merge → release → deploy this
2. send the rollout payload — 20 calls, one signature

Between (1) and (2) there is a window where PTBs pricing BUCK or USDSUI revert EUnsupportedCoinType, because supra_rule::feed<T> aborts while a coin type has no pair id in supra_rule::Config and neither has one yet. That window is deliberate — both assets are PSM-only and thinly used, so it is cheaper than a second multisig ceremony. Keep it short.

Doing it the other way round inverts the failure: the aggregator would weight a rule nothing feeds, and aggregate aborts EMissingPriceSource until this deploys.

Why not the no-downtime order

The two constraints are a cycle — this list may not run ahead of the pair ids, and the weights may not run ahead of this list. The alternative (pair ids → this PR → weights) has no downtime but needs two signing ceremonies, since the release sits between two transactions. We chose the window.

Why USDC_USD for both

Supra lists neither directly. BUCK appears only as the quote asset (SUI_BUCK 160 deprecated, USDC_BUCK 161 under supervision) and supra_rule maps one coin type to one pair without inverting; USDSUI has no listing at all. USDC_USD (89) is the peg proxy.

The tradeoff, accepted deliberately

This is a new substitution, not an inherited one — the distinction from XBTC and UP_USD above them in the list. Those stand in for a market pyth_rule already prices them off on-chain, so both sources track the same thing. BUCK and USDSUI have their own Pyth feeds (fdf28a46…, d510fcdb…), so pointing Supra at USDC puts a real-asset feed and a peg proxy on one aggregator:

• during a depeg Pyth tracks the asset down while Supra stays at ~1.00;
• below 2× the outlier band the aggregate over-values the asset by half the depeg;
• past it both sources are dropped and aggregate aborts ERiskyPrice.

Accepted because both are PSM-only and thinly used. Spreads measured 0.15% (BUCK) and 0.08% (USDSUI) at authoring time — nothing shows on a calm day, which is the reason it is written down.

Verification

• pnpm lint clean
• pnpm test:unit — 128 passed
• pnpm build clean

🤖 Generated with Claude Code

[waterlabs-bot]

Code review

Found 1 blocking issue:

1. High severity · High confidence — this head enables BUCK and USDSUI before their required Supra pair IDs exist on mainnet. The two new allowlist entries make aggregatePrices append supra_rule::feed<T> for those assets, but current single-coin simulations for both abort with supra_rule::err_unsupported_coin_type. The PR's full oracle E2E fails for the same reason, while the parent commit passes that file 6/6. Apply and verify the pair-ID rollout first, then rerun E2E to green before merging/releasing this SDK head; releasing it now breaks every SDK flow that prices BUCK or USDSUI.

bucket-protocol-sdk/src/consts/supra.ts

Lines 61 to 72 in 41c2acd

	// Also peg proxies, but a *new* substitution rather than an inherited one. XBTC
	// and UP_USD above stand in for a market `pyth_rule` already prices them off
	// on-chain, so both sources track the same thing. BUCK and USDSUI have their
	// own Pyth feeds (`fdf28a46…` and `d510fcdb…`), so pointing Supra at USDC puts a
	// real-asset feed and a peg proxy on one aggregator: a depeg moves Pyth and not
	// Supra. Below 2x the outlier band the aggregate over-values them by half the
	// depeg; past it both sources are dropped and `aggregate` aborts ERiskyPrice.
	// Accepted deliberately — both are PSM-only and thinly used. See
	// v2-move-contracts/scripts/rollout/README.md.
	'0xce7ff77a83ea0cb6fd39bd8748e2ec89a3f41e8efdc3f4eb123e0ca37b184db2::buck::BUCK', // USDC_USD
	'0x44f838219cf67b058f3b37907b655f226153c18e33dfcd0da559a844fea9b1c1::usdsui::USDSUI', // USDC_USD
	];

Evidence

• Full diff reviewed at 41c2acd727f02694dac547f1bd355235653cb4cf (1 file, +15 / -1).
• CI: lint and check-secrets pass; e2e-test fails (1 failed / 189 passed / 2 skipped).
• Local: build passed; unit tests 128/128 passed.
• Integration: BUCK and USDSUI each reproduce err_unsupported_coin_type on current mainnet; the parent commit's oracle E2E passes 6/6.

🤖 Generated with Hermes Agent

Dismissed because the PR was force-pushed during submission; this review analyzed 41c2acd, not the replacement head 1b9cc88.

[waterlabs-bot]

Code review

Found 1 blocking deployment-synchronization issue:

1. High severity · High confidence — the rollout this change depends on is not present in the reviewed deployment source. This head deliberately deploys an SDK state where BUCK/USDSUI pricing aborts until a combined pair-ID-and-weight transaction runs, and points operators to v2-move-contracts/scripts/rollout. But the current remote v2-move-contracts source has no committed scripts/rollout, no SDK_FED_SUPRA_COIN_TYPES, and its only reviewed Supra configuration still marks both BUCK and USDSUI unsupported. That leaves the transaction required to end the intentional production outage unavailable for review or reproducible execution. Commit and review the companion rollout configuration (both exact coin types → pair 89 plus the intended weights), link it here, and verify its read-only plan output before merging/releasing this SDK change.

bucket-protocol-sdk/src/consts/supra.ts

Lines 22 to 38 in 1b9cc88

	* is simply never fed, and a rule that is fed but carries no aggregator weight is
	* dropped by `remove_outliers` without affecting the result.
	*
	* ## Ordering
	*
	* The two constraints form a cycle — this list may not run ahead of the pair
	* ids, and the aggregator weights may not run ahead of this list (`aggregate`
	* aborts `EMissingPriceSource`). One side has to give:
	*
	* A. pair ids → this list → weights. No downtime, but two signing ceremonies,
	* because a release sits between two transactions.
	* B. this list → one transaction carrying pair ids *and* weights. One
	* ceremony, at the cost of a window between this going live and that
	* transaction landing, during which PTBs pricing the new coin type revert
	* `EUnsupportedCoinType`.
	*
	* **BUCK and USDSUI were added under B**, deliberately: both are PSM-only and

Current reviewed deployment config still excludes both assets:

• https://github.com/Bucket-Protocol/v2-move-contracts/blob/0029e03b8eeca29f6e7b3ffb845f8927ec44000e/scripts/supra_rule/config.ts#L219-L224
• https://github.com/Bucket-Protocol/v2-move-contracts/blob/0029e03b8eeca29f6e7b3ffb845f8927ec44000e/scripts/supra_rule/config.ts#L232-L236

Evidence

• Full current diff reviewed at 1b9cc882b7cfa0f6b7f874675a9e30bd6689c940 (1 file, +29 / -4).
• CI: lint and check-secrets pass; e2e-test fails in the documented pre-rollout state.
• Local: build passed; unit tests 128/128 passed on the semantic-equivalent prior head.
• Integration: BUCK and USDSUI each reproduce err_unsupported_coin_type; the base oracle E2E passes 6/6.

🤖 Generated with Hermes Agent

Superseded by the cross-repository re-review: PR #61 now supplies the previously missing rollout artifact, but its current head has separate execution-safety blockers.

[waterlabs-bot]

Cross-repository rollout review

The companion rollout source now exists in Bucket-Protocol/v2-move-contracts#61, and the BUCK/USDSUI EUnsupportedCoinType window is explicitly accepted. No additional SDK logic defect was found at this head.

Release remains blocked on the companion rollout, however: #61 can currently emit the full weight-bearing payload before the required SDK deployment is confirmed, accepts an empty --only= as "select everything," and carries an incomplete inventory of price-PTB consumers that must be upgraded before weights land. Because releasing this PR starts the accepted downtime window, the executable recovery/cutover path must be approved and ready first.

Acceptance: resolve and approve #61, publish this SDK change, deploy the exact release to every active price-PTB consumer, then generate/sign/execute #61's payload. The historical E2E failure is expected before the pair-ID transaction; rerun it after the transaction lands.

Companion review: https://github.com/Bucket-Protocol/v2-move-contracts/pull/61

Reviewed SDK head: 1b9cc882b7cfa0f6b7f874675a9e30bd6689c940.

🤖 Generated with Hermes Agent

[JustaLiang]

The three companion-rollout issues this release was blocked on are fixed in Bucket-Protocol/v2-move-contracts#61 at 819996f:

• #61 could emit the weight-bearing payload before the SDK deployment was confirmed — now a gate, not a banner. rollout:apply refuses unless --sdk-deployed= names the release; rollout:plan stays read-only and ungated.
• empty --only= selecting everything — absent and present-but-empty now differ, and unknown symbols are rejected before any live check. 10 regressions added.
• incomplete consumer inventory — rebuilt from all 130 org repos (the first pass was assembled from local clones and also truncated at the 100-repo API page limit). It missed bucket-cli, dashboard and water-finance-frontend-poc and was stale on three pins. It is now labelled a checklist rather than an authorization; the --sdk-deployed= flag is the gate.

No change needed on this PR — the acceptance path you set out is unchanged and now executable:

1. approve and merge fix: cjs #61
2. publish this (patch → 2.2.2)
3. deploy that exact release to every active price-PTB consumer
4. pnpm rollout:apply -- --sdk-deployed=2.2.2 --out=payload.b64, sign, execute

The acknowledgement string in #61's SDK_RELEASE_REQUIRED is pinned to 2.2.2 on the assumption that step 2 is a patch bump from 2.2.1. If the release lands on a different version, that constant needs updating first — apply will refuse rather than accept a mismatched value.

Agreed on the E2E: the oracle failure is expected before the pair-id transaction, and should be rerun after it lands.

Removed at requester direction. Companion PR #61 code blockers are resolved at 1fa46acf3b12169348d22c286a2a205ad7e25981; SDK/consumer deployment receipts remain an operational prerequisite before executing the rollout transaction.

[waterlabs-bot]

Approval after rollout re-review

Approved at 1b9cc882b7cfa0f6b7f874675a9e30bd6689c940. The SDK diff has no remaining code blocker, companion rollout PR #61 has cleared its code findings at 1fa46acf3b12169348d22c286a2a205ad7e25981, and the requester explicitly accepts the bounded BUCK/USDSUI pre-transaction downtime.

Operational order remains: publish the SDK release, deploy it to every active price-PTB consumer, then generate/sign/execute the guarded rollout payload and rerun E2E.

🤖 Generated with Hermes Agent