5. Implementation plan

All seven target connectors already exist in the Hummingbot codebase (hyperliquid, hyperliquid_perpetual, dydx_v4_perpetual, grvt_perpetual, pacifica_perpetual, lighter_perpetual, decibel_perpetual). Each connector's work is additive: add a small set of builder constants, route order payloads through an inject_builder_fields() method, and expose a /builder-info handler. No connector requires structural changes.

After §5.1 (spec ratification and Foundation onboarding) lands, all connector tracks proceed in parallel. The Foundation assigns each track to an existing connector maintainer where one is active, or creates a bounty for community implementation where no maintainer exists. Tracks do not depend on each other — each lands independently when its implementation and review complete. The Hummingbot API endpoint (§5.3) and Condor integration (§5.4) also proceed in parallel with the connector tracks, with Condor adopting each venue as its connector ships.

5.1 Prerequisite: Spec ratification and Foundation onboarding

• This proposal ratified by the Hummingbot Foundation.
• Foundation registers its builder identity on each target venue where the Foundation default applies. One-time operational work:
  • Hyperliquid: deposit ≥100 USDC into a Foundation-controlled wallet; record the EVM address.
  • dYdX v4: any chain address works. Foundation creates a dydx1… address and records it.
  • GRVT: Foundation registers a builder account through GRVT's onboarding; records the builderAccountID.
  • Pacifica: Foundation contacts Pacifica ops to register a builder_code string (≤16 chars). Suggested value: hummingbot.
  • Lighter: no Foundation registration. The Foundation default on Lighter is "no builder configured" because Lighter requires an L1 signature from users even at 0 bps.
  • Decibel: no Foundation registration. The Foundation default on Decibel is "no builder configured" because Decibel requires approveMaxBuilderFee from users before any builder field can be attached.
• Foundation builder keys held in multisig or hardware custody.
• Application integration guide published, covering: how to register your own builder identity per venue, how to override Foundation defaults in a Hummingbot API deployment, and the dual-wallet UX pattern from §4.5 (especially the Hyperliquid main-wallet constraint).

5.2 Connector implementation (parallel tracks)

All connector tracks below proceed in parallel after §5.1. The Foundation assigns each track to an existing connector maintainer where one is active, or creates a bounty for community implementation where no maintainer exists. Hyperliquid is designated as the reference implementation because Hummingbot already has an active Hyperliquid maintainer team and Condor's first integration targets Hyperliquid; later tracks can refer to the Hyperliquid implementation for patterns. No track is blocked on any other.

5.2.1 Hyperliquid (reference implementation)

This track covers both hyperliquid (spot) and hyperliquid_perpetual (perp) connectors. The implementation: attach a Foundation builder address with a zero fee rate to every mainnet order, omit on testnet and vault, no approval action invoked from the connector.

Approval rationale (why 0 bps works without approval)

The Hyperliquid order builder field carries {"b": "<address>", "f": <tenths_of_bps>}. The exchange enforces f ≤ user_approved_max(user, builder) on every order; the user's approved maximum for a given builder is queryable via the info endpoint ({"type": "maxBuilderFee", "user": "0x<user>", "builder": "0x<builder>"}). For unapproved (user, builder) pairs, the response is 0. At f = 0, the constraint 0 ≤ 0 is trivially satisfied, so the order is accepted without requiring a prior ApproveBuilderFee action.

Two cases where the venue still rejects 0-fee builder fields and require omitting the field entirely:

• Vault trading. Hyperliquid does not allow vaults to sign ApproveBuilderFee, and the venue's check on vault orders fails on the wallet-identity mismatch rather than the fee value.
• Testnet. Testnet wallets typically lack approval state altogether, and testnet's check is stricter than mainnet's — it rejects builder fields regardless of fee value, so the connector omits builder fields on testnet.

Constants

hyperliquid_perpetual_constants.py (identical pattern in hyperliquid_constants.py for spot, with the spot cap):

BUILDER_SUPPORTED = True

# Foundation builder identity. Set after §5.1 onboarding.
# The address of the Foundation-controlled wallet that has deposited
# ≥100 USDC on Hyperliquid (required to register as a builder).
FOUNDATION_BUILDER_ADDRESS = "0x..."

# Foundation default fee. 0 means attribution only.
# Unit: tenths of a basis point (Hyperliquid's `f` unit).
FOUNDATION_BUILDER_FEE_TENTHS_BPS = 0

# Protocol caps for override validation.
# Unit: tenths of a basis point. Reference: Hyperliquid builder-codes docs.
HYPERLIQUID_PERP_BUILDER_FEE_CAP_TENTHS_BPS = 100    # = 10 bps (perp cap)
HYPERLIQUID_SPOT_BUILDER_FEE_CAP_TENTHS_BPS = 1000   # = 100 bps (spot cap)