fix(hyperliquid): omit the builder field when the fee resolves to 0 - #8449
Open
AzothZephyr wants to merge 1 commit into
Open
AzothZephyr wants to merge 1 commit into
AzothZephyr wants to merge 1 commit into
Conversation
Every order fails for a user who has not approved the Foundation builder:
Error submitting order ...: Builder fee has not been approved.
_initialize_builder_fee correctly resolves the fee to 0 in that case -
min(approved, configured) with approved = 0 - but _build_builder_field still
attaches {"b": <foundation>, "f": 0}, and Hyperliquid rejects any order
carrying a builder the sender has not approved regardless of the fee being
zero. The connector cannot place orders at all until the user approves a
builder they may not want.
Omitting the field at a 0 fee is what the existing comments already assume the
behaviour to be ("otherwise it is 0 bps"), and it collects nothing either way.
An approved user is unaffected: the fee is non-zero and the field is attached
exactly as before.
Two existing tests asserted the field was still built at f=0, one of them
noting "Still attributes to the Foundation builder address, just at 0 bps" -
that is the assumption the venue rejects, so both now assert it is omitted.
Adds coverage that the key is absent from the signed order action rather than
present with a zero value.
Reproduced on mainnet against an account with maxBuilderFee = 0; orders
succeed with the field omitted.
Greptile SummaryThis PR prevents Hyperliquid perpetual orders from including an unapproved builder when the resolved fee is zero.
Confidence Score: 5/5The PR appears safe to merge with no actionable correctness or security issues identified. The new guard matches the resolved builder-fee lifecycle, preserves positive-fee attribution, and is covered through both direct field construction and order payload generation.
|
| Filename | Overview |
|---|---|
| hummingbot/connector/derivative/hyperliquid_perpetual/hyperliquid_perpetual_derivative.py | Adds a focused guard that omits the optional builder field when its resolved fee cannot collect anything and would cause venue rejection. |
| test/hummingbot/connector/derivative/hyperliquid_perpetual/test_hyperliquid_perpetual_derivative.py | Updates zero-fee expectations and verifies the real order payload excludes the builder key. |
Reviews (1): Last reviewed commit: "fix(hyperliquid): omit the builder field..." | Re-trigger Greptile
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
1 participant
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.
Problem
Every order fails for any user who has not approved the Hummingbot Foundation builder:
The connector is unusable on mainnet until the user approves a builder they may not know about and may not want to pay.
Cause
_initialize_builder_fee()resolves the fee correctly —min(approved, configured), which is0whenmaxBuilderFeereturns0:But
_build_builder_field()attaches the field regardless of the resolved fee:Hyperliquid rejects an order carrying a builder the sender has not approved even when the fee is 0. The surrounding comments assume otherwise — "The fee only takes effect if the user has approved this builder in Condor; otherwise it is 0 bps" — which holds for the fee but not for the order.
Fix
Omit the field when the resolved fee is 0. That matches what the existing comments already assume the behaviour to be, and it collects nothing either way.
An approved user is unaffected: the fee is non-zero and the field is attached exactly as before. Vault and testnet handling is untouched.
Tests
Two existing tests asserted the field was still built at
f=0, one of them noting "Still attributes to the Foundation builder address, just at 0 bps" — that is precisely the assumption the venue rejects. Both now assert the field is omitted.Added:
test_builder_field_omitted_when_fee_is_zerotest_place_order_omits_builder_key_when_fee_is_zero— asserts the key is absent from the signed action rather than present with a zero value, driving the real_place_orderpath148 passedfor the full connector suite.Verification
Reproduced on mainnet with an account where
maxBuilderFeereturns0: every order failed with the message above. With the field omitted, orders submit and fill normally.