I once thought that electronic signatures were a complete solution. Click, sign, a green checkmark appears, and then a sense of 'good, this is valid' comes over you. It seems safe, formal, and finished. Like most people, I didn't question it. If it's done by a big platform, then the legal and technical structures behind it should already be solid.
But slowly, this idea began to seem a bit… superficial. Not entirely wrong, just not complete.
Because when you shift your perspective away from these systems' 'ideal environments,' reality becomes complex. Laws in different countries are not consistent, and there is no inherent mutual trust between different judicial systems. Thus, a seemingly simple matter—a signed document—becomes anything but simple. It is valid within its own system, but once it needs to interact with another system that does not recognize it, problems arise.
It is also from here that my perspective changed.
I no longer focus solely on the act of 'signing' itself, but rather begin to think about what happens afterwards. Because the signature is not the endpoint, but the starting point of dependence. The real question is: is this proof still valid afterward? Can it be taken away? Can it be reused? After leaving the original system, can it still hold?
When I started to understand the Sign Protocol, I did not see it as an ordinary signing tool. On the surface, it seems to belong to the same product category, but its core idea is different. The focus is not on 'signing,' but on 'what remains after signing.' It attempts to ensure that proofs do not rely on a single company but are preserved and verified in an independently existing manner.
But this raises an even more critical question: simply 'creating' is not enough; it must be able to persist.
I now prefer to understand with a simple metaphor. A traditional electronic signature is like putting a signed contract in an office of some institution. You trust that they won't lose it, won't tamper with it, and that it can be found when needed. In contrast, a blockchain-based proof is more like putting the contract in a public archive—no one controls it alone, but anyone can verify it.
Sounds powerful, right? But the key is: will it be used again, or will it just lie there quietly?
Because where most systems truly fail is not in 'creation,' but in 'afterwards.' They generate results, but those results do not flow. It's like printing money that never enters circulation. It exists, but has no effect.
So I began to look at these systems structurally.
First is interactivity. A system is only meaningful when participants can truly use it among themselves. If users, developers, and institutions can easily create and verify proofs, then the system will gradually take shape. If everything relies on isolated scenarios or controlled environments, it remains fragile.
Then there's reusability. This is crucial. If a proof generated in one place can be used in another, it no longer becomes a one-time result but transforms into a 'building block' that can be stacked. A certificate should not lose its meaning just because it leaves its original system. When it can be used across scenarios, its value begins to accumulate.
Then there's the network effect—not the concept that is repeatedly mentioned, but the kind that truly occurs. When the addition of each new participant makes existing data more valuable—being verified, referenced, built upon—the system will grow naturally. If every new scenario has to start from scratch, there is no accumulation and no potential.
So back to reality, where does this system stand?
Indeed, it has been implemented in places like Sierra Leone and the UAE. This sounds like adoption. But I am increasingly accustomed to separating 'existence' and 'integration.' A system being deployed does not mean it is truly relied upon. True infrastructure often does not need to be emphasized—it quietly becomes part of the daily routine.
From a market perspective, its position is attractive, situated right at the intersection of identity, law, and digital ownership. However, overall maturity is still developing. The current activity appears to be driven more by events or collaborations rather than sustained, natural usage. Participation is growing, but it is still relatively concentrated and has not fully diffused.
And this raises a core question:
Are people using it out of 'need,' or because they are 'incentivized' to use it?
The difference between the two is significant. Incentives can bring short-term activity but cannot lead to long-term stability. A truly vibrant system is one that people will use repeatedly because it addresses a persistent problem. If a proof is created only once and never used again, then the system is static. But if they are continuously referenced, reused, and integrated into workflows, then the system begins to sustain itself.
There is also a deeper issue that cannot be ignored.
If such systems are adopted on a large scale, especially by governments, they bring not only efficiency improvements but also 'permanence.' A system for preserving proofs also means that records may be kept for a long time, even permanently. This is not just a technical issue, but a structural change. Technology does not dictate use, but it alters the boundaries of possibility.
So now, my perspective on these systems has changed.
What would truly give me more confidence? It's quite simple. If I start seeing these proofs being used across multiple independent systems, that is a signal. If institutions use them not just occasionally but rely on them daily, that's stronger. If developers build on existing proofs rather than continually creating isolated data, that indicates the system is accumulating.
But if the activity is periodic—dependent on announcements or incentives—if the results are not reused, and if participation remains concentrated among a few, then one must remain vigilant. This indicates that the system is 'creating,' but not 'flowing.'
And I've been reflecting on a very simple point:
The truly important systems are not those that 'can create things,' but those that enable these things to continue flowing, being used, referenced, and ultimately integrating naturally into daily operations.
When it no longer needs to be deliberately focused on,
It truly becomes infrastructure.