Linking offering documentation to deployed token — intended use of setTerms() / DocumentEngine?

[GreatMessage]

Hi CMTA team,

I'm exploring the CMTAT framework for tokenization of Swiss securities
under Art. 973d ff. CO and have a question about linking a deployed token
to its offering documentation.

The problem (chicken-and-egg):
A termsheet needs to reference the token, and the token needs to reference
the document. If we put a SHA-256 hash of the document into the smart
contract, the document can't contain the hash of itself.

Assumption based on documentation:

1. The termsheet references a stable identifier — no hash in the PDF itself
2. After deployment, setTerms() (ERC-7551) links the token to the document
3. DocumentEngine (ERC-1643) can store the document URI + SHA-256 hash
   on-chain for verification

Questions:

1. Is setTerms() the intended mechanism for linking offering documentation
   after deployment?
2. What is the recommended format for the terms parameter — URL, hash,
   or combination?
3. How do DocumentEngine and setTerms() relate — complementary or
   alternatives?
4. Are there published examples or best practices for this workflow?

Thank you for this excellent open-source standard.

[rya-sge]

Hello @GreatMessage,

Thanks a lot four your message.

The problem (chicken-and-egg):

You can put the hash on-chain once the token is deployed through setTerms.

Note that there are two functions setTerms. The one from ERC-7551 can only be used to set the hash and the uri, while the standard version from CMTAT contains the name, uri and hash.

ERC-7551 setTerms version is only available if you use the specific deployment version to ERC-7551

Questions:

1. Yes
2. I will let CMTA association answers since it is not a technical question. If the terms are or can be made public, personally I would recommend to put the URL + hash (combination)
3. DocumentEngine is here if you want to reference several documents or manage the documents for several tokens through a unique smart contract (Document Engine). However, we don't have a document engine for the latest audited release (CMTAT v3.0.0) and we may change the API in the future to follow strictly IERC-1643.

=> So if you plan to use a document engine, it will require a bit of development on your side.

4. I will let CMTA answers. Historically, only the URL could be put on-chain (not the hash) and we have added the hash to follow IERC-1643 standard practice

Best!

[GreatMessage]

Hello @rya-sge

Many thanks for your message and the answers, very helpful.

It is good to know that setTerms() is the intended mechanism. I think I will go with the URL + hash combination as you suggest.

I will keep an eye on the IERC-1643 evolution.

One follow-up: for the hash, do you recommend SHA-256 stored as bytes32, or is there a different convention emerging with the IERC-1643 alignment?

Also: you mentioned you'd let the CMTA association answer on the format question and best practices, will they respond here in this thread, or should I reach out separately?

Thanks again for maintaining this excellent standard.

best regards

[VALER-ge]

Hi @GreatMessage - have now replied to your email sent to CMTA inbox. Thanks

[GreatMessage]

Hi @VALER-ge - thank you very much for your extensive efforts. I highly appreciate your answers to my questions. best regards