User Guide
This guide explains how to use the four main Morpheus capabilities:
- Privacy Compute
- Privacy Oracle
- Datafeeds
- NeoDID
It also explains how to inspect supported built-in providers and feed pairs, and how to use the public NeoDID DID resolver.
Current architecture note:
- Cloudflare owns public ingress, control-plane routing, queue/workflow orchestration, and recovery.
- Supabase owns durable request, job, automation, and feed state.
- The Oracle CVM handles request/response oracle, compute, and NeoDID execution for both mainnet and testnet.
- The DataFeed CVM is isolated so continuous market-data publication is not blocked by interactive workloads.
Important production rule:
- End users should use Oracle and Compute through the on-chain Morpheus Oracle contracts plus callback fulfillment.
- End users should use NeoDID bind / action / recovery flows through the on-chain Morpheus Oracle contracts plus callback fulfillment.
- The direct HTTP routes in this guide are for local development, operator workflows, and payload debugging.
- sync is operator-only. User contracts read synchronized on-chain feed records directly.
- Each request currently costs -equivalent.
- Neo N3 supports prepaid fee credits, including contract-sponsored payment.
- Neo N3 is the only active supported runtime path right now.
- Neo X examples remain in-repo as reference material and should not be treated as the current production integration path.
Canonical Network Registry
Always treat these files as the source of truth before copying an address into a frontend, contract, or runbook:
Current Neo N3 anchors:
| Item | Mainnet | Testnet |
|---|---|---|
| Oracle Runtime URL | ||
| Oracle Attestation Explorer | ||
| DataFeed Attestation Explorer | ||
| MorpheusOracle | ||
| OracleCallbackConsumer | ||
| MorpheusDataFeed | ||
| AbstractAccount | ||
| AA Web3AuthVerifier | ||
| AA RecoveryVerifier | deployment-specific | |
| NeoDIDRegistry | unpublished | |
| Oracle NNS | unassigned | |
| DataFeed NNS | unassigned | |
| AA NNS | unassigned | |
| AA alias NNS | unassigned | |
| NeoDID NNS | unassigned |
Operational notes:
- the canonical testnet callback contract for shared infra is
- the current testnet example consumer used by live validation probes resolves to the same shared deployment
- testnet NeoDID registry remains unpublished in the shared registry until a stable shared deployment is intentionally promoted
- is the stable AA runtime name; raw deployment manifest suffixes are internal deployment metadata rather than user-facing contract names
- mainnet AA ecosystem contracts are also published under subdomains such as , , and
- now resolves to the same canonical mainnet AA address as ; treat it as an additional alias, not the primary public name
1. Concepts
Privacy Compute
Use Morpheus as an off-chain trusted coprocessor for expensive logic that is not practical on-chain.
Typical cases:
- ZKP preprocessing or witness hashing
- FHE planning and parameter estimation
- matrix / vector operations
- custom script execution in the TEE
Privacy Oracle
Use Morpheus when you need to fetch external data and optionally process it inside the TEE before returning a derived result.
Typical cases:
- fetch a private API using an encrypted secret
- run a script on sensitive API output
- return only a boolean / score / filtered result on-chain
Datafeeds
Use Morpheus datafeeds as operator-synchronized on-chain price storage that user contracts read directly.
Important properties:
- feed publication runs on the isolated DataFeed CVM
- all feed pairs are normalized to
- Morpheus does not aggregate or medianize providers
- each provider is stored independently on-chain as
- prices are stored as scaled USD integers with global precision
- threshold checks are evaluated against the quantized on-chain integer price, not unbounded source decimals
- example storage pairs:
NeoDID
Use NeoDID when you need privacy-preserving identity binding, unlinkable action authorization, or AA social recovery.
Important properties:
- production identity issuance still enters through the Oracle request + callback path
- the public DID resolver exposes service topology and verifier material, not private claims
- , JWT claims, master nullifiers, and action nullifiers remain private
- Web3Auth JWT verification happens inside the TEE for
- current public service DID is
2. Privacy Compute Usage
These direct
HTTP examples are for development and operator testing. In production, the same payloads should be carried through the on-chain request + callback path.Built-in functions
List built-ins:
Or call the worker directly:
Built-in examples:
Call through web API:
Custom script compute
Example:
Important notes:
- script execution is time-limited
- invalid entry points are rejected
- can fetch the script body from a Neo N3 contract getter when notification size is too small for inline source
- use built-ins whenever possible for stable semantics
Example registry-backed compute script:
Confidential compute payloads
If you want the function name, script, or inputs to stay encrypted until they reach the TEE, fetch the Oracle public key first and encrypt a JSON payload patch.
Example confidential builtin call:
The worker decrypts that JSON object inside the TEE, merges it into the request, executes it, and returns the callback-ready result envelope.
3. Privacy Oracle Usage
These direct
HTTP examples are also development/operator paths. End-user dApps should submit the payload through the Oracle contract and wait for the callback result.There are two main paths.
A. Built-in provider mode
Use a built-in provider such as
. Optional providers like and remain available for project-specific Oracle fetch flows, but production PriceFeed sync defaults to .Example:
Request via web API:
B. Custom URL mode
Use a custom URL with optional encrypted secrets and optional script.
Example:
Request via web API:
Important notes:
- is the cleanest choice when only an auth secret must stay private
- , , or a JSON-object can carry confidential headers, provider params, compute input, function names, or scripts
- if the encrypted blob is too large for the chain request payload, first store it through and then carry only / on-chain
- if the script body itself is too large for the request payload, move it into a Neo N3 contract getter and use
- Morpheus confidential payloads are sealed with
- the encrypted envelope includes an ephemeral X25519 public key plus AES-GCM ciphertext/tag fields
Oracle public key
To encrypt user secrets locally, fetch the Oracle public key first:
or directly from worker:
Returned fields:
Confidential store for large encrypted payloads
Use this route when a JWT or encrypted JSON patch is too large to fit directly into the Oracle request payload:
Response:
Then place only the short reference on-chain:
4. Datafeeds Usage
Query supported feed pairs
From web API:
From worker directly:
Current default pair catalog includes:
- Core crypto:
- Commodity / hard-asset:
- Equities / ETFs:
- FX:
- (inverted from )
- (inverted from )
With the global
scale, low-priced assets such as , , and can be represented directly without basket pair names.For the exact meaning of every canonical pair, including the real TwelveData source symbol and any inversion / scaling rule, read the canonical pair table in
.Canonical key note:
- use provider-scoped keys such as and in all new code
- the prefix is part of the official on-chain key, not just a display alias
Query current off-chain quotes
Single provider:
All available built-in providers for the pair:
This returns:
If multiple providers are requested, every successful quote is returned and every failed provider is listed in
. Production feed sync uses by default unless you explicitly override .Trigger an on-chain feed sync
This flow is operator-only. End users should not request
through the Oracle contract. If they do, the request is rejected and finalized with a failure callback.Web cron route:
Direct worker route:
Returned fields:
Each successful sync result contains:
On-chain storage model
For the active supported path, providers are stored and read on Neo N3.
Examples:
This means contracts can choose:
- one specific provider pair
- all stored pairs
- all feed records
- a price format that is always a 1e6-scaled USD integer, for example =
New on-chain DataFeed read methods
Neo N3
Neo X read methods are intentionally omitted here because Neo X is not part of the current production path.
5. NeoDID Usage
These direct
HTTP examples are development/operator paths. In production, the same payloads should be submitted on-chain through with:Resolve the public DID document
Resolve the service DID:
Resolve a document-only subject DID:
The public DID layer is for:
- service discovery
- verifier-key publication
- registry / Oracle / AA recovery endpoint hints
It is not for:
- provider UID disclosure
- JWT disclosure
- nullifier disclosure
- encrypted payload disclosure
Inspect runtime and provider catalog
The runtime response includes:
Direct bind example
Standard provider:
Web3Auth provider:
Large JWT production pattern
For large Web3Auth JWT payloads:
- fetch the Oracle public key
- seal the JSON patch locally with
- store the ciphertext through
- submit only on-chain inside the Oracle payload
Action ticket example
Recovery ticket example
Browser entrypoints
- live Web3Auth flow:
- interactive DID resolver:
- reference docs:
- formal DID method spec:
6. Mainnet Update Policy for Neo N3
For Neo N3 mainnet, automatic feed sync obeys two rules:
- the same price pair is updated only if the fresh quote moved by more than 0.1% versus the current on-chain stored value
- the same storage pair is updated at most once every 60 seconds
Precision caveat:
- because the chain stores quantized integers, a raw source move that is still too small to change the stored on-chain integer value cannot trigger an update, even if that raw source move is already greater than
- with the current scale, the standard catalog can use direct source-prefixed pairs such as and without basket naming
These rules apply per stored provider pair, for example:
So one provider can update while another provider is skipped.
7. Built-in Provider Support
Current built-in providers:
To inspect provider metadata:
or:
8. How to Add New Pairs Later
There are two levels.
Simple level: add symbols only
Set:
Example:
Advanced level: add provider-specific mapping
Set:
Example:
This is the correct place to add pairs whose provider symbols differ from the normalized
format.9. Practical Recommendations
- use when you need fetch + optional secret + optional compute
- use when you do not need an external fetch
- use for standardized public market data storage
- use for privacy-preserving identity binding, action authorization, and AA recovery
- for contracts, prefer provider-scoped storage pairs like
- if you need all currently stored feed pairs, use /
- use the public DID resolver only for service discovery and verifier material, not for private identity claims