> For the complete documentation index, see [llms.txt](https://docs.curiostorage.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.curiostorage.org/market-2.0/contracts/ddo-contract-review.md).

# DDO Contract Review and Allowlisting

This page is for storage providers reviewing DDO market contracts, and for builders deploying them for Market 2.0.

## What Curio Actually Checks

When a DDO deal includes `market_address`, Curio performs read-only verification before accepting the deal and again during upload finalization.

Current checks:

1. `market_address` must exist in `ddo_contracts` and be marked `allowed = true`.
2. `market_deal_id` must be present.
3. Curio calls `version()` and requires `1`, both before and after NV29.
4. Curio builds `ICurioDealViewV1.CurioDealView` from the local deal and calls `verifyDeal(...)` via `eth_call`.
5. `verifyDeal(...)` must return `true`.
6. If `verifyDeal(...)` reverts with `DealNotFound(uint256)`, Curio rejects the deal as market-missing.

What this does not mean:

1. This call only answers whether the contract accepts the proposed deal at intake or upload finalization.
2. It does not by itself prove payment, payout, callback success, or settlement behavior.
3. `AddMarketContract` only validates address syntax and that the address resolves to a Filecoin actor before inserting it into Curio policy state.
4. Curio does not inspect proxy admin, upgrade controls, ownership, or source verification for the contract.

## Provider Control States

Provider policy is separate from contract code compatibility.

Current states:

1. Added and allowed: new DDO deals can reference the contract.
2. Added but blocked (`allowed = false`): new DDO deals using that contract are rejected.
3. Removed: contract is no longer configured; new DDO deals using it are rejected.
4. Deals already in the processing pipeline continue if the contract is later blocked or removed. Deals awaiting upload finalization still recheck contract allowlisting and verification.
5. `GET /contracts` returns only allowed contracts.

These controls are managed through Curio operator tooling and UI.

## Provider Review Checklist

Before allowing a DDO market contract, providers should review:

1. Verified contract source and ABI from a source they trust.
2. The deployed address, preferably confirmed through a trusted builder channel.
3. `verifyDeal(...)` behavior, including validation of `providerActorId`, `clientId`, `pieceCidV2`, `startEpoch`, `duration`, the expected `state` / `finalizedEpoch` semantics, and acceptance of `allocationId = 0` from NV29 onward.
4. Notification-driven settlement or callback paths separately from the intake verification path.
5. Ownership, upgrade authority, and any governance or timelock around the contract if it is proxy-based or upgradeable.

Allocation note:

1. New deals and newly added DDO products must omit `allocation_id`.
2. Previously accepted deals retain their allocation data. Before NV29, Curio can resolve those allocations against either the deal client or the market contract address.
3. From NV29 onward, Curio always sends `allocationId = 0` to `verifyDeal(...)`, including when finalizing uploads for previously accepted deals. Contract verification must accept that value without requiring an allocation.

## Upgradeable Contract Risk

Curio does not distinguish immutable and upgradeable contracts during allowlisting.

Providers should treat upgradeable contracts as an ongoing trust decision:

1. Review who controls upgrades.
2. Review whether upgrades are gated by a timelock or multisig.
3. Re-review the contract when implementation or ownership changes.
4. Block or remove the contract if governance or implementation changes become unclear.

## Builder Guidance

Builders integrating a DDO market contract should:

1. Publish verified source and a reliable ABI reference.
2. Implement `CurioDealViewV1` exactly and return `version() == 1` across NV29. Keep the deprecated `allocationId` field in the ABI and support `0` from NV29 onward.
3. Keep `verifyDeal(...)` deterministic and read-only.
4. Validate the fields Curio sends rather than blindly accepting every call.
5. Use `DealNotFound(uint256)` for missing market deal identifiers.
6. Keep notification-driven callbacks efficient and document the expected failure behavior for providers if the contract depends on them.
7. Communicate upgrade process and governance model clearly if the contract is upgradeable.

## Related Pages

1. [CurioDealView v1 interface](/market-2.0/contracts/curiodealview.md)
2. [DDO product behavior](/market-2.0/products/ddo_v1.md)