GRIDer参与话题 3消息总数 4

GRIDer 2026-06-27 15:57:17 ↗ Hyperliquid

👍 Thanks

👍 Thanks

GRIDer 2026-06-27 05:47:24 ↗ Hyperliquid Builder Fee 主账户审批对子账户适用性问题

Hi, If a master account approves a builder fee (approveBuilderFee) and its agent/API wallet then places an order on a subaccount (using vaultAddress = subaccount), is the builder fee validated against the master's approval or the subaccount's? I ask because approveBuilderFee is a user-signed action with no vaultAddress field, so there seems to be no way to approve a builder fee for a subaccount. Querying maxBuilderFee per address shows subaccounts at 0 even when the master has approved. Can builder orders run on a subaccount at all, and if so, whose approval is checked? Thanks! 🙏

Hi, If a master account approves a builder fee (approveBuilderFee) and its agent/API wallet then places an order on a subaccount (using vaultAddress = subaccount), is the builder fee validated against the master's approval or the subaccount's? I ask because approveBuilderFee is a user-signed action with no vaultAddress field, so there seems to be no way to approve a builder fee for a subaccount. Querying maxBuilderFee per address shows subaccounts at 0 even when the master has approved. Can builder orders run on a subaccount at all, and if so, whose approval is checked? Thanks! 🙏

GRIDer 2026-06-10 16:51:59 ↗ Hyperliquid API钱包数量IP限制及Hydromancer解决方案

Thanks a lot for the info, that’s very helpful. Yeah, I agree Hydromancer sounds like the best long-term solution. In the meantime, while the platform scales, I’ll likely move to using REST only to verify order fills, so we can avoid hitting the per-IP wallet limit on user-specific WS subscriptions. Thanks again!

Thanks a lot for the info, that’s very helpful. Yeah, I agree Hydromancer sounds like the best long-term solution. In the meantime, while the platform scales, I’ll likely move to using REST only to verify order fills, so we can avoid hitting the per-IP wallet limit on user-specific WS subscriptions. Thanks again!

GRIDer 2026-06-09 06:17:55 ↗ Hyperliquid 用户询问 API 的 per-IP 限制及如何扩展并发用户

Hey, quick one about the per-IP limits for ws and rest. We run a grid trading platform (builder 0x0176337C97BB884b8ac4bE2276A5c779ab1156B9) that manages orders for a lot of separate user accounts. Each account needs fill detection to re-place its grid orders, so right now we open userFills + orderUpdates per user over ws. The docs mention a max of 10 unique users across user-specific subscriptions per IP, so we end up capped at around 10 concurrent users per IP. Couple of things I wanted to check: - Is that "10 unique users" limit per IP or per connection? - Can it be bumped for a builder, or is sharding across IPs the only way? - If instead of per-user ws subs we detect fills with rest (orderStatus triggered by allMids price crosses), is that only bound by the 1200 weight/min IP limit, with no per-user cap? Basically trying to confirm whether rest is a valid path to go past 10 users per IP or if we're missing some hidden limit. Thanks!

Hey, quick one about the per-IP limits for ws and rest. We run a grid trading platform (builder 0x0176337C97BB884b8ac4bE2276A5c779ab1156B9) that manages orders for a lot of separate user accounts. Each account needs fill detection to re-place its grid orders, so right now we open userFills + orderUpdates per user over ws. The docs mention a max of 10 unique users across user-specific subscriptions per IP, so we end up capped at around 10 concurrent users per IP. Couple of things I wanted to check: - Is that "10 unique users" limit per IP or per connection? - Can it be bumped for a builder, or is sharding across IPs the only way? - If instead of per-user ws subs we detect fills with rest (orderStatus triggered by allMids price crosses), is that only bound by the 1200 weight/min IP limit, with no per-user cap? Basically trying to confirm whether rest is a valid path to go past 10 users per IP or if we're missing some hidden limit. Thanks!