Skip to content
Tenzro
Documentation menu
Trust and provenance

Compliance

Residency for models, data and compute, compliance tiers built from trust credentials you choose, and Travel Rule data for payments.

Organisations in regulated industries need to know where a model runs, where their data goes, who they are dealing with, and be able to prove all of it afterwards. Tenzro Network 1 gives you these controls through signed, verifiable records instead of a central compliance registry. You decide which authorities, certification bodies and auditors you rely on; the network enforces your choices on every request and leaves evidence you can hand to an auditor.

Residency of models, data and compute

Where requests are served. Every operator publishes a signed operator policy that lists the jurisdictions it serves from. Your requests can be routed only to operators whose policy matches the countries or blocs you allow. The operator's node refuses requests outside its declared jurisdictions.

Proof of where it happened. Every response is covered by a receipt signed by the operator. It records hashes of the request and response, the model's manifest root, the jurisdiction the request was served from, and when it was signed. If an operator serves from outside its declared jurisdictions, the receipt is the evidence, and the breach is slashed from its bond.

Which model. Models are identified by a hash over every file, verified across independent origins and checked before loading. The receipt names that hash, so you can show exactly which weights produced an output. See Model provenance.

What happens to your data. An operator's policy declares how long it keeps request data and whether it ever trains on inputs. You can route only to operators that keep nothing and never train on inputs, and require an auditor's credential confirming that practice.

Confidential execution. For sensitive workloads, route to operators running inside Intel TDX, AMD SEV-SNP, AWS Nitro or NVIDIA confidential GPUs. Their attestation evidence is verified against each vendor's certificate chain and can be bound to the response. See TEE.

Data and storage. Data held by storage providers is covered by bonded SLAs, and databases are isolated per tenant. See Decentralised storage and Databases.

Licence territories. Some model licences exclude named territories. Operators serving such models check each request against the licence's territorial grant and refuse requests they cannot show are inside it, recording the decision.

Compliance tiers from trust credentials

A compliance tier is the set of credentials a counterparty must hold before you deal with it. On Network 1, tiers are built from trust credentials, not from a list someone maintains on your behalf.

  1. Choose the issuers you already rely on: your regulator, the certification bodies you accept, your auditors, a KYC provider.
  2. Put them in your trust list and state which credentials each tier requires. For example, a basic tier might require a verified-identity credential, and a higher tier an audited management-system certification plus a jurisdiction restriction.
  3. Apply the trust list to your requests. Routers use only models and operators that meet it, and your application can check a counterparty's credentials before paying it.

Because credentials expire and can be revoked by their issuer, a counterparty drops out of a tier as soon as its certification lapses or is withdrawn. Nobody else can change the rules on your list.

The same approach works for agents: an agent's identity is a DID derived from its device key, and the credentials attached to it tell you who controls it and who has vouched for it. See Identity.

Travel Rule data for payments

Transfers between virtual asset service providers above the applicable threshold must carry originator and beneficiary information under the FATF Travel Rule. Network 1 supports the IVMS101 data model for this.

An IVMS101 envelope holds four records, originator, beneficiary, originatingVasp and beneficiaryVasp, plus a transfer record with the asset as a CAIP-19 identifier, the amount in the asset's smallest unit, an ISO 8601 timestamp and the transaction hash. Field names follow the IVMS101 JSON form, so existing compliance tools read it without conversion.

Personal data never goes on chain. The full envelope travels between the two providers over their Travel Rule channel, and only a canonical SHA-256 hash of it, the two providers' DIDs and an asset and amount summary are bound to the payment receipt. An auditor can later check that a receipt was bound to a specific envelope at the time of payment.

Compute the canonical hash with the CLI:

bash
tenzro ivms101 hash --from-file envelope.json

or with the open JSON-RPC method, passing the full envelope as params:

bash
curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d @- <<'EOF'
{"jsonrpc":"2.0","id":1,"method":"tenzro_ivms101Hash","params":{ "...": "full IVMS101 envelope" }}
EOF

The result includes envelope_hash_hex, the spec version, both providers' DIDs and the amount.