Proving you're clean without handing over your customer list: there's a way
The most awkward thing for an institution entering the space is wanting to prove it's clean without handing over its customer list. There are basically two approaches today. One is to give addresses and transaction histories to an on-chain analytics company for scoring, which is equivalent to laying all your cards on the table for a third party. The other is to use a Merkle whitelist, which can only prove that a particular address is in a set—not that the set itself is clean. I tried a third approach using SXT's private data pathway: put the internal list and the public list of restricted addresses into the same set of tables, then have a query return a Boolean value along with a proof. You disclose only the conclusion, not a single record. The potential of this use case is greater than most people think. You could do proof of reserves this way, sanctions screening, or even prove whether a customer's assets meet a certain threshold—all by outputting only a yes-or-no result. The real technical challenge is keeping things current. The list changes every day, so the proof has to be regenerated too; otherwise, you're proving you were clean last week. I learned that the hard way once: I used an old proof to verify a new list, and the contract told me everything was fine. That gave me a chill. After that, I learned to include a hash of the data version in the proof, and to reject it outright if the version doesn't match. The bottleneck isn't cryptography; it's the list itself. Who maintains it, how often it's updated, and whether its update history can be audited—these are operational issues. Get those wrong, and none of the rest matters. And whether the law recognizes cryptographic proofs is still an open question; compliance officers would rather see a stamped report. Compared with Chainlink's proof of reserves, this approach is more flexible: it can run arbitrary SQL, not just sum balances. The trade-off is that you have to take on the engineering work of generating the proofs yourself. I expect RWA and custodial institutions to adopt this first, because what they need most is that layer of assurance that lets them prove things about themselves without disclosing sensitive information. To take it further, you'd need to combine range proofs with aggregation proofs—for example, proving both that total exposure is below a limit and that no single counterparty exceeds its limit. There's no off-the-shelf tool for this yet, so you'd have to build it yourself. Once this layer is running smoothly, institutional sales pitches will change from “Our risk controls are strict” to “You can verify it yourself.” #sxt $SXT @SpaceandTime
The most awkward thing for an institution entering the space is wanting to prove it's clean without handing over its customer list. There are basically two approaches today. One is to give addresses and transaction histories to an on-chain analytics company for scoring, which is equivalent to laying all your cards on the table for a third party. The other is to use a Merkle whitelist, which can only prove that a particular address is in a set—not that the set itself is clean. I tried a third approach using SXT's private data pathway: put the internal list and the public list of restricted addresses into the same set of tables, then have a query return a Boolean value along with a proof. You disclose only the conclusion, not a single record. The potential of this use case is greater than most people think. You could do proof of reserves this way, sanctions screening, or even prove whether a customer's assets meet a certain threshold—all by outputting only a yes-or-no result. The real technical challenge is keeping things current. The list changes every day, so the proof has to be regenerated too; otherwise, you're proving you were clean last week. I learned that the hard way once: I used an old proof to verify a new list, and the contract told me everything was fine. That gave me a chill. After that, I learned to include a hash of the data version in the proof, and to reject it outright if the version doesn't match. The bottleneck isn't cryptography; it's the list itself. Who maintains it, how often it's updated, and whether its update history can be audited—these are operational issues. Get those wrong, and none of the rest matters. And whether the law recognizes cryptographic proofs is still an open question; compliance officers would rather see a stamped report. Compared with Chainlink's proof of reserves, this approach is more flexible: it can run arbitrary SQL, not just sum balances. The trade-off is that you have to take on the engineering work of generating the proofs yourself. I expect RWA and custodial institutions to adopt this first, because what they need most is that layer of assurance that lets them prove things about themselves without disclosing sensitive information. To take it further, you'd need to combine range proofs with aggregation proofs—for example, proving both that total exposure is below a limit and that no single counterparty exceeds its limit. There's no off-the-shelf tool for this yet, so you'd have to build it yourself. Once this layer is running smoothly, institutional sales pitches will change from “Our risk controls are strict” to “You can verify it yourself.” #sxt $SXT @SpaceandTime
