Is there a chance for BTC to surge on the weekend?

It's basically impossible, as BTC fluctuations are usually quite small on weekends.

Unless there's some major good news, I hope for one.

I want to talk about something that few people have written about.

It's not because it's profound, but because it's hidden in the underlying design of the Sign Protocol technology. On the surface, it seems like a boring data structure problem, but if you think deeper, it touches on the most critical unresolved tension in the entire product philosophy of $SIGN .

First, clarify what Schema is, otherwise the following discussion will be unclear.

In @SignOfficial , each Attestation is constructed according to a Schema. A Schema is a data template that defines what fields are in this Attestation, what each field is called, and what type of data it holds. For example, in an employment relationship Attestation, the Schema may define fields such as employer name, employee address, position, and start date. In a KYC certification Attestation, the Schema may include fields like identity verification level, certifying agency, and validity period. #Sign地缘政治基建

Different use cases require different Schema, which is a natural thing.

The design choice of the Sign Protocol allows anyone to create and register their own Schema. This is an open, permissionless design that is consistent with the overall decentralized philosophy of the Sign Protocol. Any organization, any developer, any individual can define a set of Schema according to their needs and then use this Schema to issue Attestation.

I agree with this design conceptually; openness and permissionlessness are basic attributes that Web3 infrastructure should have.

However, after thinking seriously for a while, I found that this design choice brings a real trouble, and this trouble will become more apparent as the SIGN ecosystem expands.

The trouble is as follows.

When Schema can be freely created by anyone and there are no mandatory standardization requirements, the same concept may have dozens or even hundreds of different versions of Schema. For degree certification, it's possible that one hundred universities have each created a slightly different set of Schema. For employment relationship certification, it's possible that hundreds of companies have used hundreds of different structured Schema.

This is not a problem for the party issuing Attestation; they only need to issue their own credentials using their own Schema.

But for the party wanting to read and verify these Attestations, the trouble arises.

Imagine a background check service that wants to verify degree Attestation from one hundred different universities at the same time. If these one hundred universities use one hundred different Schema, this service will need to write separate reading logic for each Schema, understand the field structures of each Schema, and handle issues like inconsistent field names, mismatched field types, and different required fields.

This adaptation cost is a real engineering cost and grows linearly or even superlinearly with the increase in the number of Schema.

This problem has a name that has been repeatedly validated in the traditional internet, called the standardization dilemma. An open, freely extensible system, if it does not have a sufficiently strong standardization mechanism, will become fragmented with the increase of participants. Fragmentation will harm interoperability, which is precisely the core value of a credential protocol.

The significance of SIGN is to allow credentials to be verified by anyone and to let trust flow across institutional boundaries. But if the fragmentation of Schema makes the cost of verifying credentials very high, then this core value will be eroded.

I am wondering how the SIGN team views this issue, so I went to review the relevant design documents and community discussions of the Sign Protocol.

The answer I found is: there are some discussions about recommending Schema standards, and some mechanisms encourage the use of community consensus Schema, but there is no mandatory, protocol-level standardization requirement.

This answer complicates my attitude.

Not enforcing standardization is correct because enforcing standardization means a centralized Schema authority, which contradicts the positioning of decentralized infrastructure. However, completely relying on community consensus to resolve the fragmentation issue has not had many successful historical cases, and this process is usually much slower and more chaotic than expected.

I have seen how many open standards in the early internet were formed. Some were gradually converged from the bottom up through the adoption of a large number of practitioners, some were launched by a powerful participant who introduced a substantive standard that others followed, and some have remained fragmented to this day.

Which path the SIGN Schema ecosystem will take is still unclear. But one thing I think is certain: if SIGN wants to become a truly global credential infrastructure, a certain degree of standardization at the Schema level must occur; the only question is what mechanism will drive it, who will promote it, and how long it will take.

SIGN has the most motivation to promote this because the degree of fragmentation of Schema directly affects the network value of the Sign Protocol. But promoting standardization means SIGN needs to establish enough discourse power and influence within the technical community, so that enough developers and organizations are willing to adopt the Schema recommended by SIGN instead of creating their own.

This is an ecological construction issue, not a technical issue, and it is much slower and more difficult to solve than fixing a code bug.

Finally, let me mention something that makes me feel hopeful.

The Sign Protocol has a concept of a Schema registry, meaning that all publicly available Schema are searchable and citable. This at least provides a foundation for developers to check if there are existing similar Schema that can be directly used or referenced before creating new Schema.

If this registry accumulates enough high-quality Schema as the ecosystem develops, and if many developers find that reusing existing Schema is easier than creating their own, then the issue of fragmentation may naturally be alleviated to some extent without mandatory standardization.

This is an optimistic possibility, but it requires time and a sufficient number of real use cases to drive the accumulation and reuse of Schema.

SIGN is currently on this path, but how long this path is and where the endpoint is, I do not have an answer.

This is the only open issue that I feel truly needs to be seriously tracked at the technical design level after researching SIGN for so long.