> For the complete documentation index, see [llms.txt](https://city-protocol.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://city-protocol.gitbook.io/docs/platform/product-mechanics/tokenization-and-verification/oracle-attestations-and-api.md).

# Oracle, attestations and API

How each value update is verified before publication, what pauses when a check fails, the records behind each claim, the operating controls of the tokenization layer and its integration interfaces.

The oracle and verification workflow protects participants from stale, incorrect or manipulated product values. Every NAV update passes four checks before it is published, the attestation engine records the evidence behind each product claim, and partner platforms read both through the TaaS interfaces.

## Oracle and verification workflow

An update is published only after it clears four checks in order.

1. **Complete data:** Every input the valuation needs is present, from asset and position data and reserve and custody data to the service-provider reports for the valuation point.
2. **Verified inputs:** The data sources are validated, asset eligibility is checked, and the inputs carry the verifier confirmations the product requires.
3. **Deviation check:** The new value falls within the product's predefined deviation limits against the previous report. On Curated Vault rails, settlement rejects a price that moves beyond the vault's tolerance, which the pricing role sets at no more than 10,000 bps.
4. **Signer approval:** The required authorized signers approve the report under the configured quorum, and a vault can require several independent signers, for example a three-of-three quorum.

A value that clears all four is published onchain with its report hash and timestamp, and it feeds subscriptions, redemptions, integrations and reporting.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2Fq24GK8cOcEWh0XPljOrc%2Ffig-taas-oracle.png?alt=media" alt="A NAV update passes four checks in order, data complete, inputs verified, within limits and signers approve, to publication onchain and settlement; a failure at any check pauses new subscriptions, redemptions or both, followed by review and a new update"><figcaption><p>The oracle and verification workflow. Each failure pauses the product until review resolves the cause and a new update clears every check.</p></figcaption></figure>

### What triggers a pause

A product pauses when an update meets any of four conditions:

* the value falls outside the predefined deviation limits;
* the update fails verification;
* the report lacks the required signer approval;
* the update uses incomplete data.

### What pauses

The product pauses new subscriptions, redemptions or both, as its emergency controls specify. On Curated Vault rails, a pause never reaches an epoch that has already settled: no later NAV report, fee change or strategy event alters the Receipt Tokens minted or the settlement assets owed for that epoch.

### Resolution

Each pause is followed by a review that finds and resolves the cause, whether missing data, an unverified input, a deviation or a missing approval. The pause holds until a new update clears every check. On Curated Vault rails, pause and unpause are separate roles, so emergency response is fast and resumption requires review.

## Attestation records

Each attestation connects a product claim to a verifiable record. The record names the claim and the verifier, fixes the evidence through the hash of the underlying report, and carries the verification timestamp, the verification interval for recurring claims and the verification output, so an integrator can check what was verified, by whom and when.

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FeGjV4g5QhwJIJGM66i9O%2Ffig-taas-attestation.png?alt=media" alt="Claims about reserves, deployment, NAV reports, collateralization and settlement are checked offchain by a verifier, which passes only the verification output into an attestation record of claim, verifier, report hash, timestamp, verification interval and output, read by integrators, Venzo and partner applications, and monitoring and audit"><figcaption><p>From claim to attestation record. The verifier reads the full data set offchain, and only the verification output enters the record that integrators and applications read.</p></figcaption></figure>

* **Who produces them:** City Protocol, third-party verifiers, custodians, administrators, auditors or monitoring partners, depending on the product.
* **What they cover:** Proof of reserves, proof of deployment, NAV report hashes, reserve account confirmations, service-provider confirmations, collateralization levels, custodian reports, audit references, strategy exposure reports and settlement records, each with its verification interval and timestamp. Each kind is defined in [Tokenization architecture](/docs/platform/product-mechanics/tokenization-and-verification/tokenization-architecture.md).
* **Who reads them:** Integrators read them through the Attestation API; Venzo and partner applications show each product's verification status in its distribution metadata; and monitoring partners and auditors read the history of records.
* **What stays private:** Where a claim rests on account data, counterparty exposure or trading strategy details, the verifier checks the full data set offchain, and the attestation publishes only the verification output.

A master proof-of-solvency dashboard from an independent provider lets anyone verify Curated Vault TVL in real time, and product-level dashboards cover individual vaults. Both are listed on the [Audits](/docs/security/security-and-risk/audits.md) page.

## Security and operating controls

TaaS runs eleven operational security controls at the tokenization layer.

* **Independent smart contract audits:** Zenith has audited City Protocol's components, Tokenization as a Service among them, and the reports are published on the [Audits](/docs/security/security-and-risk/audits.md) page.
* **MPC custody or approved custody workflows:** The assets behind a tokenized product are held in MPC custody, where the signing key is split into shares held by separate parties, or in a custody workflow approved for the product.
* **Threat monitoring:** Role, oracle, NAV, settlement, pause and fee changes emit indexed events for monitoring, and suspicious transaction patterns trigger circuit breakers.
* **Subscription and redemption pausing:** A product pauses new subscriptions, redemptions or both when an update fails its checks or an emergency control triggers.
* **Access-control reviews:** Each deployment is checked before launch for role transfer, oracle quorum and deviation tolerance, and every later role change emits an event for review.
* **Role-based permissions:** Each privileged function is assigned by role, and reporting, pricing, access policy, pause and unpause are separate roles.
* **Oracle deviation checks:** Each new NAV is compared with the previous report, and a value beyond the product's deviation threshold pauses the product for review.
* **Co-signer systems:** Where a product requires co-signers, authorized signers approve each NAV report under a quorum, such as the three-of-three quorum a vault can require.
* **Service-provider verification:** Custodians, administrators and other service providers confirm their data, and each confirmation is recorded as an attestation.
* **Collateralization monitoring:** Collateral coverage is tracked against the product's minimum collateralization ratio, and coverage below the minimum triggers circuit breakers.
* **Product-level status flags:** Each product carries a status that every distribution channel reads, so a paused, impaired or ineligible product shows its state wherever it is listed.

Tokenization widens a product's distribution surface, and the control framework grows with it, so tokenized yield products stay safe to operate at scale.

## API and SDK surface

TaaS is integrated through APIs and SDKs, and its integration surface consists of seven interfaces.

| Interface                | Purpose                                                                                                                       |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| Product registry API     | Fetch product metadata, supported networks, token addresses, risk labels, capacity, fees and redemption terms                 |
| Investor eligibility API | Check whether a wallet or user is eligible to subscribe, hold, transfer or redeem                                             |
| Subscription API         | Route deposits, create subscription records and issue tokens or vault shares                                                  |
| Redemption API           | Submit redemption requests, check their status and claim settlement assets                                                    |
| Oracle API               | Retrieve the latest NAV, historical NAV, update time, signer status and deviation status                                      |
| Attestation API          | Retrieve reserve proofs, report hashes, verification timestamps, collateralization records and service-provider confirmations |
| Webhooks                 | Notify integrators of NAV updates, product status changes, permission changes, subscription events and redemption events      |

<figure><img src="https://3297077862-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJxNp2waFk6hg1G4lEQZu%2Fuploads%2FYTvelmQFRznapt7rbOUf%2Ffig-taas-api.png?alt=media" alt="An integration partner calls six TaaS interfaces, product registry, investor eligibility, subscription, redemption, oracle and attestation, which front the TaaS layer, and receives events from the layer through webhooks"><figcaption><p>The TaaS integration surface. The partner's backend calls six interfaces, and webhooks push NAV, status, permission, subscription and redemption events back.</p></figcaption></figure>

Through these interfaces, a partner platform lists, distributes and services tokenized yield products while City Protocol runs the issuance, oracle, eligibility, verification and lifecycle operations behind them, so the partner integrates the products without managing the full operational stack. The City Protocol SDK recommends a backend-first integration: the partner's backend holds the credentials, calls the interfaces and processes webhook events, and its frontend renders the results. The published TypeScript clients, including `CityClient` for vault interactions and `CityPortfolioClient` for indexed portfolio data, are documented in [City Protocol SDK](/docs/developers/city-protocol-sdk.md).