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

# Minting

> Deposit PAXG and receive PAXGy using the REST calldata endpoints

Minting PAXGy is a deposit of PAXG. The flow is: authorize PAXG, prepare the mint calldata, sign, and broadcast.

<Info>
  The endpoints are named `deposit` because they are shared across Paxos Labs
  yield products. For PAXGy, a deposit **is** a mint.
</Info>

<Warning>
  Minting happens on **Ethereum mainnet only** (`chainId: 1`). PAXG does not
  exist on X Layer, so there is nothing to mint from there. To end up with
  PAXGy on X Layer, either mint on Ethereum and transfer it across, or mint
  straight onto X Layer in one transaction. See
  [Cross-Chain Transfers](/v1.0.0/intro/products/paxgy/api-calldata/cross-chain).
</Warning>

## Step 1: Authorize PAXG

`GET /v2/core/authorization` tells you whether PAXG needs a permit signature, a standard approval, or already has enough allowance.

```bash theme={null}
curl -G "https://api.paxoslabs.com/v2/core/authorization" \
  -H "x-api-key: pxl_your_key" \
  --data-urlencode "vaultAddress=0x6c6494Fd9962eB98B94ffA48F6679058F820700e" \
  --data-urlencode "tokenAddress=0x45804880De22913dAFE09f4980848ECE6EcbAf78" \
  --data-urlencode "amount=1000000000000000000" \
  --data-urlencode "userAddress=0xYourWallet" \
  --data-urlencode "chainId=1"
```

Branch on `method`:

| `method` | What to do |
| - | - |
| `already_approved` | Nothing. Go straight to step 2 |
| `approval` | Broadcast `approvalTransaction.encoded` to the PAXG token address, wait for the receipt, then go to step 2 |
| `permit` | Sign `permitData` as EIP-712 typed data and pass the signature to step 2 |

## Step 2: Prepare the mint

```bash theme={null}
curl -G "https://api.paxoslabs.com/v2/amplify/deposit" \
  -H "x-api-key: pxl_your_key" \
  --data-urlencode "vaultAddress=0x6c6494Fd9962eB98B94ffA48F6679058F820700e" \
  --data-urlencode "depositAsset=0x45804880De22913dAFE09f4980848ECE6EcbAf78" \
  --data-urlencode "depositAmount=1000000000000000000" \
  --data-urlencode "userAddress=0xYourWallet" \
  --data-urlencode "chainId=1"
```

### Parameters

| Parameter | Type | Required | Description |
| - | - | - | - |
| `vaultAddress` | `string` | Yes | The PAXGy token address |
| `depositAsset` | `string` | Yes | PAXG |
| `depositAmount` | `string` | Yes | PAXG amount in base units |
| `userAddress` | `string` | Yes | Wallet sending the transaction |
| `chainId` | `number` | Yes | EVM chain ID |
| `to` | `string` | No | Who receives the PAXGy. Defaults to `userAddress` |
| `slippageBps` | `number` | No | Tolerance on the minimum PAXGy accepted, 0–10000. Defaults to `50` (0.5%) |
| `permitSignature` | `string` | No | From step 1, when `method` was `permit`. See the warning below |
| `permitDeadline` | `number` | No | Required alongside `permitSignature` |
| `destinationChainId` | `number` | No | Mint onto another chain. See [Cross-chain](/v1.0.0/intro/products/paxgy/api-calldata/cross-chain) |

<Warning>
  **A permit signature in a query string is exposed.** This is a `GET`, so
  `permitSignature` and `permitDeadline` land in URLs, and therefore in browser
  history, proxy and server access logs, and any intermediate cache. A signature
  that has not yet been consumed on-chain is a bearer authorization to move the
  signer's PAXG up to the permitted amount.

  If you use the permit path, call this endpoint from a trusted backend rather
  than a browser, redact query strings in your logging, set a short
  `permitDeadline`, and broadcast immediately so the window in which a leaked
  signature is usable stays small. The approve-and-deposit path in step 1 puts
  nothing sensitive in the URL and is the safer default when the extra
  transaction is acceptable.
</Warning>

### Response

```json theme={null}
{
  "transaction": {
    "to": "0xF6dE922D08cF9Ee4e7cE25ca1f3936EC1AA1f62C",
    "data": "0x...",
    "value": "0"
  }
}
```

Broadcast it as-is:

```typescript theme={null}
const hash = await walletClient.sendTransaction({
  to: prepared.transaction.to,
  data: prepared.transaction.data,
  value: BigInt(prepared.transaction.value),
  chainId: 1,
})
```

## Choosing `slippageBps`

The prepared calldata carries a minimum acceptable PAXGy amount. It is computed from the exchange rate **and** the mint fee at the moment you call the endpoint. PAXGy's mint fee tracks the live PAXG:gold price, so both can move before the transaction lands.

If they move further than your tolerance, the transaction reverts rather than filling at a worse rate. That is the intended protection, but it means the default 0.5% can be too tight for slow signing flows:

| Signing flow | Suggested `slippageBps` |
| - | - |
| Hot wallet, immediate confirm | `50` (default) |
| Hardware wallet | `100` |
| Multisig or manual approval | `200`+, and re-prepare if approval takes more than a few minutes |

<Warning>
  Widening slippage does not cost you anything when the market is calm. It only
  raises the worst case you are willing to accept. Do not set it so wide that a
  genuine price dislocation still fills.
</Warning>

## Previewing the mint

To show a user what they will receive before they commit, read the current exchange rate and fee from `GET /v2/amplify/vaults`:

```bash theme={null}
curl -G "https://api.paxoslabs.com/v2/amplify/vaults" \
  -H "x-api-key: pxl_your_key" \
  --data-urlencode "filter=chainId=1"
```

Each `deployments[].assets[]` entry carries `depositFees` for that asset. Remember the `type: "dynamic"` caveat: the figure is a snapshot, so label it as an estimate in your UI.

## Errors

| Status | Cause |
| - | - |
| `400` | Malformed parameters, or a deposit fully consumed by fees (raise the amount) |
| `403` | The API key has no access to this account |
| `404` | No PAXGy deployment on the requested `chainId` |
| `503` | The price feed is stale or the chain is unreachable. Retry shortly |

A `503` mentioning pricing means the gold price feed backing the fee has gone stale. This is transient and self-resolves; do not retry in a tight loop.

## Next

<CardGroup cols={2}>
  <Card title="Redemption" icon="arrow-up" href="/v1.0.0/intro/products/paxgy/api-calldata/redemption">
    Exchange PAXGy back for PAXG.
  </Card>

  <Card title="Cross-chain" icon="arrows-left-right" href="/v1.0.0/intro/products/paxgy/api-calldata/cross-chain">
    Mint directly onto another chain.
  </Card>
</CardGroup>


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