Per-fleet cost settings (SF-130)

Each customer fleet chooses the cadences that drive its network cost. The settings live on chain, bounded by the contract, and devices apply them within one check. The defaults are those of the 2026-10-23 business-plan proposal: the base price includes them, and faster options are priced add-ons. The settings page that shows the cost and collects the prepaid deposit is SF-131 (#266).

Settings, defaults and bounds

The values are shared through interfaces/fleet-v1.json (fleet_settings): the generated FLEET_SETTINGS (TypeScript) and fleet_settings_values (Rust) constants, and a generated Move test that checks the contract's defaults and accepts every bound.

The bounds keep one device within Mysten's documented public full node guidance of 100 requests per 30 seconds: routine checks at most every 5 minutes and fast checks at most every 30 seconds. Health and archive bounds equal those fleet_data already enforces.

Contract: sui_edge::fleet_settings

Introduced by a compatible upgrade of the core package. One Settings value per fleet is stored in a dynamic field (key SettingsKey) of the fleet's FleetBudget (FLEET_BUDGET.md), so:

• devices find it from the budget ID they already use, with one object read;
• a fleet has one record, never two that disagree;
• budgets created before the upgrade gain a record without migration.

Every write emits FleetSettingsChanged { budget_id, changed_by, at_ms, previous, settings }; previous is none on the first write. set checks the budget's package version through fleet_budget::assert_owner, and refuses to overwrite a record written by a newer package version (ENewerVersion), so an older package version cannot undo a later migration. There is no device-side write.

Daemon

The daemon follows the settings of the budget named by [budget].budget_id, or else [fleet_data].budget_id; configuration validation requires both to name the same budget when both are set. A deployment manifest without the fleet_settings type origins, or a fleet without a record, leaves the local configuration in force.

• Checks. After every check the daemon reads the record and applies it to the check cadence as floors: the routine interval becomes max(runtime.poll_seconds, check_interval_ms) and the fast interval (used while a deployment waits for rollout eligibility or admission, or a maintenance window is open) becomes max(runtime.rollout_poll_seconds, rollout_check_interval_ms). With fast checks off (0) the fast interval is the routine interval. The cadence's single wakeups at a known admission time or window start, and its failure backoff, are unchanged. Intervals that are not whole seconds round up.
• Health and archives. The fleet_data loop reads the record each round and reports health or archives logs at the slower of the fleet_data cadence (the contract-enforced minimum) and the fleet's setting. With a record, that loop also runs at the fleet's check interval instead of every minute, so diagnostics requests and archive cleanup follow within one check.
• Retention is applied by the owner's storage purchases (pool epochs and renewal targets), not by devices; the daemon reads but does not use it.

Local configuration can only make a device slower and cheaper, never faster than the fleet allows. A change applies at the next check after it is written: within one interval. A record the daemon cannot use (unreadable, outside the bounds, or a newer version) keeps the settings already in force and is logged once. Older daemons ignore the record and keep their local configuration.

dApp

dapp/src/lib/fleet-settings.ts provides DEFAULT_SETTINGS, SETTINGS_BOUNDS, settingsErrors (the contract's rules, checked before signing), buildSetFleetSettingsTx and fetchFleetSettings (one dynamic-field read). The /settings page (SF-131) prices each setting, sizes the prepaid deposit from them and saves them with buildSetFleetSettingsTx; see FLEET_BUDGET.md.

Verification

Public-testnet upgrade acceptance runs in the normal automatic testnet CI. Physical-device and Mainnet acceptance remain in #32 and #159.

Source: Edit this page