Last night I went back to read the governance ops section of @SignOfficial , actually at first I didn't intend to read it carefully. I thought I understood 'governance' in web3: proposal, voting, execution — the repeating pieces in most systems. If there are differences, it's only better UI, cheaper gas, or a few more layers of delegation. After reading too many projects for a while, I almost defaulted to the assumption that governance is something 'good enough', not a place for many fundamental innovations anymore.
But there is a small detail that makes me stop longer than I thought.
Not a specific feature, but the way they describe governance as a form of 'operation' directly tied to data — not just a decision-making process. At first, I skimmed over that part quickly, because it sounded a bit abstract. But the more I read, the more I began to see something that didn't match my previous understanding of governance.
If you look quickly, governance in this section still has familiar elements: proposals are created, users sign, data is validated, and finally a state is recorded. Nothing too new on the surface. But what I find more noteworthy is how the entire process is not packaged into a separate module, but instead placed within the same system with schema, attestation, and query.
At first, I thought this was just a way of organizing the documentation. But as I read more closely, I began to realize they are trying to blur the lines between 'governance action' and 'data primitive'.
A proposal, in this way, is not just a suggestion. It is a structured data form, with a clear schema, that can be verified, queried, and combined with other data. Voting is also not just an on-chain action, but becomes a series of attestations that can be processed like any other data in the system.
It sounds small, but this point made me stop.
Because if viewed this way, governance is no longer a 'layer on top'. It becomes part of the data layer. And this brings an interesting consequence: everything related to governance — from proposals, votes, to execution — can be queried, aggregated, and reused in a much more flexible way.
At first, I thought: 'okay, so it's just better data indexing.' But then I realized, without a sufficiently tight schema and attestation system, this is almost impossible. Most current systems store the results of governance, not the 'meaning' of it in a reusable way.
Here, $SIGN seems to be trying to do the opposite.
They start by defining the data first — what the schema is, who has the right to verify, where the data is stored — and then let governance 'run on' those primitives. This makes governance no longer a rigid process, but a set of operations that can be composed.
Without this layer, governance is often locked within each protocol. A DAO A cannot easily understand or use the governance results of DAO B unless there is a separate adapter layer. But if governance is represented as data with clear semantics, then theoretically, it can be shared and reused across systems.
This is where I start to see it touch on a deeper layer.
I’ve seen many projects trying to improve governance by increasing participation (delegation, incentives), or optimizing execution (automation, timelock, multisig). But most still maintain the assumption that governance is a 'black box' — you input a proposal and receive results.
Here, they seem to be trying to break that box open and turn the entire process into a form of open data.
Of course, if looked at more closely, this approach raises quite a few questions. For example: when everything becomes queryable data, who will define the standard schema? If each protocol defines its own schema, then the issue of interoperability returns to square one. But if there is a common standard, then questions about control and flexibility arise.
What I find interesting is that Sign does not try to thoroughly resolve these questions in the documentation. They only provide a toolkit for building, rather than imposing a specific governance model. This sounds reasonable, but also means that the hardest part — convergence on standards — is pushed out.
Another point I find 'on the right track', though not very prominent, is how they allow the query layer to become a central part. If governance is data, then the ability to query that data is almost as important as creating it. This opens up the possibility of building analysis, aggregation, or even meta-governance layers across different systems.
But at the same time, it also exposes a familiar issue: very few people actually build on the query layer. Most developers are only concerned with writing data, not reading and reusing it. So even if the design is reasonable, adoption remains a big unknown.
I also noticed that they clearly separate storage and verification. This is not new, but in the context of governance, it has a different significance. It allows governance data to exist independently of where it is verified. If a chain encounters problems, the data can still be validated elsewhere. It may seem like an edge case, but in the context of multi-chain or cross-chain governance, it becomes an important factor.
Nevertheless, I am still a bit cautious about this entire direction.
Not because the design has clear problems, but because I've seen too many systems that are 'architecturally correct' but never become standards. Governance is particularly sensitive to network effects — a model is only valuable when enough people use it together. And convincing protocols to abandon their current governance systems to switch to a new data representation is not straightforward.
Perhaps the hardest part is not building primitives like schema or attestation, but getting others to agree that this is the way to go.
At first, I thought I was reading a rather 'logistical' part of the documentation, like ops for governance. But the more I read, the more I see it resembles an effort to redefine governance from a data perspective — not something that happens after the system is established, but something embedded from the beginning.
I’m not sure where this approach will lead. It seems reasonable at the design level, but there are still quite a few variables on the adoption side, standards, and how other systems interact with it.
Perhaps this is one of the directions that I will need to monitor further for a while, just to see if turning governance into a form of data can actually change how systems operate... or if in the end, it still gets pulled back to the old patterns that I've seen too many times.