diff --git a/clear-signing.mediawiki b/clear-signing.mediawiki
new file mode 100644
index 0000000..b408587
--- /dev/null
+++ b/clear-signing.mediawiki
@@ -0,0 +1,812 @@
+<pre>
+ELIP: TBD
+Layer: Wallet
+Title: Clear Signing for Liquid
+Author: TBD
+Comments-Summary: No comments yet.
+Comments-URI: TBD
+Status: Draft
+Type: Standards Track
+Created: 2026-06-09
+License: BSD-3-Clause
+</pre>
+
+==Abstract==
+
+This document defines a structured metadata profile for wallets to interpret an Elements transaction for the user.
+It helps users understand the consequences of signing a particular transaction and lowers the risk of blind signing
+as much as possible.
+
+It does not specify how this metadata is verified or made trusted.
+
+==Copyright==
+
+This document is licensed under the 3-clause BSD license.
+
+==Motivation==
+
+To expand the Liquid ecosystem, infrastructure and user-facing applications should be able to explain
+to a non-technical user what is happening and which outcomes to expect. Similar to banking systems,
+users should be given as much security as possible by default.
+
+Therefore, ecosystem participants should make as much effort as possible in explaining actions to the user.
+
+This profile presents a way to interpret a general-purpose action of signing a transaction on the Liquid network to the user.
+
+==Specification==
+
+The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [https://www.rfc-editor.org/rfc/rfc2119 RFC 2119].
+
+==Scope==
+
+This document is scoped to regular Liquid transfers, asset issuance/re-issuance, asset burn, and Simplicity covenant spends.
+
+Actions that are supported by the consensus but out of scope:
+# Non-Simplicity Taproot script-path spends.
+# Bitcoin Script and Miniscript covenant interpretation outside the regular cases above
+
+This document does not specify the final shape of wallet views.
+It specifies what information should be available to the wallet and what information should be included
+in the metadata documents used for clear signing.
+
+==General==
+
+This document defines a set of metadata documents that provide enough information for the wallet to explain user the
+transaction that is being signed.
+
+<!-- TODO: complete this section with the progress of the reference implementation -->
+
+==Account and Chain Binding==
+
+Every metadata document MUST be bound to the active Liquid or Elements chain.
+
+<pre>
+chain_id = "bip122:" + first_32_lowercase_hex_characters_of_genesis_block_hash
+</pre>
+
+Liquid mainnet uses:
+
+<pre>
+bip122:1466275836220db2944ca059a3a10ef6
+</pre>
+
+Liquid testnet uses:
+
+<pre>
+bip122:a771da8e52ee6ad581ed1e9a99825e5b
+</pre>
+
+Liquid asset identifiers MUST use the [https://github.com/ElementsProject/ELIPs/blob/main/elip-0144.mediawiki ELIP-0144] asset ID form:
+
+<pre>
+asset_id = chain_id + "/" + asset_namespace + ":" + asset_reference
+asset_namespace = "elip144"
+asset_reference = 64 lowercase hex characters
+</pre>
+
+The Liquid mainnet policy asset ID is:
+
+<pre>
+bip122:1466275836220db2944ca059a3a10ef6/elip144:6f0279e9ed041c3d710a9f57d0c02928416460c4b722ae3457a11eec381c526d
+</pre>
+
+A wallet MUST verify that every field containing chain information refers to the wallet’s currently active chain.
+
+==Metadata Document Model==
+
+Each imported metadata object is a standalone document.
+A user imports an account metadata document, an asset metadata document, an action metadata document, or a covenant metadata document.
+
+A clear-signing request MAY reference standalone documents by hash, by local identifier, by registry identifier, or by embedding the document directly. This document does not specify the transport mechanism for metadata documents.
+
+Each metadata document MUST contain:
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>$schema</code>
+| String
+| Yes
+| The JSON Schema URI for this document type.
+|-
+| <code>kind</code>
+| String
+| Yes
+| The metadata document kind.
+|-
+| <code>version</code>
+| Integer
+| Yes
+| The version of the document kind.
+|-
+| <code>context</code>
+| Object
+| Yes
+| The constraints that MUST match before the document is used.
+|-
+| <code>metadata</code>
+| Object
+| Yes
+| Trusted constants values that are usable after context matching.
+|-
+| <code>display</code>
+| Object
+| Yes
+| User-facing labels, intent strings, detail labels, and formatting rules.
+|}
+
+A wallet MUST verify the <code>context</code> before applying <code>metadata</code> or <code>display</code>.
+
+A wallet MUST NOT use metadata as the source of truth for the final transaction shape. A wallet MUST compute final transaction shape from the transaction, PSET, wallet state, and wallet policy.
+
+A metadata document MAY contain a <code>documentId</code> field. If present, <code>documentId</code> MUST be a hash of the canonical document bytes or a registry identifier bound to that hash.
+
+==Clear-Signing Review Layers==
+
+A wallet SHOULD review a clear-signing request in layers:
+
+
+# Summary layer.
+# Net balance layer.
+# Account details layer.
+# Asset details layer.
+# Action details layer.
+# Amount details layer.
+# Simplicity covenant details layer.
+# Raw fallback layer.
+
+The summary layer SHOULD be short and user-facing.
+
+The net balance layer MUST be wallet-computed and grouped per asset.
+
+The account details layer MUST show the full account identifier based on [https://github.com/ElementsProject/ELIPs/blob/main/elip-0144.mediawiki ELIP-0144].
+
+The asset details layer MUST show the full asset ID.
+
+The action details layer MUST show the action being performed and the source of the action match.
+
+The amount details layer MUST show the base-unit amount and the formatted display amount when asset precision is available.
+
+The Simplicity covenant details layer MUST show the covenant metadata document and the matched action.
+
+The raw fallback layer SHOULD show the raw account, asset, action, and covenant binding values when the wallet cannot safely shorten or explain them.
+
+==Account Metadata Document==
+
+An account metadata document binds an [https://github.com/ElementsProject/ELIPs/blob/main/elip-0144.mediawiki ELIP-0144] account ID to a user-facing alias.
+
+The detailed account view MUST show the full account ID. The detailed account view MUST NOT shorten the account ID itself.
+
+If possible, a wallet SHOULD use an alias. If there is no alias, the wallet SHOULD make its best effort to point the user to the full account form so the user can verify it.
+
+A wallet MAY abbreviate an account in the summary layer only if the full account ID is available in the detailed view.
+
+===Account Metadata Fields===
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>kind</code>
+| String
+| Yes
+| MUST be <code>liquid.accountMetadata</code>.
+|-
+| <code>context.chainId</code>
+| String
+| Yes
+| The active Liquid or Elements chain ID.
+|-
+| <code>context.account</code>
+| String
+| Yes
+| The full account ID.
+|-
+| <code>metadata.alias</code>
+| String
+| No
+| The account alias.
+|-
+| <code>metadata.description</code>
+| String
+| No
+| A human-readable description of the account.
+|-
+| <code>metadata.owner</code>
+| String
+| No
+| A human-readable owner label.
+|-
+| <code>metadata.infoUrl</code>
+| String
+| No
+| A URL with more information.
+|-
+| <code>display.summaryLabel</code>
+| String
+| No
+| A short label for summary views.
+|-
+| <code>display.detailFields</code>
+| Array
+| No
+| A list of detailed fields to display.
+|}
+
+===Account Metadata Example===
+
+<pre>
+{
+  "$schema": "https://example.invalid/liquid-clear-signing/account-metadata-v0.schema.json",
+  "kind": "liquid.accountMetadata",
+  "version": 0,
+  "context": {
+    "chainId": "bip122:1466275836220db2944ca059a3a10ef6",
+    "account": "bip122:1466275836220db2944ca059a3a10ef6:b781-7bc7-db64-c3de-3937-7eb7-c9ab-f799"
+  },
+  "metadata": {
+    "alias": "Alice",
+    "description": "Receiver account"
+  },
+  "display": {
+    "summaryLabel": "Alice",
+    "detailFields": [
+      { "label": "Account", "path": "$.context.account" },
+      { "label": "Alias", "path": "$.metadata.alias" }
+    ]
+  }
+}
+</pre>
+
+==Asset Metadata Document==
+
+An asset metadata document binds an [https://github.com/ElementsProject/ELIPs/blob/main/elip-0144.mediawiki ELIP-0144] asset ID to asset metadata.
+
+The detailed asset view MUST show the full asset ID. If an asset alias, ticker, or name is unavailable, the wallet MUST fall back to displaying the full asset ID.
+
+The wallet MUST validate that the asset metadata document refers to the active chain.
+
+The asset metadata document SHOULD be compatible with the existing Liquid asset contract shape used by the Liquid asset registry and [https://github.com/ElementsProject/ELIPs/blob/main/elip-0100.mediawiki ELIP-0100], including <code>entity.domain</code>, <code>issuer_pubkey</code>, <code>name</code>, <code>precision</code>, <code>ticker</code>, and <code>version</code> when those fields are available.
+
+===Asset Metadata Fields===
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>kind</code>
+| String
+| Yes
+| MUST be <code>liquid.assetMetadata</code>.
+|-
+| <code>context.chainId</code>
+| String
+| Yes
+| The active Liquid or Elements chain ID.
+|-
+| <code>context.assetId</code>
+| String
+| Yes
+| The full ELIP-0144 asset ID.
+|-
+| <code>metadata.name</code>
+| String
+| No
+| The asset display name.
+|-
+| <code>metadata.ticker</code>
+| String
+| No
+| The ticker shown in the summary layer.
+|-
+| <code>metadata.precision</code>
+| Integer
+| No
+| The decimal precision used to format base-unit amounts.
+|-
+| <code>metadata.entity.domain</code>
+| String
+| No
+| The issuer or entity domain.
+|-
+| <code>metadata.issuer_pubkey</code>
+| String
+| No
+| The issuer public key from the asset contract.
+|-
+| <code>metadata.version</code>
+| Integer
+| No
+| The asset contract version.
+|-
+| <code>display.summaryLabel</code>
+| String
+| No
+| A short label for summary views.
+|-
+| <code>display.detailFields</code>
+| Array
+| No
+| A list of detailed fields to display.
+|}
+
+===Asset Amount Formatting===
+
+Amounts MUST be computed in base units first.
+
+If <code>metadata.precision</code> is available and valid, the wallet MAY display the amount as a decimal value. If precision is unavailable, the wallet MUST display the base-unit amount and SHOULD show that decimal precision is unavailable.
+
+Asset metadata MUST NOT override the asset ID of a transaction input or output.
+
+===Asset Metadata Example===
+
+<pre>
+{
+  "$schema": "https://example.invalid/liquid-clear-signing/asset-metadata-v0.schema.json",
+  "kind": "liquid.assetMetadata",
+  "version": 0,
+  "context": {
+    "chainId": "bip122:1466275836220db2944ca059a3a10ef6",
+    "assetId": "bip122:1466275836220db2944ca059a3a10ef6/elip144:ce091c998b83c78bb71a632313ba3760f1763d9cfcffae02258ffa9865a37bd2"
+  },
+  "metadata": {
+    "entity": {
+      "domain": "tether.to"
+    },
+    "name": "Tether USDt",
+    "precision": 8,
+    "ticker": "USDT",
+    "version": 0
+  },
+  "display": {
+    "summaryLabel": "USDT",
+    "detailFields": [
+      { "label": "Asset ID", "path": "$.context.assetId" },
+      { "label": "Ticker", "path": "$.metadata.ticker" },
+      { "label": "Name", "path": "$.metadata.name" },
+      { "label": "Precision", "path": "$.metadata.precision" }
+    ]
+  }
+}
+</pre>
+
+==Amounts and Net Balance Changes==
+
+A wallet MUST compute net balance changes per asset.
+
+A wallet MUST compute the amount lost by the wallet, the amount gained by the wallet, and the amount that stays in the wallet as change, per asset, when the required transaction data and wallet state are available.
+
+A wallet MUST show fees as part of the net balance review for the fee asset.
+
+A wallet MUST NOT use a metadata document as the source of truth for amount or asset movement.
+
+A wallet MUST reject or clearly downgrade the review if it cannot compute a safe review of wallet inputs, wallet outputs, fees, and confidentiality status.
+
+===Net Balance Change Fields===
+
+A clear-signing request review SHOULD expose the following wallet-computed structure to the display layer:
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>assetId</code>
+| String
+| Yes
+| The ELIP-0144 asset ID.
+|-
+| <code>inputAmount</code>
+| String
+| Yes
+| Wallet-owned input amount in base units.
+|-
+| <code>outputAmount</code>
+| String
+| Yes
+| Wallet-owned output amount in base units.
+|-
+| <code>changeAmount</code>
+| String
+| No
+| Wallet-owned change amount in base units when the wallet can identify change.
+|-
+| <code>externalReceiveAmount</code>
+| String
+| No
+| Amount received by external accounts when known.
+|-
+| <code>feeAmount</code>
+| String
+| No
+| Fee amount for this asset when this asset pays fees.
+|-
+| <code>netAmount</code>
+| String
+| Yes
+| <code>outputAmount - inputAmount</code>, in base units, from the wallet perspective.
+|-
+| <code>direction</code>
+| String
+| Yes
+| <code>loss</code>, <code>gain</code>, or <code>neutral</code>.
+|-
+| <code>confidence</code>
+| String
+| Yes
+| <code>verified</code>, <code>partial</code>, or <code>unknown</code>.
+|}
+
+===Net Balance Change Example===
+
+<pre>
+{
+  "assetId": "bip122:1466275836220db2944ca059a3a10ef6/elip144:ce091c998b83c78bb71a632313ba3760f1763d9cfcffae02258ffa9865a37bd2",
+  "inputAmount": "1025000000",
+  "outputAmount": "0",
+  "externalReceiveAmount": "1025000000",
+  "netAmount": "-1025000000",
+  "direction": "loss",
+  "confidence": "verified"
+}
+</pre>
+
+==Action Metadata Document==
+
+An action metadata document describes the action being performed.
+
+In cases like issuance, burn, transfer, and multisig, the action can be a special case recognized by the wallet.
+
+In some cases, a wallet MAY rely on Bitcoin Script or transaction pattern matching to understand what is happening. In some cases, this cannot be possible because of the complexity of multisig schemes and because some schemes are indistinguishable from each other from the pure transaction point of view.
+
+An action metadata document MUST NOT override wallet-computed transaction shape.
+
+===Built-In Regular Actions===
+
+This profile recognizes the following regular actions:
+
+{|
+! Action
+! Description
+|-
+| <code>transfer</code>
+| A transfer of an existing asset.
+|-
+| <code>issuance</code>
+| A issuance of a new Liquid asset.
+|-
+| <code>re-issuance</code>
+| A re-issuance of a Liquid asset.
+|-
+| <code>burn</code>
+| A burn of an existing Liquid asset.
+|-
+| <code>unknown</code>
+| A non-Simplicity action that the wallet cannot classify.
+|}
+
+===Action Metadata Fields===
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>kind</code>
+| String
+| Yes
+| MUST be <code>liquid.actionMetadata</code>.
+|-
+| <code>context.chainId</code>
+| String
+| Yes
+| The active Liquid or Elements chain ID.
+|-
+| <code>context.actionType</code>
+| String
+| Yes
+| A built-in regular action identifier.
+|-
+| <code>metadata.name</code>
+| String
+| No
+| The action display name.
+|-
+| <code>metadata.description</code>
+| String
+| No
+| The action description.
+|-
+| <code>display.intent</code>
+| String
+| Yes
+| A short action intent.
+|-
+| <code>display.interpolatedIntent</code>
+| String
+| No
+| A short summary template.
+|-
+| <code>display.fields</code>
+| Array
+| No
+| Display fields required for the action.
+|}
+
+===Action Metadata Example===
+
+<pre>
+{
+  "$schema": "https://example.invalid/liquid-clear-signing/action-metadata-v0.schema.json",
+  "kind": "liquid.actionMetadata",
+  "version": 0,
+  "context": {
+    "chainId": "bip122:1466275836220db2944ca059a3a10ef6",
+    "actionType": "transfer"
+  },
+  "metadata": {
+    "name": "Transfer",
+    "description": "A regular transfer of a Liquid asset."
+  },
+  "display": {
+    "intent": "Send",
+    "interpolatedIntent": "You send {to} {amount} {asset}",
+    "fields": [
+      { "path": "to", "label": "To", "format": "account" },
+      { "path": "amount", "label": "Amount", "format": "assetAmount" },
+      { "path": "asset", "label": "Asset", "format": "asset" }
+    ]
+  }
+}
+</pre>
+
+==Simplicity Covenant Metadata Document==
+
+A Simplicity covenant metadata document binds a Simplicity program, identified by its commitment Merkle root (CMR), to human-readable covenant metadata.
+
+A Simplicity tapleaf on an Elements chain uses leaf version <code>0xbe</code> and a leaf script consisting of the 32-byte CMR of the Simplicity program.
+
+===Covenant Identity===
+
+The covenant identity used by this document is the CMR.
+
+A wallet MUST compute the CMR itself from the Simplicity program bytes. A wallet MUST NOT trust a CMR claimed by an application, a transport layer, or a metadata registry.
+
+When the wallet has access to the taproot control block for a Simplicity input,
+the wallet MUST verify that the output being spent commits to a tapleaf with leaf version <code>0xbe</code>
+and a leaf script equal to the computed CMR.
+
+A hardware signer MUST perform this verification on-device when the control block is available and MUST display the covenant as unverified when it is not.
+
+===Covenant Metadata Fields===
+
+{|
+! Field
+! Type
+! Required
+! Description
+|-
+| <code>kind</code>
+| String
+| Yes
+| MUST be <code>liquid.covenantMetadata</code>.
+|-
+| <code>context.chainId</code>
+| String
+| Yes
+| The active Liquid or Elements chain ID.
+|-
+| <code>context.cmr</code>
+| String
+| Yes
+| The covenant CMR as 64 lowercase hex characters.
+|-
+| <code>context.contractId</code>
+| String
+| No
+| A 64 lowercase hex registry identifier for the covenant, when a registry binding exists.
+|-
+| <code>metadata.name</code>
+| String
+| No
+| The covenant display name.
+|-
+| <code>metadata.description</code>
+| String
+| No
+| A human-readable description of the covenant behavior.
+|-
+| <code>metadata.compilerVersion</code>
+| String
+| No
+| The SimplicityHL compiler version that produces the program from the source.
+|-
+| <code>metadata.sourceHash</code>
+| String
+| No
+| The SHA-256 of the flattened covenant source, as 64 lowercase hex characters.
+|-
+| <code>metadata.manifestHash</code>
+| String
+| No
+| The SHA-256 of the canonical transaction manifest bytes describing this covenant's actions, as 64 lowercase hex characters.
+|-
+| <code>metadata.actions</code>
+| Array
+| No
+| The covenant actions. Each action has a <code>path</code> (an array of <code>Left</code> and <code>Right</code> strings identifying the witness branch), a <code>name</code>, an optional <code>description</code>, and optional <code>outputAnnotations</code> (an array of <code>{ "outputIndex": n, "label": s }</code> objects).
+|-
+| <code>display.summaryLabel</code>
+| String
+| No
+| A short label for summary views.
+|-
+| <code>display.intent</code>
+| String
+| No
+| A short covenant intent for the summary layer.
+|-
+| <code>display.detailFields</code>
+| Array
+| No
+| A list of detailed fields to display.
+|}
+
+===Covenant Metadata Example===
+
+<pre>
+{
+  "$schema": "https://example.invalid/liquid-clear-signing/covenant-metadata-v0.schema.json",
+  "kind": "liquid.covenantMetadata",
+  "version": 0,
+  "context": {
+    "chainId": "bip122:1466275836220db2944ca059a3a10ef6",
+    "cmr": "f3cd4537d7ebb201732203195b30b549b8dc0c2c6257b3a0d53bedb08ea02874",
+    "contractId": "1111111111111111111111111111111111111111111111111111111111111111"
+  },
+  "metadata": {
+    "name": "Cash-settled option",
+    "description": "A covenant locking collateral until exercise, settlement, expiry, or cancellation.",
+    "compilerVersion": "0.5.0",
+    "sourceHash": "6a5e0d54c9f87e9c05bfa1cb3c33627628898e263861d980d9a5b1e6d1e08b25",
+    "actions": [
+      {
+        "path": ["Left", "Left"],
+        "name": "Create option",
+        "outputAnnotations": [
+          { "outputIndex": 2, "label": "Collateral locked to covenant" }
+        ]
+      },
+      {
+        "path": ["Left", "Right", "Left"],
+        "name": "Exercise option",
+        "description": "Burns option tokens and pays the settlement asset into the covenant."
+      }
+    ]
+  },
+  "display": {
+    "summaryLabel": "Cash-settled option",
+    "intent": "Interact with a cash-settled option covenant"
+  }
+}
+</pre>
+
+===Covenant Action Matching===
+
+A wallet MAY match the covenant action from the revealed Simplicity witness branch when the witness is available.
+A wallet that cannot prove the action from the witness MUST mark the action as unproven when displaying it.
+
+===Intent Verification and Transaction Manifests===
+
+Clear signing exists to make the action the user believes they are approving match the transaction they actually sign. Displaying labels is not sufficient: the wallet SHOULD verify the transaction shape against a declared recipe of the intended action before presenting that action as the summary.
+
+A [https://github.com/ElementsProject/ELIPs/pull/41 transaction manifest] describes a protocol's actions as recipes: ordered input descriptors (covenant UTXO types or wallet inputs, with asset and amount constraints), ordered output descriptors (destinations, assets, amount formulas), and per-input witnesses. Because a Simplicity covenant address is fully determined by its source and compile parameters (<code>P2TR(NUMS, tapleaf(0xbe, CMR))</code>), a manifest binds human-readable action descriptions to on-chain scripts in a machine-checkable way.
+
+When a manifest is available for the covenant being spent, a wallet SHOULD:
+
+# Recompute the covenant scripts from the manifest's sources and compile parameters (or verify supplied program bytes against them by CMR), and verify the spent outputs and created outputs match the action's input and output descriptors, including <code>required_index</code>, asset and amount constraints.
+# Display the action's description as the intent only after the recipe matches. A partial match MUST NOT be presented as a verified intent.
+
+A covenant metadata document MAY bind to a manifest through <code>metadata.manifestHash</code> (SHA-256 of the canonical manifest bytes), allowing metadata document trust (registration or attestation) to extend to the manifest content.
+
+===Raw Transaction Review===
+
+A wallet MUST let the user verify the raw transaction independently of every interpretation layer. At minimum the raw review MUST expose, for every output: the full scriptPubKey (or the address derived from it), the full asset ID in hex, the amount in base units, and any OP_RETURN payload. For every Simplicity input the raw review MUST expose the device-computed CMR and the hash of the program bytes. Interpreted views (aliases, tickers, action labels, output annotations) supplement the raw data; they MUST NOT replace it or make it unreachable.
+
+===Verification Paths===
+
+A wallet SHOULD implement as many independent verification paths as possible and display which of them succeeded. A wallet MUST NOT display data as trusted when no path succeeded.
+
+A wallet MUST display trust as provenance rather than a bare verdict: the user is shown WHO vouched for the data ("registered by you", "whitelisted by you", "attested by <label>"), not only that something was "verified".
+
+Display names and labels MUST be bound at registration time: the wallet stores the name the user approved when registering a contract, asset, or attestor, and uses the stored value on all subsequent review screens in place of any name supplied with the transaction. A description whose binding cannot be traced to a registration or attestation MUST be qualified as claimed (for example an action description not yet proven from the transaction witness).
+
+Registration itself is a trust decision and MUST be reviewable: registration screens SHOULD present human-meaningful information (names, purposes, consequences), not only identifiers, and a wallet SHOULD allow registering a protocol's related contracts, assets, and attestor as one reviewed bundle rather than training the user to approve many consecutive screens.
+
+{|
+! Path
+! What it proves
+! Trust root
+|-
+| Local contract registration
+| The user explicitly approved this contract metadata on the verifying device.
+| The user, at registration time.
+|-
+| CMR whitelisting
+| The user explicitly approved this exact program (by device-computed CMR).
+| The user, at registration time.
+|-
+| Attestor attestation
+| An attestor key vouched for the binding of contract ID to metadata.
+| The user's decision to register the attestor key on the device.
+|-
+| Source recompilation
+| The covenant source and compile parameters produce the program being spent.
+| The compiler toolchain and the reviewer of the source.
+|-
+| Manifest recipe matching
+| The transaction shape matches the declared action recipe.
+| The manifest binding (hash referenced from trusted covenant metadata).
+|-
+| Asset contract self-verification
+| The asset contract fields (name, ticker, precision, issuer domain) belong to the asset ID, per [https://github.com/ElementsProject/ELIPs/blob/main/elip-0100.mediawiki ELIP-0100].
+| The asset issuance transaction on the active chain.
+|-
+| Special-asset labels
+| The user explicitly approved a display label for an asset ID on the verifying device.
+| The user, at registration time.
+|}
+
+Dynamically issued protocol tokens (for example per-offer claim tokens in a lending protocol) have no ELIP-0100 issuer domain to verify. For these, the wallet SHOULD offer registration of a user-approved display label bound to the asset ID at the time the wallet first participates in the issuing transaction, so subsequent plain transfers of the token can be explained.
+
+===Covenant Metadata Authenticity===
+
+A covenant metadata document is authentic for a wallet only if at least one of the following holds:
+
+# The document was explicitly imported and approved by the user on the verifying device, and the device stores the document (or its hash) locally.
+# The document carries an attestation: an ECDSA signature over <code>SHA256(contract_id || SHA256(metadata))</code> that verifies against an attestor public key that the user has registered on the verifying device.
+# The wallet recompiled the covenant source with the stated compiler version and verified that the resulting program CMR equals <code>context.cmr</code>, and the wallet trusts the metadata content by review.
+
+A metadata registry download on its own MUST NOT be treated as authentic. In particular, a registry that validates only that submitted source code compiles does not bind the source or metadata to the CMR; the wallet MUST perform the CMR binding itself.
+
+==Trust Assumptions==
+
+This section defines the trust boundaries for clear signing. Every layer MUST degrade to an explicit unverified state instead of displaying unverified data as trusted.
+
+===Transaction Shape===
+
+The final transaction shape (inputs, outputs, amounts, assets, fees) MUST be computed by the wallet from the transaction, PSET, wallet state, and wallet policy. No metadata document, application hint, or registry response may override it. A wallet MUST reject or clearly downgrade the review when it cannot compute a safe review of wallet inputs, wallet outputs, fees, and confidentiality status.
+
+===Asset Metadata===
+
+Liquid asset metadata is self-verifying via [https://github.com/ElementsProject/ELIPs/blob/main/elip-0100.mediawiki ELIP-0100]: the hash of the asset contract is committed into the asset entropy and therefore into the asset ID. A wallet SHOULD verify that the asset contract and the issuance prevout reproduce the asset ID before displaying contract fields (name, ticker, precision, issuer domain) as verified. An asset registry is a transport for contracts, not a trust anchor.
+
+===Covenant Identity and Metadata===
+
+The covenant CMR MUST be computed by the verifying device from program bytes, and bound to the spent output through the taproot commitment as described above. Covenant metadata authenticity is established per the Covenant Metadata Authenticity section. The role of a hardware signer is central: the hardware device MUST NOT display host-provided covenant claims as verified unless the device itself verified the CMR, the taproot binding, and the metadata binding.
+
+===Account Metadata===
+
+Account aliases are local, user-imported bindings. There is no global account naming trust. The detailed view MUST always expose the full account identifier so the user can verify it out of band.
+
+===Attestors===
+
+An attestor is a public key that the user chose to trust by registering it on the verifying device. Attestor registration is a user decision made out of band; this document does not define an attestor PKI. A valid attestation from an unregistered attestor MUST be displayed as unverified. At registration time the wallet SHOULD let the user approve a display label for the attestor key and MUST use that stored label, not a per-transaction claim, whenever an attestation from the key is displayed.
+
+===Software and Hardware Split===
+
+A software wallet computes the full layered review from complete wallet state. A hardware signer is the final authority for the inputs it signs: everything the hardware device displays as verified MUST have been verified on-device (CMR computation, taproot leaf binding, metadata hash, attestation signature). Data that the host claims but the device cannot verify MUST be displayed as unverified or the request MUST be rejected.
+
+==Reference Implementation==
+
+* Software wallet: the <code>clear_sign</code> module of the [https://github.com/Blockstream/lwk Liquid Wallet Kit], which builds the layered clear-signing request (net balances, account, asset, action, and covenant reviews) from a PSET and wallet state, validates metadata documents against the active chain, and is exposed to mobile wallets through the LWK bindings.
+* Hardware signer: [https://github.com/Blockstream/Jade Blockstream Jade], which accepts a <code>simplicity_inputs</code> sidecar to <code>sign_psbt</code>. The device computes the CMR from the provided program bytes, verifies a host-claimed CMR against it, verifies the taproot leaf binding when a control block is provided, verifies metadata hashes against its on-device contract registry, verifies attestations against on-device registered attestor keys, and renders the covenant review screens before signing.