> For the complete documentation index, see [llms.txt](https://docs.tapir.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tapir.money/protocol-mechanics/tapir-mechanics/oracle-resolution/ptrw-oracle.md).

# PTRW Oracle

PTRW stands for **PT Redemption Witness**. It extends the [base oracle](/protocol-mechanics/tapir-mechanics/oracle-resolution.md) for Pendle Principal Token markets by redeeming a witness amount after PT expiry and comparing the expected and actual redemption values.

The witness checks the configured redemption route. The inherited price feeds separately track the reference asset. A PT trading at a discount before expiry does not, by itself, trigger this witness adjustment.

## Funding the witness

An external actor transfers PT to the oracle contract. The constructor does not acquire PT, enforce pre-expiry funding, or prevent market creation if funding fails. Funding an adequate witness before maturity is an operational responsibility.

At redemption, the oracle uses its **entire PT balance** as the expected redemption value (`ptrwErv`). It calls Pendle's `redeemPyToToken` route with the configured base token as both output and SY redemption token, without an external aggregator swap.

The actual redemption value (`ptrwArv`) is the router's returned `netTokenOut`. The oracle transfers its resulting base-token balance to the calling operator as a tip. It therefore depends on the configured Pendle route and its reporting; it is not an independent guarantee of underlying solvency.

The expected 1:1 relationship must be meaningful in the configured token units. The contract compares raw ERV and ARV amounts without decimal normalization between those two tokens.

## Who can resolve?

`resolvePtrw()` requires `OPERATOR_ROLE`, an unpaused oracle, a non-zero PT balance, and confirmation from the PT that it has expired.

A successful non-zero redemption records the witness values and enables price submission. The automated function has no `ptrwResolved` entry guard: a later operator call with newly supplied PT can overwrite witness values. Final **pool** settlement is still irreversible.

## Closing-price adjustment

The immutable `errorTolerance` is an **absolute amount**, expressed in the witness's comparison units. A 1% tolerance is an illustrative configuration, not a fixed percentage enforced by the contract.

```
factorBp = min(10,000, floor((ARV + tolerance) × 10,000 / ERV))
adjusted closing price = floor(normal closing price × factorBp / 10,000)
HWM = unchanged
```

If `ARV + tolerance >= ERV`, the closing price is unchanged. Otherwise, the factor reduces it. The operator must resolve PTRW before calling `writePriceData`; the pool then applies its ordinary cooldown, price-age, threshold, and payout rules.

## Worked examples

Assume ERV is `1.00`, tolerance is `0.01`, and the base oracle's HWM and closing price are both `1.00`:

| ARV   | Factor       | Adjusted closing | Outcome              |
| ----- | ------------ | ---------------- | -------------------- |
| 0.992 | 1.00, capped | 1.00             | No witness shortfall |
| 0.970 | 0.98         | 0.98             | 2% pool depeg        |

If the base oracle's closing price has also fallen, the witness factor compounds that decline. Conversely, a reduced witness factor does not alone guarantee a depeg: the pool compares the final adjusted closing price against its HWM and threshold.

## Zero output, reverts, and manual backup

If redemption **returns zero**, the transaction sets `forceManualResolve` and emits `MustResolveManually`. An admin can then supply non-zero ERV and an ARV explicitly after PT expiry.

If redemption **reverts**, the whole transaction rolls back, including any state updates. A revert does not set the manual-resolution flag or prove a specific loss; integration problems or a temporarily unavailable route can also cause failure.

Without `forceManualResolve`, the admin backup requires that PTRW is unresolved and that the oracle holds **no PT**. A reverting redemption with PT still held can therefore leave that backup unavailable until the issue is addressed. The admin can also reset `forceManualResolve`.

These are role-controlled recovery mechanisms, not a permissionless dispute process. See [Source Code & Contracts](/resources/source-code-and-contracts.md) for the contract references.

## Limits of the witness

* It samples one configured redemption route after expiry and depends on correct route configuration and reporting.
* It does not continuously track PT market discounts or ensure that a small witness represents every holder's executable redemption.
* Shortfalls within the configured tolerance are absorbed.
* Settlement also depends on base-oracle observations and operator submission.

For vault-share markets, the [VRP Oracle](/protocol-mechanics/tapir-mechanics/oracle-resolution/vrp-oracle.md) uses recurring vault previews and adjusts both final prices instead.