Stayed up late again, this time specifically to look at the attestation creation process of @SignOfficial . I originally thought where the data is stored was just a cost issue. However, when I clicked on the hybrid attestation part, I realized that the matter is far from simple.

It's not just about storing it; there are also APIs, indexes, and query paths involved. Whether this proof can be continued to be used by others in the future is directly tied to where it is stored, which is quite frustrating.

The document for $SIGN clearly outlines the route; the schema can be fully on-chain or use hybrid methods like Arweave/IPFS, and some attestations even need to be initiated through APIs, relying on indexing services for queries. I initially thought this was just about storage preferences, but the more I look, the more I feel it’s not.

Fully on-chain is the cleanest approach, but it’s expensive, heavy, and clumsy; fully off-chain is the lightest, but others may not necessarily want to follow your path to retrieve data in the future. Hybrid seems like a compromise, but as you look further down, you find that it also brings in APIs, indexes, and query links. This means that what Sign is handling here is not just about where to store it, but whether this proof can still be called by the system in the future.

This changes the perspective entirely.

Many projects talk about attestation in a very simple way. However, Sign’s approach feels like that of a concerned adult—what if the data is too large, what if the privacy is too sensitive, how will other systems query, verify, and continue to use it in the future?

Now, what interests me most about $SIGN is not whether it can issue more proofs, but whether its proofs can be conveniently utilized by other systems in the future.

If this link cannot be flattened, hybrid is just a seemingly smart compromise. But if this link can truly run smoothly, then what Sign encounters is not just the proof layer, but the foundation of how proofs can survive between systems. #sign地缘政治基建