Self-Custody Trading

​

The flow

​

The signing wallet

​

Funding from more than one wallet

• Optional. Omitting it keeps the default.
• Repeat the key on the quote query (?fundingAddresses=0x…&fundingAddresses=0x…); send an array in the fill body.
• Every entry must be linked to the same account. An entry is an EVM address (0x + 40 hex) or a Solana public key (base58); see Solana.
• Duplicates and signingAddress itself are removed, and order does not matter: AGG decides which wallet pays what. The quote echoes the final set back as fundingAddresses.
• On the venue’s own chain only the signing wallet’s balance is usable. A funding wallet’s Hyperliquid balance cannot pay for a Hyperliquid trade, but it can move to other venues.
• Self-custody limit buys accept the same field, checked when the order is placed.

​

Quote and fill

import type { SmartRouteResponse } from "@agg-build/sdk";

type SelfCustodyQuote = SmartRouteResponse & {
  custodyWarnings?: { reason: string; message: string }[];
};

// client is authenticated and was created with { signer: mySigner }.
const quote = await client.request<SelfCustodyQuote>(`/orderbook/${encodeURIComponent(outcomeId)}/route`, {
  query: { signingAddress: wallet, side: "buy", maxSpend: "25" },
});

if (quote.status !== "ok") {
  throw new Error(quote.error ?? `Quote unavailable: ${quote.status}`);
}
if (quote.custodyWarnings?.length) {
  throw new Error(quote.custodyWarnings.map((warning) => warning.message).join("; "));
}

// Show the quote, fees, and warnings and obtain the user's confirmation before filling.
await client.fillSelfCustody({
  quoteId: quote.quoteId,
  signingAddress: wallet,
});

curl -s -G "$API/orderbook/$OUTCOME_ID/route" \
  -H "x-app-id: $APP_ID" -H "Authorization: Bearer $ACCESS_TOKEN" \
  --data-urlencode "signingAddress=$SIGNING_ADDRESS" \
  --data-urlencode "maxSpend=25"

curl -s -X POST "$API/execution/fill" \
  -H "x-app-id: $APP_ID" -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"quoteId":"'"$QUOTE_ID"'","signingAddress":"'"$SIGNING_ADDRESS"'"}'

​

Solana

{
  messageBase64: string;       // the serialized transaction MESSAGE; this is what gets signed
  transactionBase64: string;   // the full unsigned VersionedTransaction, for wallets that
                               // need one to display or simulate
  chainId: 792703809;
  blockhash: string;
  lastValidBlockHeight: number;
  summary: string[];           // one line per instruction group, for your UI
}

import { VersionedTransaction } from "@solana/web3.js";

case "solana_transaction": {
  const { transactionBase64 } = req.payload as { transactionBase64: string };
  const tx = VersionedTransaction.deserialize(Buffer.from(transactionBase64, "base64"));
  const signed = await wallet.signTransaction(tx);
  const index = signed.message.staticAccountKeys.findIndex(
    (key) => key.toBase58() === req.signerAddress,
  );
  if (index === -1) throw new Error(`signer ${req.signerAddress} is not a signer of this tx`);
  return `0x${Buffer.from(signed.signatures[index]).toString("hex")}`;
}

​

Fees

​

Venues

​

Funding sources

• When the deposit wallet is the only source for that amount, it is one eip712 signature from the EOA. The pUSD is unwrapped and bridged from the deposit wallet in a single transaction, and nothing passes through the EOA.
• Otherwise, for example when the EOA’s own funds pay part of it, the EOA first signs one eip712 transfer that moves the pUSD from the deposit wallet to the EOA. The bridge then asks for the usual cross-chain signatures for that token.

​

Choosing an approve mode

• Omit the field, or send approveMode: "sponsored". The user does not send an approve transaction. The wallet signs an eip7702_authorization: a signature over a raw digest, neither EIP-191 nor EIP-712. Many wallets cannot produce it. Where it works, the user signs once per chain, and later bridges on that chain need no further approve signature.
• approveMode: "user_broadcast": the user sends an ordinary approve as type: "transaction" and pays that transaction’s network fee. It sets up no delegation. A token that needs an approval needs it once per token per chain, after which trades use a permit signature only.

​

Not supported, with the exact code

• signingAddress is not supported in paper mode.
• The two wallet-linking messages above.
• approveMode "sponsored" is not valid for a self-custody Myriad fill …: omit the field or pass "user_broadcast". The quote stays fillable.
• Could not verify the signing wallet on BNB right now. Retry the fill in a moment.: a 503 with { retryable: true }. Not a refusal; retry the same fill.

• Direct orders (POST /execution/orders) reject signingAddress at validation.
• Withdrawals always act on the managed wallet. A self-custody user already holds their funds.

await client.redeemSelfCustody({ venueMarketOutcomeId, signingAddress });
// A signer that lives outside the client (a React provider) can be passed per call:
await client.redeemSelfCustody({ venueMarketOutcomeId, signingAddress }, { signer });

​

Self-custody limit orders

​

Prebuilt trading UI

<AggProvider client={client} config={{ features: { tradingCustody: "self-custody" } }}>
  <AggWalletSignerProvider value={signer}>{children}</AggWalletSignerProvider>
</AggProvider>

​

Related