• Author: Michael Feng (mike@hummingbot.org)
• Companion to: HGP-87 (Builder Code Support for Perp DEX Connectors)
• Status: Internal research notes — not part of the formal HBP submission
• Scope: How four existing open-source trading platforms handle Hyperliquid's main-wallet builder approval constraint, and what Hummingbot can learn from each.

Why this document exists

The formal HGP proposal documents what Hummingbot will ship and why. This document records the research that informed those choices — specifically, how NautilusTrader, CCXT, Tealstreet, and Insilico Terminal handle Hyperliquid's ApproveBuilderFee constraint. The constraint forces every Hummingbot-adjacent platform to make a choice about how to handle main-wallet signing in a tool whose normal credentials are agent-wallet-only, and these four implementations bracket the design space from "no UX needed" to "forced browser-wallet onboarding."

Keeping this analysis out of the public HBP keeps the proposal focused on what Hummingbot ships rather than the competitive landscape. The patterns referenced in the HBP (Nautilus 0-bps model, Insilico forced browser-wallet onboarding) are documented here with full context.

1. NautilusTrader: skip the question

Nautilus hardcodes its builder address with feeRate = 0. Because no fee is charged, no approval action is needed on mainnet (Hyperliquid only enforces approval when requested_fee > 0). The adapter accepts either a main wallet key or an agent wallet key plus a HYPERLIQUID_ACCOUNT_ADDRESS env var, and signs orders with whatever is provided. No approval UX exists in the library at all.

Flow: user sets HYPERLIQUID_PK (and HYPERLIQUID_ACCOUNT_ADDRESS if it's an agent key). Done.

Trade-off: zero friction, but no monetization possible without changing the model.

How they got there. Nautilus did not start at 0 bps. Earlier releases charged a non-zero builder fee and carried machinery to refresh approval state periodically (a builder_fee_refresh_mins config option). Two production bugs forced a reconsideration:

• Issue #3762 (vault orders): when vault_address was configured, every order was rejected with "Builder fee has not been approved" because Hyperliquid does not allow vaults to sign ApproveBuilderFee. Fix: omit builder fields for vault orders.
• Issue #3989 (testnet): testnet orders were rejected with the same error because testnet wallets typically lack the approval state. Fix: omit builder fields on testnet to match vault behavior.

After absorbing both fixes, Nautilus removed the builder fee entirely in release 1.224.0 (Feb 2026). The release notes are blunt: "Removed Hyperliquid builder fee charges (builder-fee approval no longer required). Removed Hyperliquid builder_fee_refresh_mins config option (builder fees no longer charged)."

Learnings carried into HBP-XXX:

1. Vault and testnet require omitting builder fields, not zeroing them. A 0-fee builder is still a builder, and Hyperliquid's approval check fires on the wrong wallet identity (vault, or testnet wallet without approval). Codified as connector-level omit invariants.
2. Going to 0 bps eliminated both bugs AND the complexity of approval-refresh logic. The builder_fee_refresh_mins config option existed only because approval state could go stale at any non-zero fee. At 0 bps, there is no approval state to track and no refresh logic to maintain. Hummingbot ships the Foundation default at 0 bps on every venue where the venue allows it.