> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Institutional treasuries

# Institutional Treasuries

Crypto treasuries, whether held by public companies, DAOs, foundations, or asset managers, face a recurring operational problem: proving to auditors, regulators, and stakeholders that a given on-chain address is owned and operated by the institution, and that every transfer is traceable to an authorized signer. Spreadsheets, internal wikis, and signed PDFs fall apart at audit time. Notareum gives treasuries a cryptographically anchored, machine-readable record: signed `.nota` files for every treasury address, receipts for every material transfer, and registry entries that auditors can query without asking the treasury team for a screenshot.

## What treasuries publish

A treasury publishes three classes of `.nota` file:

1. **Address `.nota`** for every treasury wallet (hot, warm, cold, multisig). Signed by the treasury admin key.
2. **Contract `.nota`** for any protocol treasury's deployed contracts (vaults, timelocks, multisig implementations).
3. **Receipt `.nota`** for each outgoing transfer above a policy threshold, signed by the authorized signer at transfer time.

Together they form a self-describing, continuously updated map of the treasury's on-chain footprint.

```mermaid theme={"system"}
flowchart LR
    Treasury[Treasury Entity] -->|signs| Map[Address Map .nota]
    Treasury -->|per transfer| Receipt[Transfer Receipt .nota]
    Map -->|registered| Registry[NotaRegistry]
    Receipt -->|distributed| Audit[Auditor / Regulator]
    Registry -->|queried| Audit
```

## Address registration

```typescript theme={"system"}
import { Notareum } from "@notareum/sdk";

const ntm = Notareum({ provider, signer: treasuryAdmin, contracts });

async function registerTreasuryAddress(opts: {
  address: string;
  chainId: number;
  label: string;
  custodyType: "multisig" | "hsm" | "mpc" | "cold";
  signersPolicy?: { threshold: number; total: number; signerRefs?: string[] };
}) {
  const nota = await ntm.nota
    .create({
      type: "address",
      chainId: opts.chainId,
      chainName: chainIdToName(opts.chainId),
      identifier: opts.address,
      name: opts.label,
      description: `Treasury wallet, custody=${opts.custodyType}`,
      resourceMetadata: {
        custodyType: opts.custodyType,
        signersPolicy: opts.signersPolicy,
        classification: "treasury",
        entity: "Acme Foundation",
        jurisdiction: "CH",
        registeredAt: Math.floor(Date.now() / 1000),
      },
      issuerName: "Acme Foundation Treasury",
      issuerEntityType: "organization",
      issuerDid: "did:web:treasury.acmefoundation.org",
    })
    .validate()
    .sign(treasuryAdmin);

  await ntm.registry.registerResource(nota);
  await ntm.verification.requestVerification(nota.resourceId(), {
    level: "institutional",
  });
  return nota;
}
```

Each address is verified at `INSTITUTIONAL` level, which triggers the 15-validator quorum and the strongest on-chain trust signal. Block explorers, auditors, and counterparties querying the registry see the address with a "Treasury, institutional-verified" badge.

## Signer transparency

A treasury that wants maximum transparency can publish the multisig signer set as part of the address `.nota`:

```json theme={"system"}
{
  "signersPolicy": {
    "threshold": 3,
    "total": 5,
    "signerRefs": [
      "notareum:resource:0xabc...",
      "notareum:resource:0xdef...",
      "notareum:resource:0x123...",
      "notareum:resource:0x456...",
      "notareum:resource:0x789..."
    ]
  }
}
```

Each `signerRefs` entry resolves to another registered `.nota` for the individual or sub-entity signer, forming a verifiable org chart. Revoking a signer's entry (e.g., on departure) is immediate and propagates.

## Transfer receipts

For each transfer above the treasury's policy threshold, the signing operator produces a receipt:

```typescript theme={"system"}
async function issueTransferReceipt(opts: {
  txHash: string;
  chainId: number;
  from: string;
  to: string;
  amount: string;
  token: string;
  purpose: string;
  approvalRef: string;
}) {
  const nota = await ntm.nota
    .create({
      type: "transaction",
      chainId: opts.chainId,
      chainName: chainIdToName(opts.chainId),
      identifier: opts.txHash,
      name: `Transfer: ${opts.purpose}`,
      resourceMetadata: {
        from: opts.from,
        to: opts.to,
        amount: opts.amount,
        token: opts.token,
        purpose: opts.purpose,
        approvalRef: opts.approvalRef,
        approvedAt: Math.floor(Date.now() / 1000),
      },
      issuerName: "Acme Foundation Treasury",
      issuerEntityType: "organization",
    })
    .sign(treasuryAdmin);

  await ntm.registry.registerResource(nota);
  return nota;
}
```

Receipts link:

* `from` and `to` to registered `.nota` addresses (both sides of the transfer contextualized).
* `approvalRef` to the governance proposal, board resolution, or ticket system entry authorizing the transfer.
* `purpose` to a free-text field with a controlled vocabulary (payroll, grant, investment, rebalance, operational).

## Audit queries

An auditor holding the treasury's public issuer DID can run a fully external query:

```typescript theme={"system"}
import { Notareum } from "@notareum/sdk";

const ntm = Notareum({ provider, contracts }); // no signer needed

async function auditPeriod(issuerDid: string, fromTs: number, toTs: number) {
  const issuer = await ntm.registry.getIssuerByDid(issuerDid);

  const addresses = await ntm.registry.listByIssuer(issuer.id, { type: "address" });
  const receipts = await ntm.registry.listByIssuer(issuer.id, {
    type: "transaction",
    signedAfter: fromTs,
    signedBefore: toTs,
  });

  const totalsByToken = new Map<string, bigint>();
  for (const r of receipts) {
    const { token, amount } = r.resourceMetadata;
    totalsByToken.set(token, (totalsByToken.get(token) ?? 0n) + BigInt(amount));
  }

  return { addresses, receipts, totalsByToken };
}
```

The auditor does not need the treasury to send anything: the on-chain record plus the off-chain receipt set is self-sufficient. The treasury does not need to produce a custom report: their day-to-day transfer discipline produces the audit trail as a byproduct.

## Governance approval linking

DAOs can tie receipts to governance proposals in both directions:

1. A governance proposal includes a receipt template (to, amount, token, purpose).
2. On execution, the treasury produces the receipt with `approvalRef = "snapshot:proposal:0xabc..."` or `approvalRef = "aragon:vote:42"`.
3. Indexers cross-reference proposal outcomes and actual transfers in real time.

Failures show up as missing receipts for executed transfers, not just missing votes.

## Cold-wallet attestations

Cold wallets rarely move. Periodic proof-of-reserves for cold wallets can be produced as signed `.nota` files without moving funds:

```typescript theme={"system"}
const pora = await ntm.nota
  .create({
    type: "attestation",
    chainId: 1,
    identifier: coldAddress,
    name: "Monthly cold wallet attestation",
    resourceMetadata: {
      attestationType: "balance_snapshot",
      snapshotBlock: 19832144,
      snapshotTimestamp: 1713571200,
      assets: [
        { token: "ETH", balance: "12500.0" },
        { token: "USDC", balance: "45000000.0" },
      ],
      challengeNonce: "0xa1b2c3...",
    },
  })
  .sign(coldWalletSigner);
```

The signature proves the cold key was live at snapshot time without exposing the wallet to an on-chain transfer.

## Operational controls

* **Key rotation.** When a signer rotates keys, revoke the old `.nota` and issue a new one. History remains queryable.
* **Segregation.** Separate `.nota` records for operational, strategic, and grant-specific pools make policy enforcement programmable.
* **Multi-jurisdiction.** Each entity (parent, subsidiary, grant recipient) publishes its own issuer `.nota`. Receipts cross-reference entities for audit and tax purposes.

## Integration patterns

* **Treasury dashboards** (Gnosis Safe, Squads, Utopia) import `.nota` records to render portfolio views.
* **Accounting software** (Cryptio, Bitwave, Integral) consumes receipts as tagged transaction records.
* **Regulators** run queries against the on-chain registry with the entity DID.
* **DAO treasuries** link proposal outcomes to receipts for end-to-end transparency.

## Related pages

* [Exchange Deposits](exchange-deposits.md)
* [Cross-Chain Identity](cross-chain-identity.md)
* [Payment Requests](payment-requests.md)
* [Verification Engine](../protocol/verification-engine.md)