# Txmanifest - portable format for wallets to call SimplicityHL contracts without custom code **URL:** \ **Category:** General\ **Created:** [July 13, 2026, 8:25am UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24 "2026-07-13T08:25:16Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![stringhandler](https://avatars.discourse-cdn.com/v4/letter/s/c57346/32.png) [@stringhandler](https://community.simplicity-lang.org/u/stringhandler)\ **Post date:** [July 13, 2026, 8:25am UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24/1 "2026-07-13T08:25:16Z")
I am not sure why I find it hard to describe the need for something like this. I think a lot of users of SimplicityHL think about writing the `.simf` file and that’s the end of it. Creating the contract is probably the most mentally challenging part, but there is a fair amount of (tedious) work in creating the wallet that interacts with the contract. Currently, simplicity contracts basically require their custom wallets to be developed. My goal for `txmanifest` is to create a standardized, descriptive format that wallets can implement for building transactions interacting with simplicity inputs and are able to generate addresses. The file itself can grow quite complex, so I’ve created a book to guide users through learning it, and that’s my recommended learning path: [Introduction - The tx-manifest Cookbook](https://stringhandler.github.io/tx_manifest_book) At the same time, I’ve created an ELIP and I’ll be editing it as I test out more and more use cases with it. I’ll keep adding to this thread to keep everyone up to date. I’d love some feedback. ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex007/uploads/simplicity_community/original/1X/6769f2cda55e509da52b7d835888f42bbeccd20d.png) [@system](https://community.simplicity-lang.org/u/system)\ **Post date:** [July 13, 2026, 8:48am UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24/2 "2026-07-13T08:48:27Z")
Unlisted on July 13, 2026, 8:48am UTC ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex007/uploads/simplicity_community/original/1X/6769f2cda55e509da52b7d835888f42bbeccd20d.png) [@system](https://community.simplicity-lang.org/u/system)\ **Post date:** [July 13, 2026, 2:31pm UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24/3 "2026-07-13T14:31:43Z")
Listed on July 13, 2026, 2:31pm UTC ---
**Author:** ![stringhandler](https://avatars.discourse-cdn.com/v4/letter/s/c57346/32.png) [@stringhandler](https://community.simplicity-lang.org/u/stringhandler)\ **Post date:** [August 20, 2026, 11:30am UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24/4 "2026-08-20T11:30:47Z")
I’ve pushed a new version. There are a lot of changes so I’ve started a changelog. # [0.2.0] - 2026-08-20 **Breaking:** a manifest that sets `utxo_type.confidential` no longer parses. Confidentiality is now declared per output. ### Added - **Blinding factors can be declared.** An output or an input may carry a `blinding` block of `asset_bf` / `value_bf`. Each is a 32-byte scalar written as a decimal, a `0x` string, a `params.X` / `instance.X` reference, or arithmetic over one (`params.RT_FACTOR + 1`). On an output it pins what the builder would otherwise pick at random; on a covenant input it states the factors the spent UTXO was created with. Needed by any covenant that verifies its own UTXOs as Pedersen commitments, because Elements’ `blind_last` chooses every factor itself. - **Confidential covenant outputs.** `confidential: true` on a `utxo_type` destination blinds the output, using the wallet’s change blinding key. - **Confidential covenant inputs.** Their prevout is rebuilt from the asset, the amount and the declared factors — a taproot sighash and Simplicity’s `inputUTXOsHash` both cover only a spent output’s asset, value and scriptPubKey, so the reconstruction is exact and needs no network access. - **`allow_change`** on an action: `none`, `lbtc_only` or `any`, bounding which surpluses may become a change output the manifest never declared. - **A parameter interface for `utxo_type`** : `params` on the type and `args` at each site, which closes the type’s scope so its address derivation reads only what it declares. - **`script_hash` param compute** , deriving `sha256(scriptPubKey)` from an address so a covenant’s committed hash and the address paid to cannot drift. - **On-chain amounts.** A pinned outpoint reads its amount and asset from the chain, outranking anything the manifest or an operator supplies. - **`simplicity_hl.unstable_features`** for opting into SimplicityHL `imports` and `enums`. ### Changed - A reissuance now writes the spent token’s asset blinding factor as its `issuance_blinding_nonce`, which is the value Elements rebuilds the token’s generator from. Previously a constant placeholder. - Pinning an output’s `asset_bf` to the value an input of the same asset already carries is refused with an explanation. The surjection proof would have a zero shift to prove; secp reports only `CannotProveSurjection`. ### Removed - **`utxo_type.confidential`** (breaking). It answered per address a question that is per output: one covenant address can hold a blinded reissuance token beside an explicit collateral UTXO. Use `confidential` on the output. Every example set it to `false`, and the builder only ever read it to warn. ---
**Author:** ![tvolk131](https://yyz1.discourse-cdn.com/flex007/user_avatar/community.simplicity-lang.org/tvolk131/32/12_2.png) [@tvolk131](https://community.simplicity-lang.org/u/tvolk131)\ **Post date:** [August 20, 2026, 3:49pm UTC](https://community.simplicity-lang.org/t/txmanifest-portable-format-for-wallets-to-call-simplicityhl-contracts-without-custom-code/24/5 "2026-08-20T15:49:38Z")
Nice, awesome to see that v0.2.0 supports re-issuance tokens! I know I’ve discussed this elsewhere many times, but I’d love to see support for tx manifests to describe not just how to push a known contract instance forward, but how to discover contract instances purely from chain data, and re-derive their state. Such functionality, I think, could allow for building a tx manifest indexer server. Such a server could be given multiple different tx manifests along with their SimplicityHL source files (and possibly their SimplicityHL compiler version) and each manifest’s initial block height, and the indexer could scan every block and transaction from a connected liquid node and index all found instances. This could replace the lending indexer, and eliminate the need for creating a new indexer for each simplicity contract.