> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kuru.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Execute packed slot replacement

> Execute compact 32-byte maker-slot operations.

Submits `wallet.execute_replace_by_slot_packed` for clients that implement Kuru's compact slot-operation codec.

<Info>The example uses the verified mainnet WETHUSDC market, but its wallet, nonce, deadline, account ID, packed operations, and signature are placeholders. Build and sign a fresh intent for the selected network before submitting.</Info>

<ParamField body="requestId" type="string" required>New lowercase UUIDv7 for correlation.</ParamField>
<ParamField body="method" type="string" required default="wallet.execute_replace_by_slot_packed">Must be `wallet.execute_replace_by_slot_packed`.</ParamField>
<ParamField body="wallet" type="string" required>Secondary trading EOA matching the bearer JWT.</ParamField>

<ParamField body="payload" type="object" required>
  Signed `ReplaceBySlotIntent` containing `header`, `packedOps`, `expectedOrderIds`, and `signature`.
</ParamField>

<ParamField body="authorization7702" type="object | null">Normally `null` after onboarding.</ParamField>

`packedOps` contains one to 256 canonical 32-byte words. `expectedOrderIds` must contain one uint64 decimal string per word, and target slots must be unique.

Sign `ReplaceBySlotIntent` with the `KuruTradingWallet` EIP-712 domain: version `2`, chain ID `143` on mainnet or `10143` on testnet, and the **delegated trading EOA** as `verifyingContract` (not the shared implementation or Relay address). Version-`1` wallet signatures are invalid for the current implementation; rebuild and re-sign pending intents rather than resubmitting them. AccountCore signer grants use their separate `KuruAccountCore` version-`1` domain. See [Trading-wallet Signing](/sdk/trading-wallet).

### Slot binding and planning-time checks

Relay checks each slot binding while planning the request, before the transaction enters the signer queue. This check reads the Relay's currently observed proposed state; it does not wait for finalization or for preceding transactions to become visible.

For every packed operation, `expectedOrderIds` controls what Relay is allowed to replace:

| Value | Required slot state |
| - | - |
| `0` | The slot must be empty |
| A specific order ID | The slot must contain that exact order |
| `18446744073709551615` | Accept whichever order currently occupies the slot (wildcard) |

If a replacement is signed with `0` while the preceding placement is already present in proposed state, Relay rejects it because the slot is no longer empty. If it is signed with the new order ID while Relay still observes an empty slot, upstream-state lag can produce the inverse rejection. The error alone does not distinguish these cases.

The signer-ordering guarantee preserves handoff order, but it does not make concurrent planning observe preceding transactions. For continuous slot replacement, use the wildcard value when “replace whatever currently occupies this slot” is the intended behavior; this avoids waiting to learn the preceding order ID. Use exact IDs only when the corresponding proposed state has been observed first.

<RequestExample>
  ```curl cURL theme={null}
  curl --request POST --url https://relay.mainnet.kuru.io/relay \
    --header "Authorization: Bearer $KURU_RELAY_JWT" \
    --header 'Content-Type: application/json' \
    --data '{
      "requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f",
      "method":"wallet.execute_replace_by_slot_packed",
      "wallet":"0x1111111111111111111111111111111111111111",
      "payload":{"header":{"accountId":"123","market":"0x8121ee960066e4344a213f9ac7502395502aee7a","authNonce":"1","nonce":"1720000000124","deadline":"1720000030","clientOrderId":"0x0000000000000000000000000000000000000000000000000000000000000002","builder":"0x0000000000000000000000000000000000000000","builderFeePps":"0"},"packedOps":"0x<one-or-more-32-byte-words>","expectedOrderIds":["31"],"signature":"0x..."},
      "authorization7702":null
    }'
  ```
</RequestExample>

The signature binds `keccak256(packedOps)` and the Solidity ABI hash of `expectedOrderIds`.

<ResponseExample>
  ```json BROADCAST theme={null}
  {
    "requestId": "018f5ef2-88a1-7b41-a826-4b679010f87f",
    "status": "BROADCAST",
    "txHash": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "sponsorAddress": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
    "sponsorNonce": "43",
    "transactionType": "DYNAMIC_FEE"
  }
  ```
</ResponseExample>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.