---
title: "Propose a settlement"
method: POST
path: "/atlas/settlements"
tags: ["Atlas Settlement Network"]
---

# Propose a settlement

`POST /atlas/settlements`

Permissions required: **Propose and Accept settlements**


Propose a settlement with a counterparty for a list of assets coming from and/or arriving into wallets owned by your participant.

Positive amounts indicate funds to be received and negative amounts indicate funds to be sent.

```json
[
	{
		"walletId": "d4578f401daadff65615236c5ad1e12c",
		"quantity": "-1.1",
		"assetType": "BTC"
	},
	{
		"walletId": "43a9aeac02c851f4868f9d89aabde494",
		"quantity": "20.62",
		"assetType": "ETH"
	}
]
```
For example, the above wallet amounts indicate you will send 1.1 BTC from your wallet `d4578f401daadff65615236c5ad1e12c` and receive 20.62 ETH into your wallet `43a9aeac02c851f4868f9d89aabde494`.

The steps to create a settlement are:
1. The proposer participant proposes it, selecting an acceptor, assets, amounts and wallets.
2. The proposer authorizes it, either through the API or mobile app signing.
3. The acceptor participant accepts it, selecting wallets to use.
4. (optional) The acceptor authorizes it, either through the API or mobile app signing.
5. The settlement is funded in the sending wallets.
6. The assets are transferred on-chain, as directed by the settlement.

Steps 2 or 3 can happen out of order.
Step 4 is skipped if the acceptor is not sending any assets.
The settlement stays in the `ActionNeeded` state until it reaches step 6. Then it enters the `Executing` state and, after that, it enters one of the final states.

## Headers

- `Api-Signature` string, required
- `Api-Timestamp` integer, required

## Request body

- SNSettlementProposal
  - `acceptorId` string, required
  - `applyPostLock` boolean — Conditional. This parameter is only applicable for clients utilizing Atlas settlements integrated with "Anchorage Vesting". When set to true, it enables the automatic creation of post-settlement vesting schedules. Note: Enabling this will place indefinite holds on the acceptor's destination wallets immediately following a successful settlement
  - `clientReferenceId` string — An ID, set by the proposer, visible to both sides, to uniquely identify the purpose of the settlement so that both sides can account for it correctly.
  - `idempotentId` string, required
  - `proposerId` string, required
  - `useGasStation` boolean — Option to request to use Gas Station to cover fees for proposer.
  - `vaultId` string, required — The vault ID of the proposer. It needs to match the vault that the wallets are in.
  - `walletAmounts` SNWalletAmount[], required — In a proposal, each asset type can appear only once in the wallet amount list.
    - `assetType` string, required — A string representing a type of crypto-asset, which usually corresponds to the crypto asset's ticker symbol. Use `/asset-types` to list all of the supported asset types for your organization.
    - `quantity` string, required — The numeric value of this amount, excluding units. Use positive numbers for receiving and negative for sending assets. Amounts never include fees.
    - `walletId` string

## Response `201`

settlementId

- SNProposeSettlementResponse
  - `settlementId` string, required

## Other responses

- `400` — Bad Request
- `401` — Unauthenticated
- `403` — Forbidden
- `429` — Too Many Requests
- `500` — Internal Server Error

---

[API](https://skmtc.net/anchorage/apis/anchorage-digital-api-reference.md) · [All operations](https://skmtc.net/anchorage/apis/anchorage-digital-api-reference/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/anchorage/anchorage-digital-api-reference/versions/166864b1ec6d/schema)