builderApprovedFundingByTime
Hourly funding payments made by users who had an active builder-fee approval for your builder address.
The funding counterpart of builderApprovedFillsByTime: every hourly funding payment made by a user while they had approved your builder, across all of those users at once. Each row is exactly a userFunding row with the paying user added.
Why you need this
Funding is often the largest recurring cost or income for a perp position, and it is invisible to every routing-based endpoint. If you report net PnL for the users who approved you, fills alone overstate it; this endpoint supplies the missing leg without you having to poll userFunding per user.
POST Request
type
string
Required. "builderApprovedFundingByTime"
builder
string
Required. Builder address, 42-char hex.
startTime
number
Required unless cursor is given. Inclusive, milliseconds.
endTime
number
Optional. Inclusive, milliseconds.
cursor
string
Optional. Continue from a previous page. Format "{time}_{user}_{coin}".
limit
number
Optional. Default and maximum 2000.
Results are returned oldest-first, ordered by (time, user, coin).
curl -X POST https://api.hydromancer.xyz/info \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"type": "builderApprovedFundingByTime",
"builder": "0x1924b8561eef20e70ede628a296175d358be80e5",
"startTime": 1786000000000,
"limit": 100
}'import requests
resp = requests.post(
"https://api.hydromancer.xyz/info",
headers={"X-API-Key": "YOUR_API_KEY"},
json={
"type": "builderApprovedFundingByTime",
"builder": "0x1924b8561eef20e70ede628a296175d358be80e5",
"startTime": 1786000000000,
"limit": 100,
},
)
funding = resp.json()Pagination
Take the last returned row and build cursor as "{time}_{user}_{delta.coin}", then repeat the request with that cursor instead of startTime. A page shorter than limit means you have reached the end of the range.
Funding is charged once an hour, and every payment of that hour carries the same time, so a page boundary usually falls inside an hour. That is why the cursor carries user and coin rather than a transaction index: it resumes exactly after the last row you saw without repeating or skipping the rest of the hour.
Semantics
Hourly rows. One row per
(user, coin)position per funding hour, with the block timestamp of the funding event astime. There are no rows between funding hours.Attributed at the block. An approval applies from the block it lands in, and a revocation likewise. A payment that happened while an approval was active stays attributed permanently — revoking does not remove past rows from this endpoint.
Same row as
userFunding.time,hashanddeltaare byte-for-byte what userFunding returns for that user; onlyuseris added.hashis always the zero hash, as it is there, because funding is a protocol event with no transaction.
Response Fields
user
string
The user who paid or received the funding, and who had approved your builder at the time.
time
int
Funding block timestamp (ms).
hash
string
Always the zero hash.
delta
object
Funding payment details, identical to userFunding.
delta.type
string
Always "funding".
delta.coin
string
Asset symbol.
delta.usdc
string
USDC amount of the funding payment (negative when paid).
delta.szi
string
Position size at the time of funding.
delta.fundingRate
string
Funding rate applied.
Last updated