Linh invest
Frequent Trader
5.5 Years
51 Following
118 Followers
197 Liked
18 Shared
Posts
All
Quotes
In the past, my friend and I often argued about this issue: if logic is not put on the blockchain, then that system is 'not serious'. It feels like everything must be encoded, must run on-chain to be 'trustworthy'. But I immediately changed my perspective after reading more about @SignOfficial ; I realized that my previous assumptions were still not entirely correct: there are too many things that do not need to be executed, only verified.
We are accustomed to using smart contracts as a 'truth adjudicator machine'. Every condition must be written into code. But this method implicitly assumes that the world can be completely formalized. In reality, it cannot. Things like identity or reputation are not just data; they depend on who is observing and what they believe.
Sign does not try to replace blockchain. It reduces the role of blockchain to what is necessary: not to understand or decide what is right, but to record what has been signed in an indisputable way. An attestation is merely a claim + signature. No workflow, no approval chain. Everything stops at the ability to verify.
At first, I found this approach somewhat 'lacking control'. Without contract enforcement, what is there to ensure? But upon further reflection, what is called 'ensurance' has largely been me outsourcing trust to code. Sign is different; it forces me to decide for myself whom to trust.
Perhaps this is not a 'safer' system, but a more honest system with how the world operates. And if that is true, then what Sign changes is not the technology but the way we accept the truth.
$SIGN #SignDigitalSovereignInfra
We are accustomed to using smart contracts as a 'truth adjudicator machine'. Every condition must be written into code. But this method implicitly assumes that the world can be completely formalized. In reality, it cannot. Things like identity or reputation are not just data; they depend on who is observing and what they believe.
Sign does not try to replace blockchain. It reduces the role of blockchain to what is necessary: not to understand or decide what is right, but to record what has been signed in an indisputable way. An attestation is merely a claim + signature. No workflow, no approval chain. Everything stops at the ability to verify.
At first, I found this approach somewhat 'lacking control'. Without contract enforcement, what is there to ensure? But upon further reflection, what is called 'ensurance' has largely been me outsourcing trust to code. Sign is different; it forces me to decide for myself whom to trust.
Perhaps this is not a 'safer' system, but a more honest system with how the world operates. And if that is true, then what Sign changes is not the technology but the way we accept the truth.
$SIGN #SignDigitalSovereignInfra
A New Perspective on Reputation Through the Lens of Sign Protocol
There is one interesting thing that I just realized today: Reputation has always been treated as something 'pre-existing': a number, a badge, a status that is almost fixed: you have a reputation, or you do not. This perspective is convenient because it is simple. But it is also dangerous because it makes us forget that reputation in real life has never been a static or binary thing.
From the perspective of @SignOfficial , that assumption begins to crack. Reputation is no longer a final outcome, but a collection of attestations of claims that are signed, sourced, and can be verified. Instead of trusting a synthetic system, you can look at each piece of data that constitutes that 'reputation'.
From the perspective of @SignOfficial , that assumption begins to crack. Reputation is no longer a final outcome, but a collection of attestations of claims that are signed, sourced, and can be verified. Instead of trusting a synthetic system, you can look at each piece of data that constitutes that 'reputation'.
There is one thing I am starting to find interesting when thinking about @SignOfficial : it directly touches on what I have always assumed is necessary - bureaucracy. Previously, information needed to be 'correct' must go through many layers of approval: signatures, checks, compliance. It is slow and cumbersome, but it creates a sense of security.
Sign changes that. A claim only needs a signature and verification to be sufficient: no workflow, no approval chain, no need for a central confirmation system. It sounds simple, but it also makes me feel a bit lacking.
What is removed is bureaucracy. But bureaucracy exists not because technology is weak but because humans are imperfect. It does not make everything more correct, but makes mistakes less likely to occur and disperses responsibility.
With Sign, you no longer trust the system; you must verify yourself. An important question arises: if anyone can sign, who should I trust?
Previously, the filtering system helped you. Now you must assess the signer yourself, bear the risk if wrong. Sign does not eliminate bureaucracy. It just shifts it from the organization to your head.
This brings freedom but also opens up risks: false claims, manipulated reputations, and users lacking the ability to discern. Bureaucracy used to absorb risks on your behalf, Sign does not.
The trade-off is very clear: sacrificing the safety of the process for speed and freedom of verification, as everything runs faster, mistakes also spread faster.
And perhaps the most interesting thing is: we are still very early in this. No one knows how a system without a 'truth approval' layer will operate. It may open up new ways of organizing. But it may also be that we will accidentally rebuild the things we just tried to eliminate, only in a different form.
$SIGN #SignDigitalSovereignInfra
Sign changes that. A claim only needs a signature and verification to be sufficient: no workflow, no approval chain, no need for a central confirmation system. It sounds simple, but it also makes me feel a bit lacking.
What is removed is bureaucracy. But bureaucracy exists not because technology is weak but because humans are imperfect. It does not make everything more correct, but makes mistakes less likely to occur and disperses responsibility.
With Sign, you no longer trust the system; you must verify yourself. An important question arises: if anyone can sign, who should I trust?
Previously, the filtering system helped you. Now you must assess the signer yourself, bear the risk if wrong. Sign does not eliminate bureaucracy. It just shifts it from the organization to your head.
This brings freedom but also opens up risks: false claims, manipulated reputations, and users lacking the ability to discern. Bureaucracy used to absorb risks on your behalf, Sign does not.
The trade-off is very clear: sacrificing the safety of the process for speed and freedom of verification, as everything runs faster, mistakes also spread faster.
And perhaps the most interesting thing is: we are still very early in this. No one knows how a system without a 'truth approval' layer will operate. It may open up new ways of organizing. But it may also be that we will accidentally rebuild the things we just tried to eliminate, only in a different form.
$SIGN #SignDigitalSovereignInfra
Why is Sign Protocol's technology so good but businesses haven't "jumped in"?
There is a quite clear moment when I learned about @SignOfficial . It's not the kind of “wow new technology”. But rather a somewhat confusing feeling. If this is true, then a lot of what businesses are doing is redundant. The question that arises as I skim through that Sign is: Why does Sign do everything so well but businesses are still on the sidelines?
And finally I found the answer, this answer is from my personal perspective:
And finally I found the answer, this answer is from my personal perspective:
Zero-trust has never failed. It is only implemented in the easiest way.
I realized this not when reading the documentation, but when debugging an internal flow. Service A calls service B. The header has a clean valid token. No one asks again, "why does this request exist?" As long as it is in the correct format, it's sufficient. Trust does not disappear but is hidden away.
Sign makes me understand in a different way. It does not allow "correct format" to be enough. It forces the answer to a harder question: where is the proof?
A claim like "the user has KYC". Normally, that sounds too familiar. In Sign, that statement is empty if there is no attestation that can be independently verified, Hash, signature, reference. It does not matter who said it as long as it can be verified.
At this point, the real issue becomes apparent. It is not a lack of trust; it is an excess of uncontrolled trust.
State starts to drift out of the database. It resides in the evidence. Anyone can check, no special access is required. Stateless trust sounds beautiful.
If the source of attestation is wrong, the entire system will be "correct in a mistaken way." Cryptography cannot save dirty data. If revocation is needed, everything becomes slow and tangled. When verifying, you have to go through many layers, increasing latency. Developers start to cache and ignore.
One thing I don't like but cannot deny. Sign has no execution layer. It only states what is correct. It does not force the system to behave according to that correctness. This means that even with perfect proof, the final decision still rests with the code written by humans, and humans always find ways to simplify.
This is the most interesting point. Sign does not solve trust. It makes trust become visible, leaving no place to hide.
It’s not that the system becomes safer, but that it’s harder to deceive oneself.
$SIGN #SignDigitalSovereignInfra @SignOfficial
I realized this not when reading the documentation, but when debugging an internal flow. Service A calls service B. The header has a clean valid token. No one asks again, "why does this request exist?" As long as it is in the correct format, it's sufficient. Trust does not disappear but is hidden away.
Sign makes me understand in a different way. It does not allow "correct format" to be enough. It forces the answer to a harder question: where is the proof?
A claim like "the user has KYC". Normally, that sounds too familiar. In Sign, that statement is empty if there is no attestation that can be independently verified, Hash, signature, reference. It does not matter who said it as long as it can be verified.
At this point, the real issue becomes apparent. It is not a lack of trust; it is an excess of uncontrolled trust.
State starts to drift out of the database. It resides in the evidence. Anyone can check, no special access is required. Stateless trust sounds beautiful.
If the source of attestation is wrong, the entire system will be "correct in a mistaken way." Cryptography cannot save dirty data. If revocation is needed, everything becomes slow and tangled. When verifying, you have to go through many layers, increasing latency. Developers start to cache and ignore.
One thing I don't like but cannot deny. Sign has no execution layer. It only states what is correct. It does not force the system to behave according to that correctness. This means that even with perfect proof, the final decision still rests with the code written by humans, and humans always find ways to simplify.
This is the most interesting point. Sign does not solve trust. It makes trust become visible, leaving no place to hide.
It’s not that the system becomes safer, but that it’s harder to deceive oneself.
$SIGN #SignDigitalSovereignInfra @SignOfficial
When data is uncertain, how will Sign handle it?
I once spent nearly a day just debugging a very small case. A user was excluded from the whitelist even though everything looked valid. The signature was correct. The attestation existed, the hash matched, there were no technical errors but it was wrong in understanding.
With the same attestation, two systems read out two different results. One side considers it a reference signal. The other side considers it a direct exclusion condition. The user stands in the middle, with no way to prove themselves 'right'.
With the same attestation, two systems read out two different results. One side considers it a reference signal. The other side considers it a direct exclusion condition. The user stands in the middle, with no way to prove themselves 'right'.
I once thought Sign was just a place to store attestation - a layer of data that can be verified, with a clear schema, and that was enough. But the deeper I went, I realized that this understanding was not only wrong but also dangerous.
Because the issue has never been whether the data is on-chain or off-chain. What decides the entire system is: who creates that data, based on what source, and why another party would trust it.
Attestation is just the tip of the iceberg. What really operates underneath is trust flow.
I once saw a campaign encounter a very frustrating error: the same set of users, the same conditions, but two systems reading the data returned two different eligible lists. Not because the data was wrong. But because each party was “believing” in a different way — one party read raw data, the other relied on the processed attestation. Trust is not unified, and the result is money going to the wrong people.
That was when I understood: if you do not design trust flow, you are letting it happen on its own. And when it breaks, you do not know where to start fixing it.
Sign does not solve the issue of “what to store is right.” It provides primitives — schema, attestation, reference, verification logic for you to define what is considered right, in your specific context.
But this is precisely where the hardest point lies: Sign does not fail because the technology is weak. It fails when users are not aware that they are designing a belief system. And once trust is vaguely defined, everything behind it from eligibility to reward is just the consequence of a mistake that has been legitimized.
$SIGN #SignDigitalSovereignInfra @SignOfficial
Because the issue has never been whether the data is on-chain or off-chain. What decides the entire system is: who creates that data, based on what source, and why another party would trust it.
Attestation is just the tip of the iceberg. What really operates underneath is trust flow.
I once saw a campaign encounter a very frustrating error: the same set of users, the same conditions, but two systems reading the data returned two different eligible lists. Not because the data was wrong. But because each party was “believing” in a different way — one party read raw data, the other relied on the processed attestation. Trust is not unified, and the result is money going to the wrong people.
That was when I understood: if you do not design trust flow, you are letting it happen on its own. And when it breaks, you do not know where to start fixing it.
Sign does not solve the issue of “what to store is right.” It provides primitives — schema, attestation, reference, verification logic for you to define what is considered right, in your specific context.
But this is precisely where the hardest point lies: Sign does not fail because the technology is weak. It fails when users are not aware that they are designing a belief system. And once trust is vaguely defined, everything behind it from eligibility to reward is just the consequence of a mistake that has been legitimized.
$SIGN #SignDigitalSovereignInfra @SignOfficial
Between the "raw truth" of EAS and the "organized truth" of Sign, what is the market in need of?
I once encountered a quite unpleasant situation. A small campaign, a few thousand users, using attestation to confirm who is eligible to receive the reward. Everything seemed very clear because the task was completed, signatures were fully provided, and data was on the chain, but when it came time to check eligibility, the system returned two different results depending on where you read from.
One side is the raw data. The other side is the data that has been indexed. Both are "correct" but cannot be correct at the same time.
One side is the raw data. The other side is the data that has been indexed. Both are "correct" but cannot be correct at the same time.
I maintain the old viewpoint after researching quite thoroughly about @SignOfficial : Sign and traditional KYC do not replace each other. They are two layers of trust running in parallel.
Because 'trust' is not a single entity. One layer connects you to the real world. One layer measures you in the digital world.
KYC answers the most uncomfortable question: if something happens, who can be held accountable? It creates a static identity that can be traced back. Organizations like Binance maintain KYC because if they drop it, the connection to the traditional financial system will be severed.
Sign goes in a different direction. It does not ask who you are. It records what you have done and who has confirmed it. Attestation overlaps to form a reputation. It is not fixed. It is always updated based on behavior.
If these two are forced to be alternatives, it will break immediately at the use case. Attestation cannot stand legally. KYC does not reflect behavior over time. A clean account today can become a risk tomorrow.
So they do not compete directly.
KYC stands at the entrance. Fiat, exchange, compliance. A hard layer.
Sign operates internally. Airdrop, governance, access. A soft layer.
The notable moment is when the two layers intersect. A wallet with a clean on-chain history for many years is sometimes more trustworthy than an account that has just finished KYC. The focus begins to shift. From 'who are you' to 'how have you lived'.
It is not about replacement but about layering trust.
And perhaps the question worth keeping is not which system will replace which, but rather: when will a system be confident enough to trust your behavior, even when it does not know who you are?
$SIGN #SignDigitalSovereignInfra
Because 'trust' is not a single entity. One layer connects you to the real world. One layer measures you in the digital world.
KYC answers the most uncomfortable question: if something happens, who can be held accountable? It creates a static identity that can be traced back. Organizations like Binance maintain KYC because if they drop it, the connection to the traditional financial system will be severed.
Sign goes in a different direction. It does not ask who you are. It records what you have done and who has confirmed it. Attestation overlaps to form a reputation. It is not fixed. It is always updated based on behavior.
If these two are forced to be alternatives, it will break immediately at the use case. Attestation cannot stand legally. KYC does not reflect behavior over time. A clean account today can become a risk tomorrow.
So they do not compete directly.
KYC stands at the entrance. Fiat, exchange, compliance. A hard layer.
Sign operates internally. Airdrop, governance, access. A soft layer.
The notable moment is when the two layers intersect. A wallet with a clean on-chain history for many years is sometimes more trustworthy than an account that has just finished KYC. The focus begins to shift. From 'who are you' to 'how have you lived'.
It is not about replacement but about layering trust.
And perhaps the question worth keeping is not which system will replace which, but rather: when will a system be confident enough to trust your behavior, even when it does not know who you are?
$SIGN #SignDigitalSovereignInfra
I really like the direction of Sign, it is not noisy but quietly penetrates every corner of Web3
Have you ever wondered why we enter a restaurant when we see the sign "TripAdvisor Recommended", or trust to purchase an expensive item just because that shop has the label "Mall"? What we hold in our hands is trust, while how to ensure that label is not counterfeited by Photoshop is something few pay attention to.
In the world of Web3, it's the same. One morning, you perform a verification on a decentralized application, receiving a tiny blue check mark next to the username. You feel more secure trading with them. But you have no idea that behind that blue check is the operation of Sign.
In the world of Web3, it's the same. One morning, you perform a verification on a decentralized application, receiving a tiny blue check mark next to the username. You feel more secure trading with them. But you have no idea that behind that blue check is the operation of Sign.
I once participated in a campaign on Galxe, completed all tasks but when claiming the reward it failed, not because I did something wrong, but because the system wasn't sure I was the one performing it. In the end, I still had to DM the admin for manual verification, a very “Web2” experience in the context of Web3.
The first use cases of @SignOfficial stem from this bottleneck when trust still lies in the backend. With Sign, after completing a task, the system will create an attestation: wallet A has performed action B at time T. When claiming, the smart contract only needs to read that data again, without needing an API or waiting for admin confirmation. This means verification is done once and can be reused multiple times.
The change, though small, is fundamental: the backend no longer “confirms again,” but simply records it once. This also applies in DAO, where previous contributions were stored on Notion or Google Sheet. With Sign, each contribution is signed as it happens, transparent about the signer and the time, without needing to confirm again.
More importantly, attestations can be read and used by other systems, helping the value of contributions extend beyond the scope of a single organization. However, this also opens up new issues: if attestations are issued indiscriminately, then even if the technology is correct, the trust behind it becomes hollow.
Therefore, Sign not only changes the way verification is done but also forces us to revisit the core question: where does the data come from, and how do we assess the signer in a world where anyone can sign. $SIGN #SignDigitalSovereignInfra
The first use cases of @SignOfficial stem from this bottleneck when trust still lies in the backend. With Sign, after completing a task, the system will create an attestation: wallet A has performed action B at time T. When claiming, the smart contract only needs to read that data again, without needing an API or waiting for admin confirmation. This means verification is done once and can be reused multiple times.
The change, though small, is fundamental: the backend no longer “confirms again,” but simply records it once. This also applies in DAO, where previous contributions were stored on Notion or Google Sheet. With Sign, each contribution is signed as it happens, transparent about the signer and the time, without needing to confirm again.
More importantly, attestations can be read and used by other systems, helping the value of contributions extend beyond the scope of a single organization. However, this also opens up new issues: if attestations are issued indiscriminately, then even if the technology is correct, the trust behind it becomes hollow.
Therefore, Sign not only changes the way verification is done but also forces us to revisit the core question: where does the data come from, and how do we assess the signer in a world where anyone can sign. $SIGN #SignDigitalSovereignInfra
Is signing the weapon for building on-chain reputation in the future?
For me and the guys doing retroactive or hunting airdrops, the flow is probably not strange: connect wallet → popup appears → sign quickly to confirm participation in the campaign. The content usually states clearly: "I confirm that I have joined campaign X on date Y". I'm the same, quickly scrolling through and then clicking confirm as a habit. Usually, at this point, it's done, I close the tab to work on something else.
But that time, I don't know why I didn't close the tab immediately. In the corner of the screen, the app showed a small notification line: "Attestation created".
But that time, I don't know why I didn't close the tab immediately. In the corner of the screen, the app showed a small notification line: "Attestation created".
About 90% of the projects I have researched are related to Privacy, but the question I ask the most is: Why does privacy always provoke such strong reactions from regulators?
And this is my personal perspective.
It's not because they hate technology, but because they cannot see it. They dislike unclear and vague things.
In 2023, the U.S. Department of Justice prosecuted related to Tornado Cash. Approximately 1 billion USD is alleged to be money laundering. The reaction is not about the number but about the fact that they cannot trace the flow of money. Code is punished like humans.
@MidnightNetwork touches that sensitive point.
Not fully hidden like Monero. Not absolutely mixed like Tornado. It allows proof without revealing data. Sounds like the way the Financial Action Task Force wants the world to operate. Just enough information to audit.
But that's the problem.
According to Chainalysis, in 2024 only 0.34% of crypto volume is related to illicit activity. Small. But enough to shape policy. Regulators always look at the worst-case scenario. If users choose when to disclose, compliance becomes optional.
Midnight lies in between, and the middle ground is often the most dangerous. If it allows both compliant flow and non-compliant flow to coexist, regulators will assess based on the higher risk portion. No need for a majority, just a sufficiently large minority. An interesting point. Input Output Global designed Midnight with auditability in the whitepaper. They understand the rules of the game but cannot control how users play.
If Midnight can encode policy into proof, allowing only transactions valid under AML rules, it could become something regulators like. But then, it is no longer privacy in the sense that crypto once believed.
It's not about hiding or revealing, but who decides when to be seen.
$NIGHT #night
And this is my personal perspective.
It's not because they hate technology, but because they cannot see it. They dislike unclear and vague things.
In 2023, the U.S. Department of Justice prosecuted related to Tornado Cash. Approximately 1 billion USD is alleged to be money laundering. The reaction is not about the number but about the fact that they cannot trace the flow of money. Code is punished like humans.
@MidnightNetwork touches that sensitive point.
Not fully hidden like Monero. Not absolutely mixed like Tornado. It allows proof without revealing data. Sounds like the way the Financial Action Task Force wants the world to operate. Just enough information to audit.
But that's the problem.
According to Chainalysis, in 2024 only 0.34% of crypto volume is related to illicit activity. Small. But enough to shape policy. Regulators always look at the worst-case scenario. If users choose when to disclose, compliance becomes optional.
Midnight lies in between, and the middle ground is often the most dangerous. If it allows both compliant flow and non-compliant flow to coexist, regulators will assess based on the higher risk portion. No need for a majority, just a sufficiently large minority. An interesting point. Input Output Global designed Midnight with auditability in the whitepaper. They understand the rules of the game but cannot control how users play.
If Midnight can encode policy into proof, allowing only transactions valid under AML rules, it could become something regulators like. But then, it is no longer privacy in the sense that crypto once believed.
It's not about hiding or revealing, but who decides when to be seen.
$NIGHT #night
Why are companies still "afraid" of Midnight even though it solves the security problem?
I am wondering: Why is @MidnightNetwork so good, yet companies still hesitate to apply it? After thorough research, I realized that companies are not ignoring Midnight; they are avoiding a state that, if it occurs even once, is enough to be fatal.
In November 2023, in the U.S. Department of Justice's file on Tornado Cash, there is a small but very noteworthy detail. It's not about the amount of money. It's the legal argument: the system has "not been able to prevent use for money laundering purposes despite the ability to change the code."
In November 2023, in the U.S. Department of Justice's file on Tornado Cash, there is a small but very noteworthy detail. It's not about the amount of money. It's the legal argument: the system has "not been able to prevent use for money laundering purposes despite the ability to change the code."
Why does @SignOfficial "ignore" the DID standard?
Looking closely at the documents of @SignOfficial , I noticed a rather unique detail: they completely avoid the concept of Identity according to the W3C DID standard. Why does a project that has a full set of Attestation, Issuer, Verifier not build a proper DID profile? Seeing that 60% of crypto developers still ignore DID (according to Electric Capital 2024), I understand that they do not want to tailor their approach to fit the standard.
Identification in Crypto is not static
DID assumes that identity is a stable block tied to a wallet. But in reality, today you might be a Degen whale, tomorrow a contributor to a DAO, and the day after you might disappear. Sign chooses a different path, not building a flashy profile, but only recording fragmented pieces of truth (attestation).
The interesting part is verification at the time of use (at-use). Do you need to prove you are an Early User to receive an airdrop? One attestation from a reputable source is enough; there’s no need to pull out the DID for scrutiny. This method filters noise very well; where there is an error, it filters there, without ruining the whole profile. This is also a tough Sybil problem: Sign does not ask you who you are?, Sign asks What have you accomplished?. An attestation from Gitcoin always weighs more than an empty profile just created to secure a deal.
However, every issue has two sides, with Sigh it is the risk of Schema
Not following a common standard means that each project creates its own type of declaration form (Schema). Project A calls it Early User, project B calls it Loyal Member with a completely different structure. The result is a pile of fragmented data, like each country using a different type of passport, none of which can be scanned through each other's machines.
Sign bets on flexibility and practicality. Success lies in whether they can create a Meta-Schema strong enough to connect these fragmented pieces, or if it will become even more confusing in the heap of garbage data?
$SIGN #SignDigitalSovereignInfra
Looking closely at the documents of @SignOfficial , I noticed a rather unique detail: they completely avoid the concept of Identity according to the W3C DID standard. Why does a project that has a full set of Attestation, Issuer, Verifier not build a proper DID profile? Seeing that 60% of crypto developers still ignore DID (according to Electric Capital 2024), I understand that they do not want to tailor their approach to fit the standard.
Identification in Crypto is not static
DID assumes that identity is a stable block tied to a wallet. But in reality, today you might be a Degen whale, tomorrow a contributor to a DAO, and the day after you might disappear. Sign chooses a different path, not building a flashy profile, but only recording fragmented pieces of truth (attestation).
The interesting part is verification at the time of use (at-use). Do you need to prove you are an Early User to receive an airdrop? One attestation from a reputable source is enough; there’s no need to pull out the DID for scrutiny. This method filters noise very well; where there is an error, it filters there, without ruining the whole profile. This is also a tough Sybil problem: Sign does not ask you who you are?, Sign asks What have you accomplished?. An attestation from Gitcoin always weighs more than an empty profile just created to secure a deal.
However, every issue has two sides, with Sigh it is the risk of Schema
Not following a common standard means that each project creates its own type of declaration form (Schema). Project A calls it Early User, project B calls it Loyal Member with a completely different structure. The result is a pile of fragmented data, like each country using a different type of passport, none of which can be scanned through each other's machines.
Sign bets on flexibility and practicality. Success lies in whether they can create a Meta-Schema strong enough to connect these fragmented pieces, or if it will become even more confusing in the heap of garbage data?
$SIGN #SignDigitalSovereignInfra
Don't call it Identity, SignPass is the right to choose what exists.
The SignPass of @SignOfficial is not identity. It's how you choose which moments of your life are allowed to exist on-chain. I realized this not while reading the documentation, but while looking back at a very specific case.
In March 2024, a Sybil farming operation on Gitcoin Passport was exposed. Over 1.2 million “identity scores” were generated, but internal analysis showed that over 35% of accounts exhibited signs of automation. The system wasn't faulty; it was trying to gauge your identity by gathering all possible signals.
In March 2024, a Sybil farming operation on Gitcoin Passport was exposed. Over 1.2 million “identity scores” were generated, but internal analysis showed that over 35% of accounts exhibited signs of automation. The system wasn't faulty; it was trying to gauge your identity by gathering all possible signals.
Assuming @MidnightNetwork will replace Privacy Coin (like Monero) is a fundamental misunderstanding of demand. This is not a technology race, but a confrontation between two philosophies: Absolute privacy and Conditional privacy.
Traditional Privacy Coins are rough but sturdy "fortresses". They cut off all observation, require no explanation, and need no permission. In contrast, Midnight is an intelligent "filter". It doesn’t hide everything but only hides enough for you to be both private and able to prove validity (via ZKP) to the system.
Midnight allows for "selective disclosure". However, as proving becomes easier, it will become a mandatory requirement. Privacy shifts from a default state to something users must "justify". You are not forced to disclose data, but you are compelled to "prove in the way others want".
Midnight doesn’t kill Privacy Coin through technology, but by changing societal expectations. As pragmatic privacy takes precedence, the demand for absolute anonymity can easily be deemed "extreme".
Midnight does not replace Privacy Coin. They are two diverging paths: One maximizes personal freedom, while the other optimizes balance to integrate into the system. Midnight may win in user scale (mass adoption), but Privacy Coin remains the final refuge for those who refuse to "justify" their privacy.
$NIGHT #night
Traditional Privacy Coins are rough but sturdy "fortresses". They cut off all observation, require no explanation, and need no permission. In contrast, Midnight is an intelligent "filter". It doesn’t hide everything but only hides enough for you to be both private and able to prove validity (via ZKP) to the system.
Midnight allows for "selective disclosure". However, as proving becomes easier, it will become a mandatory requirement. Privacy shifts from a default state to something users must "justify". You are not forced to disclose data, but you are compelled to "prove in the way others want".
Midnight doesn’t kill Privacy Coin through technology, but by changing societal expectations. As pragmatic privacy takes precedence, the demand for absolute anonymity can easily be deemed "extreme".
Midnight does not replace Privacy Coin. They are two diverging paths: One maximizes personal freedom, while the other optimizes balance to integrate into the system. Midnight may win in user scale (mass adoption), but Privacy Coin remains the final refuge for those who refuse to "justify" their privacy.
$NIGHT #night
Monero, Aleo, Secret or Midnight: Which project truly addresses Privacy at its core?
There is a situation that I think many people have encountered, but rarely notice.
You send money to a strange wallet that could be minting an NFT, or trying out a new protocol. A few days later, you start receiving an airdrop, and then someone asks about that specific transaction. No one knows who you are, but it is clear they understand what you just did.
It's not being hacked. It's not about leaking information. It's just that everything is clear enough for others to piece together a story. And at that moment, I realized something a bit uncomfortable: on the blockchain, you don't need to reveal your identity to be read.
You send money to a strange wallet that could be minting an NFT, or trying out a new protocol. A few days later, you start receiving an airdrop, and then someone asks about that specific transaction. No one knows who you are, but it is clear they understand what you just did.
It's not being hacked. It's not about leaking information. It's just that everything is clear enough for others to piece together a story. And at that moment, I realized something a bit uncomfortable: on the blockchain, you don't need to reveal your identity to be read.
Login to explore more contents