# Off Ramp

The OffRamp contract is the main redemption component of the Colb ecosystem. It allows users to convert $USC stablecoins into fiat currency through a controlled, two-step off-ramp process.

The system is designed to be compliant and auditable, ensuring that only verified users can initiate redemptions while authorized operators manage settlement and completion. 

***

### How it Works?

The off-ramp process follows a simple lifecycle:

1. User creates a redemption request
2. Request is processed off-chain
3. Authorized operator completes or cancels the request

Each request is uniquely identified and fully traceable across chains and request types.

***

### Creating a Request

Verified users can initiate a redemption request by specifying an amount of $USC and selecting the desired request type.

When a request is created:

* The specified amount of $USC is securely locked in the OffRamp contract
* A unique and deterministic request ID is generated
* The request status is set to Pending
* An on-chain event is emitted to support off-chain indexing, monitoring, and settlement workflows

Each request represents the user’s on-chain intent to redeem $USC or settle a payment through the Colb off-ramp system and remains active until it is completed or cancelled.

***

### Request Types

The OffRamp contract supports multiple request types to accommodate distinct redemption and settlement use cases within the Colb ecosystem.

#### OffRamp

Represents standard redemption requests in which $USC is converted into fiat currency (e.g., USD) through traditional financial channels.

#### Payment

Represents settlement requests in which $USC is used to settle obligations to merchants or service providers.

Each request type is recorded and processed independently and may be subject to different operational procedures, compliance requirements, and settlement mechanisms as the system evolves.

***

### Deterministic Request IDs

The request ID is computed from the following ordered parameters:

| Parameter       | Description                               |
| --------------- | ----------------------------------------- |
| `address(this)` | The deployed OffRamp contract address     |
| `sender`        | Address initiating the request            |
| `amount`        | Amount of $USC locked for redemption      |
| `usc`           | Address of the $USC token contract        |
| `nonce`         | Per-user incrementing nonce               |
| `requestType`   | Enum value identifying OffRamp or Payment |
| `feeRate`       | Fee rate applied to this request (BPS)    |
| `block.chainid` | Chain identifier                          |

These values fully describe what the request is, who created it, where it exists, and how it is processed.

***

#### Hash Construction

The request ID is generated using the `keccak256` hash function over a tightly packed encoding of the parameters:

```
keccak256(
  abi.encodePacked(
    address(this),
    sender,
    amount,
    usc,
    nonce,
    requestType,
    feeRate,
    block.chainid
  )
)
```

This produces a fixed-size bytes32 identifier that is:

* Deterministic
* Order-sensitive
* Collision-resistant

Any modification to any single input will produce a completely different request ID.

### Rationale

The deterministic nature of request ID generation provides several operational and compliance advantages:

* Off-chain systems can deterministically derive and validate request identifiers prior to or independent of on-chain execution
* Indexing and monitoring services can independently verify the authenticity and integrity of emitted events
* Auditors can recompute request identifiers from historical on-chain data for verification and reconciliation purposes
* Integrators can validate request integrity without requiring additional contract calls

Collectively, these properties enhance system transparency, facilitate integration with external settlement and compliance infrastructure, and support robust auditability across the OffRamp lifecycle.

***

### Completing a Request

Once a request has been processed off-chain, an authorized operator can complete it.

There are two supported completion paths:

#### Treasury Transfer

$USC is transferred to an approved treasury address.\
This is typically used when funds need to be routed to external systems for further processing or settlement.

#### Token Burning

$USC is permanently removed from circulation.\
This is used when the redemption process requires reducing the total token supply.

After completion:

* The request status changes to **`Completed`**
* A completion event is emitted for transparency and auditability

***

### Cancelling a Request

Requests can be cancelled under the following rules:

* Users may cancel their own requests after a 14-day waiting period
* Authorized operators may cancel any request immediately

When a request is cancelled:

* The locked $USC is returned to the original user
* The request status is updated to **`Cancelled`**
* A cancellation event is emitted

The waiting period balances user protection with operational efficiency.

***

### Eligibility Requirements

Only verified accounts approved through the Colb Whitelist can create redemption requests, enabling KYC/AML compliance.

All sensitive operations are protected by strict role-based permissions.


---

# 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.colb.finance/payments-core-tech/interactive-blocks.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.