FAQ

Why does publishing need a remote store?

Because v2 does not write the DDO on chain. It signs the document as a verifiable credential, has the node encrypt it, stores it off chain, and writes only an encrypted { remote: … } pointer that ocean-node dereferences. Without somewhere to put the document there is nothing to point at, so publish throws.

Use IpfsRemoteStore with a Kubo node or a pinning service such as Pinata, or S3RemoteStore with an S3-compatible bucket. The node's own storage (NodePersistentRemoteStore) cannot hold DDOs on ocean-node 4.2, so nautilus rejects it. See remote stores.

My asset is on chain, but getAsset says "DDO not found"

The transactions succeeded, but the node could not index the asset. It does not say so on chain; it records a failure in its indexing state, under the transaction:

curl "https://<your-node>/api/aquarius/state/ddo?txId=<setMetadata tx hash, lower-case>"

?nft=<nftAddress> finds failures too, but a later success does not remove them, so it can return an old error from an earlier transaction. A success is filed under the DID instead (?did=did:ope:…). From nautilus, use getIndexingState. With waitForIndexer, nautilus reads it for you and throws an IndexingError with the node's message. Typical causes: the node cannot fetch the remote store's content through its gateway, the node is not an OceanProtocolEnterprise ocean-node 4.2.x, the publisher key is the node's own (decrypt then fails with 401; nautilus warns about it), or two metadata transactions for the asset landed in one block (nautilus then throws a MetadataConflictError).

Can I publish without encryption?

No. Since 2.0.0-beta.1 nautilus is encrypted only: the stored envelope and the on-chain pointer are always node-encrypted (flags 0x02), and encrypt: false throws. The DDO is never written on chain.

Where did the subgraph go?

Gone, along with the urql and graphql dependencies. Config has no subgraphUri at all any more. Prices are derived from contract reads plus the indexed indexedMetadata.stats[].prices, exactly as ocean.js does it.

v1's getAccessDetails and AccessDetails are replaced by getPricingInfo and getOrderPrice. See pricing.

Why is my gated asset letting everyone through?

Check whether the node has a policy server (POLICY_SERVER_URL). Without one, ocean-node checks address and access lists itself, and does not know an SSIpolicy entry: with match_allow: 'any', another entry that matches lets the consumer through without the credentials the SSIpolicy asks for. (Under the default match_allow: 'all' the unknown entry denies everyone instead.)

initializePolicyVerification returning null, or hasPolicyServer() answering false, says the node has no policy server. This is a deployment property, not something nautilus can compensate for.

Why am I paying twice for the same asset?

access reuses your previous order while it is inside the service's timeout. ocean-node 3.0 to 4.2 report no validOrder from the access initialize, so nautilus finds the order in the datatoken's events instead, reading back no further than the timeout and at most 100 000 blocks. An order past its timeout, or one placed by another account or for another service, means a new order. reusedOrder in the result says which happened. A lookup the RPC refuses, or one that cannot read back over the whole timeout, does not buy a service that costs anything: access() throws an OrderCheckError before paying, unless you pass orderOnLookupFailure: true.

compute orders each input on every job. See Do you already hold an order?.

Never put 127.0.0.1 in a DDO

ocean-node's DEFAULT_UNSAFE_URLS blocks any URL matching it, and the failure surfaces as "URL is marked as unsafe" rather than a connection error — which sends people looking in the wrong place entirely.

Use a hostname the node can resolve. Remember that you never fetch these URLs; the node does, to encrypt the files object at publish time.

Free compute vs. paid compute

freeCompute places no order, funds no escrow and takes no payment token. It needs a compute environment that exposes free resources — if none does, the call fails and there is nothing to configure your way out of.

compute orders every input, locks funds in the chain's escrow contract (its EnterpriseEscrow by default) from what the node quotes, and then starts the job.

Why does build() reject my asset?

DDO v5 requires providedBy, which had no v4 equivalent, so assets ported from v1 fail on a field that did not used to exist. build() also requires name, type, and at least one service — and container metadata when type is 'algorithm'.

Everything beyond that is checked by validate, which publish() runs automatically before spending any gas.

Do I still need separate Aquarius and Provider URLs?

No. One ocean-node serves metadata, provider services and the indexer, so metadataCacheUri and providerUri both collapse into a single oceanNodeUri. See migrating from v1.