> For the complete documentation index, see [llms.txt](https://jpydf.gitbook.io/jpy-defi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jpydf.gitbook.io/jpy-defi/collateral-and-pricing/dtoken.md).

# dToken

A **dToken** is the token the Core actually holds as collateral. It is an ERC-20 token (18 decimals) that records, at 1:1, the claim against the underlying asset a user deposited: depositing wstETH mints dwstETH, and depositing USDC mints dUSDC. The Core treats it as an ordinary collateral token, while each branch's Vault handles custody of the underlying asset, external deployment, decimal normalization, issuance caps, and in-kind redemption. Recording the claim at 1:1 does not guarantee full or immediate payout.

Follow each asset through its Vault and dToken, then the reverse path when withdrawing underlying assets.

![USDC and wstETH collateral paths, followed by dToken burning, buffer payout and withdrawal requests](https://2664012221-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fk6OsOkfOCs0PpKCrImRu%2Fuploads%2Fgit-blob-980e49cd9c9900bf4836a8dac6a5421087960675%2Fcollateral-path.png?alt=media)

## Why collateral is converted into dTokens

Converting collateral into dTokens lets JPY DeFi do the following while keeping its differences from the Liquity v2 Core small.

* Deploy part of the underlying asset into external venues ([Collateral Strategies](/jpy-defi/collateral-and-pricing/strategies.md)).
* Handle assets such as USDC (6 decimals) uniformly at 18 decimals.
* Limit the size of each branch with a total-supply cap (mint cap) per dToken. The mint cap limits the dToken; it does not directly limit JPYdf debt.

## Minting and in-kind redemption

* **Mint**: Deposit the underlying asset into the Vault and receive dTokens for the deposited amount. To borrow, you deposit these dTokens as collateral.
* **In-kind redemption**: Burn dTokens to withdraw the underlying asset.

In-kind redemption converts your own dTokens back into the underlying asset. It is a separate mechanism from [redemption](/jpy-defi/borrowing-and-trove-management/redemptions.md), which exchanges JPYdf for collateral from other Troves.

## Liquidity buffer and withdrawal requests

Because part of the underlying asset is deployed externally, not all of it is always in the Vault. The Vault keeps a share of the underlying asset for immediate withdrawals (the **liquidity buffer**).

* If the buffer covers an in-kind redemption, you receive the underlying asset immediately. The buffer is shared by all users and used in the order transactions succeed.
* If the buffer is insufficient, all of the specified dTokens are still burned. The Vault pays what it can from the current buffer and records the rest as a **withdrawal request**. The request belongs to the receiver's address and does not remain as a dToken balance.
* After the waiting period, the request owner can claim. A claim requires the full amount to be available in the buffer. Matured requests have no priority, so new in-kind redemptions can use the buffer first.
* The buffer is replenished by new deposits and by recoveries from venues. A withdrawal request does not automatically recover funds from a venue.

## Backing ratio

The **backing ratio** is the value of the underlying asset the Vault holds divided by the total dToken claims plus unpaid withdrawal requests, capped at 1.0. The value includes the Vault's balance and each venue's valuation, capped at principal. Normally it is 1.0.

* If a venue's valuation falls below principal and the Vault's total assets fall below total claims, the backing ratio falls below 1.0. Losses not visible in the valuation are reflected when the loss is confirmed. If a venue's valuation cannot be read and no recent record (up to one day old) is available, it is treated as a price failure.
* The backing ratio is multiplied into the collateral price ([How Prices Are Determined](/jpy-defi/collateral-and-pricing/oracle.md)), so an under-backed dToken is never valued as full collateral, and the effect carries into liquidation checks.
* While the backing ratio is below 1.0, dToken deposits, in-kind redemptions, and claims are not possible. They become available again when the backing ratio returns to 1.0. They can also stop while a venue's valuation cannot be read on the spot.
* A **backstop reserve** can be used to restore backing to 1.0. It is held separately and requires governance approval to be paid out, so it is not used on a first-come, first-served basis. Contributions to the reserve are not guaranteed.

Deposits, in-kind redemptions, and claims can also be paused by governance emergency powers or by emergency actions on a venue ([Governance & Timelock](/jpy-defi/governance/governance-and-timelock.md)).