Minting

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

The endpoints are named deposit because they are shared across Paxos Labs yield products. For PAXGy, a deposit is a mint.

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.

Step 1: Authorize PAXG

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

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

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

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.

Response

{
  "transaction": {
    "to": "0xF6dE922D08cF9Ee4e7cE25ca1f3936EC1AA1f62C",
    "data": "0x...",
    "value": "0"
  }
}

Broadcast it as-is:

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 share 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

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.

Previewing the mint

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

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.

Redemption

Exchange PAXGy back for PAXG.

Cross-chain

Mint directly onto another chain.

Getting started

Amplify

PAXGy

Transit

USDG0

Webhooks

Step 1: Authorize PAXG

Step 2: Prepare the mint

Parameters

Response

Choosing `slippageBps`

Previewing the mint

Errors

Next

Redemption

Cross-chain

​Step 1: Authorize PAXG

​Step 2: Prepare the mint

​Parameters

​Response

​Choosing slippageBps

​Previewing the mint

​Errors

​Next

Redemption

Cross-chain

Step 1: Authorize PAXG

Step 2: Prepare the mint

Parameters

Response

Choosing `slippageBps`

Previewing the mint

Errors

Next