# Asset Movement

Asset Movement Anchors are the on- and off-ramps between Keeta and the outside world. They cover the full range of providers that move value across networks: commercial banks, stablecoin ramps, blockchain bridges, and card networks. Once connected, any of these rails can be reached through the same interface, whether you're depositing fiat from a bank account, withdrawing to a crypto wallet, or bridging between chains. This page covers the two mechanics your application will use: [**managed transfers**](#managed-transfers) for one-off movement of value, and [**persistent addresses**](#persistent-addresses) for reusable destinations that forward incoming assets to Keeta automatically.

## Managed Transfers

Managed transfers are the primary way of moving value to and from Keeta. A client specifies the destination and amount, whether a bank account or a blockchain address. The selected provider registers the request and informs the client how to complete it. Once the provider receives the funds, it automatically completes the transfer on the destination side. Each managed transfer carries a full lifecycle, and its status can be monitored from request through settlement.

### How They Are Constructed

Each transaction [request](https://github.com/KeetaNetwork/anchor/blob/cc4af48060705ca57bfe31640ddf47fcedf3bb91/src/services/asset-movement/common.ts#L345-L389) comprises the following information:

* **Asset** being transferred (i.e. `$BTC` or `EUR`) — or a pair of assets if the transfer involves a conversion.
* **Value** — how much value is being moved. Always specified in the source asset's smallest unit (cents for `USD`, wei for `$ETH` , etc.)
* The **source** — where the value originates. A [**location**](https://github.com/KeetaNetwork/anchor/blob/cc4af48060705ca57bfe31640ddf47fcedf3bb91/src/services/asset-movement/lib/location.ts#L5-L102) identifying the rail or network (a blockchain, a banking system, a card network, etc.)
* The **destination** — where the value should go. A **location** and a **recipient**, which may be a wallet address, or bank account.

## Persistent Addresses

**Persistent Addresses** are reusable destination addresses that automatically forward received assets to your Keeta account. Think of them as permanent forwarding addresses for different networks and rails.

When moving assets from external networks (like Ethereum, Bitcoin, or bank accounts) to Keeta, you typically need a unique destination address. Persistent addresses:

* Remain constant across multiple transfers
* Automatically forward incoming assets to your Keeta account
* Work across different asset types and networks
* Can be shared with others for recurring payments

### **How They Are Constructed**

A persistent address consists of:

* **Template**: Defines the asset type, location (chain/bank), and rail
* **Address Instance**: The actual address generated from the template
* **Forwarding Rules**: Instructions for how to route received assets to Keeta

### Common Use Cases for Persistent Addresses

* **Receiving Salary** - Bank deposit could be made directly to a Keeta account
* **Cross-Chain DeFi** - Moving funds between blockchain networks

## Running an Asset Movement Anchor

If you already operate a service that moves value across networks, the Anchor SDK is mainly a translation layer between that service and the Keeta interface. A DeFi bridge can expose itself by forwarding EVM contract call instructions in the Anchor format. A stablecoin ramp can map its fiat deposit and issuance flow to managed transfer endpoints, and verify user compliance through certificates issued by KYC Anchors instead of re-collecting documents.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeta.com/anchors/anchor-types/asset-movement.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
