Introduction
The evolution of the eIDAS regulatory framework in Europe, especially with eIDAS 2, shows that electronic evidence, digital identity, trust services and electronic ledgers will become increasingly important in the coming years. The introduction of qualified electronic ledgers is particularly interesting, because it confirms that electronic ledgers can play a role in ensuring the integrity, timestamping and chronological ordering of certain electronic data.
This point seems important for the Cosmos stack, because it shows that electronic evidence is not only about document storage or electronic signatures. The real issue is the ability to produce reliable, verifiable and usable evidence for digital systems, whether for private actors, public actors, enterprise workflows, smart contracts or, tomorrow, AI agents.
Originally, my thinking came mainly from an administrative-law use case. In my Master’s thesis in French public law, I worked on the idea that a sovereign ledger could allow public administrations to record certain proofs related to administrative acts, procedures, publications, notifications and public procurement. The goal was to think about an infrastructure capable of bringing more trust, traceability and legal certainty to public action in the age of automation.
However, in order to build a simpler and more easily demonstrable MVP, I chose to start from a private environment. The MVP presented here is therefore intentionally limited. It does not yet cover all legal or contractual workflows. It focuses on one first private legal event: the signature of a document through DocuSign, and then the anchoring of the proof of that signature on the Cosmos Hub provider testnet.
The starting idea is simple: before considering legal automation, whether through smart contracts, AI or enterprise workflows, we must first be able to trust the data being used. An AI agent or a smart contract cannot safely move forward in the execution of a contract if the previous event is not verifiable.
In this logic, the DocuSign MVP serves as a first experiment. It shows how a proof of signature can be structured, hashed, anchored on-chain, and then verified through a proof bundle. From this first case, we can then think about broader workflows: governance decisions before signature, important contractual clauses, contract execution, escrow, amendment, termination, or even administrative use cases.
Part I: A DocuSign MVP to test contractual proof on Cosmos
I: The Signing Ledger MVP and the anchoring of a signature proof
The MVP is fairly basic, but it allows us to explain the intended flow. It is an interface connected to a DocuSign test API, allowing the user, once connected to both DocuSign and Keplr, to send a document for signature to an email address.
Once the document has been sent through DocuSign, the application calculates several hashes related to the sent envelope, including the hash of the initial document and the hash of the DocuSign envelope. The user can then record, in a transaction on the provider testnet, from their Cosmos address, a proof of the sending of this envelope. This proof is published as a memo containing the important hashes.
Once the envelope has been signed by the counterparty, the user can then anchor a second proof, this time related to the final signature. This second proof relies on several hashes, including the signed document and the DocuSign Certificate of Completion.
The user can then download two proof bundles:
- a proof bundle for the sending of the envelope before signature;
- a final proof bundle after signature.
These bundles allow anyone to verify that the document contained in the bundle is indeed the same as the one that was originally recorded. Verification consists of recomputing the hashes locally, and then comparing them with the hashes contained in the memos of the Cosmos transactions.
The MVP therefore records two legal events:
- the sending of the DocuSign envelope before signature;
- the completion of the signature, with the signed document and the certificate serving as proof of signature.
The hashes contained in the memos make it possible to demonstrate, thanks to the immutability of the chain, that a proof bundle or a document corresponds to the originally recorded version.
Before going further, it is worth noting that these legal events create several proof links. First, the signature event obviously links the contracting parties together. This event would exist even without blockchain, thanks to DocuSign and the signed contract. Second, there is a trust link with DocuSign, which remains the electronic signature provider. Finally, there is a link with the on-chain recording of the proof on the provider testnet.
But the most interesting link for the future is the one that connects this proof of signature to a given Cosmos address. The proof of the signed contract becomes linked to the Cosmos address that recorded this event. This address becomes the on-chain author of the proof anchoring. This is an important point for what comes next, especially regarding governance, contractual authority and automated execution.
II: From anchored signature to verifiable contractual workflow
To understand the value of this type of recording, we need to start from two temporal dimensions.
The first temporal dimension is before the signature of the contract. It concerns the decision-making process, the authority of the person entering into the contract, internal authorization, and more broadly the governance path that leads to the sending of the contract.
The second temporal dimension is after the signature of the contract. It concerns the execution of the contract, its amendment, its termination, or the conditions that allow certain actions provided for in the contract to be triggered.
The MVP voluntarily starts with signature, because it is a clear, identifiable and relatively easy-to-verify legal event. But the signature should primarily be understood as a first trust checkpoint. Once this proof of signature is anchored, it becomes possible to think about other legal or contractual events that could be attached to this first proof.
A: Contractual decision-making before signature
The MVP starts when the contract is sent to the counterparty through DocuSign. However, before this sending, the company must in principle go through some form of internal decision-making. The person sending or signing the contract must have the authority to do so, and certain decisions may require hierarchical, budgetary, legal or even more structured governance approval.
If we assume, for example, that a company has a sovereign Cosmos chain for its own internal needs, this chain could contain a governance module, contractual authority rules, delegations of authority, or validation paths specific to certain important decisions.
In this context, the company could use the Hub through Interchain Accounts to anchor several linked proofs:
- proof that the contractual decision was taken according to internal rules;
- proof that the person or entity acting had the authority to do so;
- proof of the sending of the DocuSign envelope;
- proof of the signature of the contract;
- the link between these different steps and the Cosmos address used to publish the proof.
The goal is to create a verifiable path between the internal decision, the sending of the contract, the signature, and the on-chain anchoring. The internal details of the governance process or the contract can remain private on the company’s chain or inside an off-chain bundle, while the Hub only receives hashed proofs.
The Hub could therefore become a common point of reference to verify decisions made by sovereign chains. In case of conflict, fork, modification of the document or dispute over the decision-making process, the already anchored hashes would make it possible to compare versions and identify which one corresponds to the proof published at a given time.
B: Execution, amendment and termination of the contract after signature
Today, the MVP only anchors the proof of signature of the contract. To go further, however, it is important to understand that the signature is only a first proof checkpoint. It can demonstrate that a document was signed in a certain version, but it is not yet enough to understand all the useful content of the contract or the events that may occur after its signature.
The next step is therefore to attach certain important pieces of contractual information to this proof of signature. For example, execution clauses, payment conditions, deadlines, late-payment clauses, amendment conditions, termination conditions, delivery obligations or compliance criteria.
This information could be structured in a private bundle or in the company’s sovereign chain, and then attached to the proof of signature through hashes. The idea is to be able to demonstrate that a clause or condition did exist in the signed version of the contract, without necessarily publishing that clause in clear text on the Hub.
This is where the link with the Cosmos address becomes particularly interesting. If the proof of signature is anchored by a given Cosmos address, and if certain important contractual information is attached to that proof, then this address becomes a verifiable point of reference for the rest of the workflow. Certain automated actions could then be conditioned on the verification of these proofs.
Contractual data can therefore be used for verified automatic execution, whether through smart contracts, enterprise workflows or artificial intelligence.
Before acting, a system could verify:
- the existence of the proof of signature on the Hub;
- the Cosmos address that anchored this proof;
- the existence of an execution clause in the signed version;
- the existence of a payment condition;
- the existence of an amendment clause;
- the existence of a termination condition;
- the existence of a delivery proof;
- the existence of a compliance proof.
For example, an escrow system could verify that the signed contract does contain a payment release clause in case of compliant delivery. It could then verify that a proof of compliant delivery has indeed been anchored. If these two elements are verified, then the payment could be released.
Similarly, an AI agent could use these proofs as checkpoints before moving to the next step of the workflow. It could verify that the contract was signed, that the relevant clause exists, that the required condition is fulfilled, and then propose or trigger the next action within the defined framework.
Execution could take place directly on the company’s Cosmos chain. But the execution event itself could then be anchored as proof on the Hub with ICA, so that the execution benefits from the same level of verifiability as the initial signature.
Each important legal or contractual event could therefore be hashed and attached to the workflow:
- the contract was signed;
- the delivery clause exists in the signed version;
- the parcel was delivered;
- the delivery is compliant;
- the escrow release condition is fulfilled;
- the payment can be released;
- an amendment to the contract was accepted;
- a termination was triggered according to the agreed conditions.
The signature therefore becomes the first trust checkpoint, but it can then serve as a basis for a broader contractual workflow. Once the signature, the important clauses and the execution events become verifiable, it becomes possible to consider more serious automation of execution, amendment or termination of the contract.
This is probably where the use case can go the furthest. Blockchain first serves to create a trust basis for contractual data. This trust basis can then legitimize automation layers, whether through smart contracts, enterprise workflows or AI agents.
III: The Cosmos Hub as trust middleware for automatable proofs
The value for Cosmos can be understood at two levels.
The first level concerns the adoption of the Cosmos stack itself. This type of legal use case could become an additional building block to offer to institutions and companies that wish to adopt the stack. The Cosmos stack would not only be used to create a chain, but also to build an infrastructure for proof and automation. A company could keep its contracts, documents, clauses, internal governance and sensitive data in its own environment, while structuring this information in a verifiable way.
The second level concerns the Cosmos Hub more specifically. The Hub could position itself as trust middleware for proof anchoring. Its role would not be to know the content of the contracts or to execute all the contractual logic directly, but to provide an external proof point, more neutral and more decentralized than the company’s internal environment.
The goal is therefore to separate data and proof. Sensitive data remains in the company’s environment or in a private bundle, while the Hub receives only hashes. It does not need to know the content of the contract, the exact clauses or the details of the workflow in order to provide a trust layer.
This trust layer becomes interesting because it can then be used by automated systems. An AI agent, a smart contract or an enterprise workflow can verify that an important event has indeed been anchored before going further: governance decision, contract sending, signature, execution clause, compliant delivery, amendment or termination.
Interchain Accounts could then serve as the technical mechanism to publish these proofs from the company’s environment to the Hub. The company would keep its contracts and private data, but could anchor on the Hub the proofs needed to make certain steps of the workflow verifiable and therefore automatable.
From this perspective, the Cosmos stack provides the sovereign infrastructure, while the Hub provides an external IBC layer of trust. This articulation is what makes the use case interesting: proof anchored on the Hub can become a reliable checkpoint to trigger or secure automation layers.
Part II: The administrative use case as the origin of the reflection
This administrative use case is actually the starting point of my reflection. Without trying to fully develop it here, since it is analyzed in much greater depth in my Master’s thesis, the general idea is that administrative acts face a similar need to the one described above for private contracts: creating reliable, verifiable and usable proof of important legal events.
I: The need for proof in administrative acts
In the administrative context, trust is central. An administrative act does not produce effects only because it materially exists, but also because it complies with a number of conditions of authority, form, procedure, publication and notification. A significant part of legal uncertainty can come precisely from human errors in these steps: wrong signatory, procedural error, lack of publication, failure to notify, incorrect chronology, or difficulty proving that a formality was properly completed.
This is where a sovereign ledger could be useful. By recording proofs of the different steps in the life of an administrative act, it becomes possible to strengthen traceability and legal certainty in public action. The objective would not only be to keep a record, but to create a trust layer that could then make a certain degree of administrative programmability possible.
We therefore find the same logic as in the private contractual case: before automating, one must be able to verify. If we want a system to trigger a procedure, publish an act, verify authority, check a notification or execute a public procurement step, it must first be able to rely on reliable proof of the previous event.
This reasoning can be applied to unilateral administrative acts, but also to administrative contracts and, more specifically, to public procurement. In these areas, chronology, authority, publicity, transparency and compliance with procedures are essential. A ledger could therefore be used to record proofs of important steps: decision, validation, publication, notification, award, signature, amendment, execution or termination.
II: Sovereignty as a condition for administrative proof
The important difference with the private case is that the Cosmos Hub would probably not be able to serve as the main intermediary for a State. A State will not base its administrative trust on an external public infrastructure that it does not control, whether Ethereum, the Cosmos Hub or another network. Administrative proof requires a specific sovereignty requirement.
But this apparent limit becomes precisely interesting with the Cosmos stack. The need for sovereignty can be satisfied by a chain belonging to the State, built with the Cosmos stack and operated by a consensus of public actors. We could imagine, for example, a sovereign chain operated by different public entities, such as the State, regions, departments or other public institutions, each participating in the reliability of the registry.
This chain could record proofs related to administrative acts, procedures, decisions, publications, notifications, administrative contracts and public procurement. The goal would be to obtain a sovereign ledger, controlled by public actors, capable of producing reliable, chronological and verifiable proof of important administrative events.
Thus, even if the Cosmos Hub is probably not the appropriate trust layer for a State’s administrative proof, the Cosmos stack remains particularly relevant. It could make it possible to build a sovereign infrastructure, decentralized between public actors, and adapted to the specific requirements of public law.
Conclusion:
This post is an attempt to share my current vision of a general blockchain use case: the recording of legal proofs and their automated execution, whether through smart contracts, enterprise workflows or artificial intelligence.
Law must adapt to new technological advances. If automation is now at the center of the debate with AI, this automation will only truly work if we can trust the data being used.
This is exactly the role that a proof infrastructure can play. Before an AI agent or a smart contract executes an action, it must be possible to verify that the previous legal or contractual event actually occurred, that the expected conditions exist, and that the proofs correspond to the original version of the document or workflow.
The DocuSign MVP presented here is therefore a first step. It starts with signature, because it is a clear and easily demonstrable legal event. But the idea goes further: progressively building an infrastructure capable of verifying the contractual and legal events required for automation.
In my view, this opens an important field of utility for the Cosmos stack and for the Hub. The Cosmos stack can provide sovereign chains adapted to the needs of companies or institutions. The Hub can serve as a common proof layer within the IBC network. Interchain Accounts can allow these chains to publish proofs on the Hub while keeping their documents private.
I worked very hard to get here, I hope you will appreciate this post, and the thesis for those who would like to go further. I also thank in advance anyone who takes the time to give me feedback.
I am open to any comments, collaboration and help, especially on the technical relevance of the MVP, the possible role of the Cosmos Hub, and the possibility of building verifiable contractual and legal workflows in the Cosmos ecosystem.
Thank you for your attention. If you would like to contact me, you can do so by email or on Telegram.
You will find attached my thesis, titled: Blockchain as an Infrastructure for Enhancing the Legal Certainty and Programmability of Administrative Acts.
Telegram : @BradvaKun
email : quentinvittecoq@gmail.com