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

# Report Deposit

<div className="venue-tags" aria-label="Supported venues">
  <span className="venue-tag">Polymarket</span>
</div>

Reports a direct Polygon pUSD transfer for verification and crediting. The source wallet must sign
the deposit intent. Notional derives the recipient, source, asset, amount, and finality from the
transaction and its receipt.

## Endpoint

```text theme={null}
POST /exchange
```

## Request Body

| Parameter | Type | Description |
| - | - | - |
| `action`\* | object | Deposit-report action |
| `signature`\* | string or object | 65-byte hex signature, or `{ r, s, v }` with `v` equal to 0, 1, 27, or 28 |

### action

| Field | Type | Description |
| - | - | - |
| `type`\* | string | Must be `"reportPolymarketDeposit"` |
| `polygonTxHash`\* | string | `0x`-prefixed 32-byte Polygon transaction hash |
| `logIndex` | number | Optional nonnegative integer; must match the verified direct transfer log |

There is no request nonce or `expiresAfter`. Do not supply a user address, token, amount, or other
extra fields; the request schema is strict. `logIndex` is an optional compatibility hint and does
not select which transfer receives credit.

## Signing and Submission

Use the actual deposit recipient shown by Notional's deposit instructions for the selected
deployment. The recipient is part of the signing domain; it is not the pUSD token contract or the
user's address.

With a connected Viem `walletClient` for the source wallet:

```typescript theme={null}
import {
  getPolymarketDepositIntentDomain,
  POLYMARKET_DEPOSIT_INTENT_TYPES,
} from "@notional/common";

const polygonTxHash = "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" as const;
// Set recipient to the deployment's actual deposit wallet address, in lowercase.
const signature = await walletClient.signTypedData({
  account: walletClient.account!,
  domain: getPolymarketDepositIntentDomain("mainnet", recipient),
  types: POLYMARKET_DEPOSIT_INTENT_TYPES,
  primaryType: "PolymarketDepositIntent",
  message: { transactionHash: polygonTxHash },
});

const request = {
  action: { type: "reportPolymarketDeposit", polygonTxHash },
  signature,
};
```

Use `"testnet"` for the testnet deployment. The EIP-712 domain has name
`NotionalPolymarketDeposit`, version `1`, Polygon chain ID `137`, the deposit recipient as
`verifyingContract`, and a deployment-specific salt. Use the shared builder to construct it.
The message contains only `transactionHash: bytes32`.

## Eligible Transfers

The proof must establish a successful ordinary pUSD ERC-20 `transfer` from the signing user to the
configured deposit recipient, with a positive amount and no unsupported additional effects. Bridge
transfers, contract-wallet flows, and protocol-managed transfers cannot be claimed through this
ordinary-transfer format. Approved API wallets cannot claim a new deposit for their owner.

The receipt must be finalized and canonically included. Reporting a hash alone never credits an
unverified amount.

## Response

```json theme={null}
{
  "status": "committed",
  "transactionId": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
  "amount": "100.00000000",
  "logIndex": 7,
  "userAddress": "0x1111111111111111111111111111111111111111",
  "alreadyProcessed": false
}
```

`committed` means the deposit credit was recorded. `amount` is decimal pUSD in ledger units,
`logIndex` identifies the verified receipt log, and `userAddress` is the credited source address.
Refresh [`assets`](/api-reference/info-endpoints/assets) to read the pUSD balance.

An exact already-credited deposit returns success with `alreadyProcessed: true`; it does not credit
funds twice. Check this flag before displaying a new-deposit notification.

## Errors

| HTTP status | Meaning |
| - | - |
| `400` | Malformed request or signature encoding |
| `404` | Deposit proof is not yet available or finalized; retry hint is 5 seconds |
| `409` | The exact transfer is already claimed by a protocol bridge transfer |
| `422` | Invalid deposit intent, ineligible transfer, conflicting evidence, or rejected credit |
| `503` | Direct deposit reporting is unavailable |

A validly encoded but invalid deposit signature is an eligibility failure (`422`), rather than a
successful deposit report.


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