> For the complete documentation index, see [llms.txt](https://polarischain-1.gitbook.io/polarischain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://polarischain-1.gitbook.io/polarischain/9.-native-compliance-framework-erc-3643/9.7-transparency-privacy-and-honest-limitations.md).

# 9.7 - Transparency, Privacy & Honest Limitations

Polarischain’s compliance framework is engineered for **regulatory transparency at the protocol level**. Every transaction is visible to validators, regulator nodes, and public explorers. This is intentional: native ERC-3643 enforcement depends on universal verification, not selective disclosure. This design carries explicit privacy trade-offs that operators and users must understand.

**On-Chain Visibility**

* Sender/receiver public keys & addresses
* Transaction amounts, types, timestamps, and DAG ordering
* NAA ownership history & transfer chains
* Identity registry mappings (address ↔ identity ID ↔ country code)
* Compliance claim metadata (active topics, issuing authorities, expiry dates)

**Off-Chain Confidentiality**

* PII documents (passports, corporate registration, KYC files)
* Verification data underlying claim attestations
* Only `BLAKE2b` hashes of verification data are persisted on-chain

**Recognized Privacy Limitations**

1. **Claim Metadata Leakage:** A wallet holding a US-jurisdiction or accredited-investor claim reveals that attribute publicly, even without exposing underlying documents.
2. **Transaction-Graph Traceability:** Public-key reuse enables standard chain-analysis techniques. Once a key is linked to a real-world identity, historical activity becomes attributable.
3. **Pseudonymity ≠ Anonymity:** Like Bitcoin and Ethereum, Polarischain is pseudonymous. Privacy degrades proportionally with regulatory interaction frequency.

**Operational Mitigations**

Users requiring enhanced operational privacy can deploy these patterns within the existing protocol:

* **Address Rotation:** Generate per-counterparty Dilithium keypairs; wallet UX should automate key cycling for retail users.
* **Multi-Signature Custody:** Corporate treasuries use multi-sig addresses that decouple transaction execution from individual identity.
* **Selective Claim Issuance:** Request only asset-required topics (e.g., sanctions screening only) rather than universal identity attestations.
* **Wallet Compartmentalization:** Isolate regulated assets in dedicated wallets to prevent claim-metadata cross-contamination with general-purpose activity.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://polarischain-1.gitbook.io/polarischain/9.-native-compliance-framework-erc-3643/9.7-transparency-privacy-and-honest-limitations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.