Use daily claims to fund a quoting strategy, or obtain Assets from another Network's testnet faucet to exercise deposits. Testnet Assets have no monetary value.
Testnet is the public environment and runs the latest release at api.testnet.polyester.com.
Mainnet is coming soon. See Environments and hosts for connection details and the Quickstart for your first order.
Claim funds programmatically
claims.v1.ClaimsService requires a session JWT. API keys cannot read claim status or claim
rewards. Keep this funding step separate from a bot that trades with an API key.
Your root account must have a verified X or Discord account. Either provider is sufficient. A reward must be active for the current UTC day. An available reward in the status response does not replace the verification check made when you claim.
The UTC_DAILY policy allows one claim per root account per UTC calendar day. Use resetAt for the next day's boundary, rather than waiting a rolling interval after the previous claim.
Choosing a Subaccount does not give it a separate daily allowance.
Read today's reward
Call GetDailyClaimStatus or GET /v1/trading/daily-claim.
The response identifies today's campaign, rewards, reset time, and any existing claim.
Future reward schedules are not returned.
With your session JWT in POLYESTER_SESSION_JWT:
curl --fail-with-body
'https://api.testnet.polyester.com/v1/trading/daily-claim'
-H "Authorization: Bearer ${POLYESTER_SESSION_JWT}"Read the Assets and amounts from rewards. REST returns each amount as a decimal string;
ConnectRPC returns amount_e18 in unified units with 18 decimals. Use decimal or integer
arithmetic when allocating balances.
Claim to the chosen account
Call ClaimDailyReward or POST /v1/trading/daily-claim/claim.
An empty request selects your root account:
curl --fail-with-body
'https://api.testnet.polyester.com/v1/trading/daily-claim/claim'
-H "Authorization: Bearer ${POLYESTER_SESSION_JWT}"
-H 'Content-Type: application/json'
--data '{}'To receive the reward in a Subaccount, supply its public ID in subaccountId on REST or subaccount_id on ConnectRPC, using that interface's ID encoding. It must be active and owned
by your root account. Shared access to another owner's Subaccount does not qualify.
The destination is fixed when today's claim is created. Retrying returns the same claim and destination, even if you request another destination. All reward Assets are transferred together into the recipient's Trading balance.
Confirm the payout
Read status again until the claim completes. The REST states are AVAILABLE, PROCESSING, CLAIMED, UNAVAILABLE, and PAYOUT_DELAYED; the ConnectRPC enum names carry the CLAIM_ prefix.
Only treat a completed payout and the resulting available Trading balance as funds ready to trade.
For a delayed payout, inspect payoutDelayReason on REST or payout_delay_reason on ConnectRPC.
The claim remains recorded and is retried automatically. Retrying the claim request does not
create another reward or change its amount.
Handle claim errors
Use structured codes rather than matching error messages. REST uses a problem response code;
ConnectRPC uses error details, including claims.v1.ErrorDetail for claims errors.
Authentication errors can use authentication-specific details.
UNAUTHENTICATED/AUTH_SESSION_KIND_NOT_ALLOWED
Use a valid interactive session JWT. An API key cannot authorize claims.SOCIAL_VERIFICATION_REQUIRED
Verify either X or Discord before claiming.CLAIM_UNAVAILABLE
No eligible reward is available today. Read status and its reset time instead of repeatedly submitting claims.SUBACCOUNT_NOT_FOUND/SUBACCOUNT_INACTIVE
Choose an active Subaccount owned by your root account, or omit the destination to use the root account.CLAIM_TEMPORARILY_UNAVAILABLE/CLAIM_PAYOUT_UNAVAILABLE
The payout is delayed or paused. Read status; the recorded claim is paid automatically once the condition clears.RATE_LIMIT_EXCEEDED/CONFLICT
Back off before retrying. Repeated claim requests still refer to the same daily claim.
For malformed requests, permission failures, transport failures, and other server errors, follow Error responses and Error codes.
Test deposits from other Networks
For deposit testing, obtain Assets in an external testnet wallet from Testnet faucets. If a faucet is unavailable, consult Faucet backups. These are third-party services; their eligibility rules and availability apply separately from Polyester's daily claims.
Follow Deposits to obtain the deposit address for the intended account and Network. Send the matching test Asset to that address.
Move Funding balances to Trading
Funding and Trading are separate balances. If your funds arrive in Funding, move them to Trading through the account's on-chain TradingGateway deposit on Polyester Chain before placing orders. See Internal transfers for the route.
The REST and ConnectRPC internal-transfer operation moves Trading to Trading. It does not perform the Funding-to-Trading move. Daily claim payouts already arrive in Trading.
Fund several strategy Subaccounts
Create and configure your strategy accounts as described in Subaccounts and roles. Each Subaccount has its own balances and must have a policy that permits the actions your strategy needs.
For several strategies, claim to the root account, then allocate its Trading balance with Trading-to-Trading internal transfers. Use a distinct idempotency key per logical allocation and reuse it when retrying that transfer. Alternatively, claim directly to one owned Subaccount and redistribute from there with the required permissions. Selecting several destinations across retries cannot split a daily claim.