> For the complete documentation index, see [llms.txt](https://bluprynt.gitbook.io/bluprynt-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bluprynt.gitbook.io/bluprynt-docs/credentials/credentials-overview.md). # Credentials Overview Overview of Bluprynt's credential framework for asset-level verification. ## The Credential Framework Bluprynt's credential framework provides asset-level verification for tokenized finance. Each credential answers a specific compliance question that institutions, regulators, and smart contracts need resolved before engaging with a digital asset. ### Why Asset-Level Credentials Matter Most compliance infrastructure in crypto operates at the **infrastructure level** — KYC on wallet holders, transaction monitoring on transfers, sanctions screening on addresses. These are necessary but insufficient. Regulators and institutional investors increasingly need compliance at the **asset level**: verifiable proof that a specific token meets specific requirements. Not just "is this wallet clean?" but "is this asset properly collateralized?", "does the issuer have adequate insurance?", and "has the smart contract been independently audited?" Bluprynt's credentials fill this gap. They're issued onchain, linked to the issuer's verified identity via KYI, and queryable by smart contracts through the Compliance Hub — making compliance programmable rather than manual. ### Bluprynt's Credentials | Credential | What It Verifies | Key Stakeholders | | -------------------------- | --------------------------------------------------------- | --------------------------------- | | **Know Your Issuer (KYI)** | Entity identity, wallet ownership, mint authority | Exchanges, explorers, wallets | | **Proof of Collateral** | Asset backing, reserve verification, collateral structure | Investors, custodians, regulators | Each credential type maps to a specific scope, or set of scopes, in Bluprynt's taxonomy, ensuring that the underlying data is structured, comparable, and reusable across forms and jurisdictions. ### How Credentials Work #### Issuance Credentials are issued when an asset issuer completes the required verification process for that credential type. The process varies by credential: * **KYI** requires KYB verification, wallet challenge, and token contract linking — handled directly on the Bluprynt platform. * **Proof of Collateral** requires disclosure of collateral structure, valuation methodology, and reserve composition — submitted via Smart Disclosures and reviewed by Bluprynt or an approved verifier. * **Proof of Insurance** requires documentation of coverage details from an approved underwriter — currently facilitated through the Proof of Integrity partner ecosystem. * **Proof of Integrity** is a composite credential that combines independent assessments from specialized partners across security auditing, risk monitoring, and insurance coverage. #### Onchain Registration Once issued, each credential is: 1. **Published to IPFS** — the full credential metadata is stored as content-addressed data 2. **Registered onchain** — an attestation referencing the credential is published to the asset's blockchain network (EVM via EAS, Solana via SAS) 3. **Linked to the issuer's identity** — the credential is associated with the issuer's CCID, DID, and ONCHAINID 4. **Queryable via the Bluprynt Registry** — accessible through the API and by smart contracts #### Enforcement Credentials become enforceable when integrated with Bluprynt's Compliance Hub. A policy module can require specific credentials before allowing token actions: ``` Policy: "EU MiCA Stablecoin Compliance" ├── Required: KYI attestation (active) ├── Required: Proof of Collateral (active, < 90 days old) ├── Required: Regulatory attestation — MiCA white paper (approved) └── Action: Allow mint, transfer, burn └── If any credential missing/expired → revert transaction ``` This means compliance is continuously enforced — not just checked once at listing time. If a credential expires or is revoked, the associated token actions are automatically gated until the credential is renewed. #### Lifecycle **Active** → The credential is valid, onchain, and queryable. Smart contracts can verify it and allow gated actions. **Expiring** → The credential is approaching its expiration date. The issuer receives notifications to renew. The system can be configured to flag expiring credentials to relevant stakeholders, including exchanges and regulators. **Expired** → The credential has passed its expiration date. Compliance Hub enforcement kicks in — gated actions are blocked until renewal. **Revoked** → The credential has been explicitly revoked, for example due to a failed audit, regulatory action, or issuer request. Revocation is immediate and onchain. *** ### Credentials vs. Attestations This distinction matters: **Attestations** record facts. They say "this disclosure was submitted," "this white paper was approved," or "this audit was completed." Attestations are informational — they don't grant or restrict permissions. **Credentials** authorize actions. They say "this issuer is verified to mint tokens," "this asset's collateral has been confirmed," or "this infrastructure has passed security review." Credentials are checked by the Compliance Hub before allowing onchain actions. In practice, credentials are *built from* attestations. When an issuer submits a Proof of Collateral disclosure, which produces an attestation, and that disclosure is reviewed and approved, a Proof of Collateral credential is issued. The attestation is the evidence; the credential is the permission. *** ### Complementary, Not Competing Bluprynt's credentials are designed to complement existing infrastructure-level security solutions, not replace them. A custody platform like Fireblocks secures the keys and transaction signing. Bluprynt's credentials verify the compliance status of the *assets* those keys control. This creates a layered approach: * **Infrastructure layer** — wallet security, key management, transaction monitoring, provided by custody and security platforms * **Asset layer** — issuer verification, disclosure compliance, collateral verification, insurance coverage, and security audits, provided by Bluprynt credentials Together, these layers give institutions the full picture they need for regulated participation in tokenized markets. *** ### Get Started * [Know Your Issuer (KYI)](/bluprynt-docs/kyi-know-your-issuer/what-is-kyi.md) — Free for all qualifying assets * [Proof of Collateral](/bluprynt-docs/overview/core-products.md#proof-of-collateral) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bluprynt.gitbook.io/bluprynt-docs/credentials/credentials-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.