Queue an allocation of the caller's side of a matched trade from their trading
(CLOB) balance. The side is derived from the trade: the buyer pays the cash
amount, the seller delivers the security. Only the two trade parties can fund;
anyone else gets 422 not_fundable, before and after the match.

Select the leg with the optional body:

• Empty body or {}: the caller's side of the trade.
• {"leg": "fee"}: the operator fee leg. The requester owes the fee whichever
  side they took, so only the requester can fund it. The engine holds the trade
  until the fee is funded.

The balance check uses the same available balance as
GET /api/trading/balances. Re-posting for a side that is already queued or
funded is a no-op success. Unknown body fields are rejected.

Wait for the leg's settlement contract. When a quote is accepted, the trade is
matched first and its on-ledger settlement contract (DvP) is created a moment later.
A leg can only be funded once that contract exists, which the request shows as
open_status (close_status for a repo close leg) created or partial. While it
is null or pending, this endpoint returns 422 not_fundable and queues nothing;
poll the request and retry. The phase alone does not tell you: funding_required
starts at acceptance. The fee's contract is created with the open leg's. The same
applies when funding from your own wallet: there is no allocation request to sign
until the contract exists.

Funding from your own wallet

Instead of this endpoint, a trade party can fund directly from their own wallet.
Once a quote is accepted and the trade is matched, the RFQ engine creates an
allocation request for the trade, and another for the fee when the trade carries
one. Each appears as an active contract on the wallet of every party that sends
assets on it. To fund, pull those active contracts from your wallet and sign an
allocation for each leg you send:

1. Build the settlement ref from the request's trade_id: <trade_id> for
   the trade, <trade_id>:fee for the operator fee.
2. Pull your wallet's active contracts by interface
   #splice-api-token-allocation-request-v2:Splice.Api.Token.AllocationRequestV2:AllocationRequest.
   If your wallet does not return interface views, query the engine's template
   #temple-settlement-impl:Temple.RFQ.Leg:TradeLegV2 instead.
3. Match the trade. Keep the contract whose view has
   settlement.settlementRef.id equal to the settlement ref, then each entry of
   transferLegs whose sender is your party. Allocations must be submitted
   before settlement.allocateBefore.
4. Skip legs already funded. Check your wallet's active
   #splice-api-token-allocation-v2:Splice.Api.Token.AllocationV2:Allocation
   contracts for one with settlement.id equal to the settlement ref and a
   SenderSide entry for the leg, so you do not allocate it twice.
5. Sign and submit AllocationFactory_Allocate for each remaining leg, acting
   as your party, on the instrument's allocation factory
   (#splice-api-token-allocation-instruction-v2:Splice.Api.Token.AllocationInstructionV2:AllocationFactory).
   Get the factory contract id, choice context, and disclosed contracts from the
   instrument admin's token registry
   (POST {registry}/allocation-instruction/v2/allocation-factory), or for CC
   (Amulet) from GET /api/amulet/disclosures/v2. Fund the leg from unlocked
   holdings that cover amount.

Take the parties, amount, instrument, and deadlines from the allocation request
exactly as they appear. The engine rejects an allocation that differs from the
request. Funding status shows up on the request (status, funding) once the
engine sees the allocation.

Example command (buyer funding the cash leg):

{
  "commands": [{ "ExerciseCommand": {
    "templateId": "#splice-api-token-allocation-instruction-v2:Splice.Api.Token.AllocationInstructionV2:AllocationFactory",
    "contractId": "<factory contract id>",
    "choice": "AllocationFactory_Allocate",
    "choiceArgument": {
      "settlement": {
        "executors": ["<settlement.executor>"],
        "id": "<trade_id>",
        "cid": null,
        "meta": { "values": { "temple.settlementId": "<trade_id>" } }
      },
      "allocation": {
        "admin": "<instrument admin>",
        "authorizer": { "owner": "<your party>", "provider": null, "id": "" },
        "transferLegSides": [{
          "transferLegId": "payment-0",
          "side": "SenderSide",
          "otherside": { "owner": "<leg receiver>", "provider": null, "id": "" },
          "amount": "162450.25",
          "instrumentId": "USDCx",
          "meta": { "values": {} }
        }],
        "settlementDeadline": "<settlement.settleBefore>",
        "nextIterationFunding": null,
        "committed": false,
        "meta": { "values": { "tag": "temple-rfq" } }
      },
      "requestedAt": "2026-10-21T18:06:00Z",
      "inputHoldingCids": ["<holding contract id>"],
      "actors": ["<your party>"],
      "extraArgs": { "context": "<factory choice context>", "meta": { "values": {} } }
    }
  } }],
  "actAs": ["<your party>"],
  "disclosedContracts": ["<from the factory response>"]
}

Also add a ReceiverSide entry (with otherside set to that leg's sender) for
each other leg of the same allocation request where you are the receiver and the
instrument admin is the same, ordered by transferLegId.