Galactica Network’s Key Technological Pillars

Overview

Among Galactica Network’s primary value propositions is that of leveraging zkKYC for Sybil resistance thereby enabling meaningful modeling of real-world societal, financial, and political institutions on-chain. An extremely valuable byproduct of this setup is a protocol that enables regulatory-compliant privacy.

Figure 1: Galactica Network overview

As can be seen in Figure 1 above, the technological core enabling Galactica Network, aside from its foundation of EVM smart contracts, rests upon four key technological pillars; zkCertificates, the Reputation Root Contract, Contingent Transactions, and Oracle Nodes- each of which will be explained in this article.

These are innovations distilled from relatively recent developments within the Web3 space, and as we’ll explain in the following sections, they are the keystones enabling Galactica Network.

zkCertificates

Zero-knowledge Certificates (zkCertificates) find their intellectual roots in Peter Pauwels’s whitepaper; “zkKYC: A solution concept for KYC without knowing your customer, leveraging self-sovereign identity and zero-knowledge proofs” in June of 2021, which introduced the idea that Zero-Knowledge cryptography could in fact be applied to the realm of KYC and AML/CTF. The whitepaper; “Decentralized Society: Finding Web3’s Soul”, developed the link between soulbound tokens (SBTs), initially discussed by Vitalik Buterin by his blogpost; “Soulbound”, and how they can enable forms of Sybil resistance and are instrumental to catalyzing deeper societal substrate across web3 protocols (i.e. enabling decentralized societal institutions). The whitepaper has rapidly become a principal work when discussing the future of Web3 governance and is a vital piece of literature underlying the creation of Galactica Network.

Galactica Network’s zkCertificates are non-transferable NFTs with arbitrary metadata that come with an option of selectively disclosing said metadata through the use of zero-knowledge cryptography. zkCertificates can be implemented in a variety of ways, some vanilla, and some more exotic in nature, the lowest-hanging fruit being the aforementioned zkKYC.

One of the key applications of zkCertificates is that of Galactica Network Citizenship; an SBT that once obtained grants the owner rights and responsibilities within the Galactica Network. The only condition that is needed to be eligible for Citizenship is obtaining a zkCertificate by passing Galactica Network’s Oracle Node process.

Beyond Citizenship, zkCertificates can be utilized for a variety of other applications. zkCertificates can be implemented in nuanced applications such as zk-Diplomas, which can store detailed records of a student’s degree, scores, classes, and much more; all of which can be embedded into their Galactica Citizenship or another soulbound token and then selectively disclosed.

Leaning into more advanced areas, the encrypting of medical data records and other forms of PII/PHI, voting data, government records, and citizen data (think taxes, property titles, etc.) via zkCertificates. It fits use cases such as machine learning algorithms that can verifiably be used and paid for directly on-chain without exposing the data sets used to train the models, nor the models themselves. zkCertificates are further explained in the Whitepaper, Appendix I — Galactica’s Zero-Knowledge KYC Design, in the Further Considerations section.

Oracle Nodes

The second technological pillar of the Galactica Network is its native Oracle Nodes, which exist to facilitate among other things KYC within the Galactica Network ecosystem. Users can submit their KYC requests, then these requests are sent to a set of Oracle Nodes that verify user documentation; either approving or disapproving their authenticity by cryptographically signing the user’s account.

Figure 2: Initial KYC steps, incl. privacy aspects

The Nodes handling these activities are whitelisted at the inception of the network and will include large institutions, such as exchanges and large wallets. The KYC data is stored in multiple locations:

1. At the KYC centers’ back office systems, where the data is entirely off-chain;
2. And on users’ personal devices, (mobile, desktop, or otherwise);
3. In an encrypted manner on-chain available to the particular user.

More importantly, however, is that by design KYC providers cannot associate a set of documents with the user’s on-chain account. In other words, while a KYC provider knows that it has checked the authenticity and veracity of KYC documents, (this much is known to anyone as every KYC provider runs its own Node), the link associating an account with an off-chain KYC record is encrypted. This result is achieved through applying MPC techniques and several custom SNARK libraries, which are open-source and are used extensively in the Galactica KYC SDK.

Figure 3: KYC Record Creation and Verification.

Documents at the KYC center and the account it belongs to are linked in such a manner that they can be decrypted through Shamir’s secret sharing scheme with at least m of n notes made available to the responsible authorities. For example, there are two notes with an account, one note with a regional enforcement agency (police department or similar), and one note with the KYC provider. There could be an account with three notes, the first two the same as in the previous example and the third with the Galactica foundation.

As a final note, users’ KYC data feeds into a zkCertificate registry smart contract and zkCertificates are issued by KYC centers. As noted the KYC data is stored on the user’s device; and, after zkCertificate is created, that device can be used for ZK proof generation for selective disclosure. This is how users can interact with protocols and perform said selective disclosures to verify specific aspects of their account with the smart contract or DApp. A deeper analysis of Oracle Nodes can be found in the Whitepaper Appendix I — Galactica’s Zero-Knowledge KYC Design, in the Overview of the Technical Design section.

Consider the example of AML proofs — quick generation of proofs that all the accounts registered under one’s name have only interacted with liquidity of KYC’ed users without revealing any other information. One can generate programmable proofs of compliance without giving up one’s privacy;

Reputation Root Contract (RRC)

The Reputation Root Contract (RRC) is a protocol primitive that, when fed a user-defined function that takes on-chain data as input, outputs a unique Reputation Score for every account. This contract can also take a user’s ZKP as additional input to prove statements about data hidden in zkCertificates. This ZKP is only needed as additional input if the reputation function depends on selective disclosures of personal data hidden in zkCertificates.

In layman’s terms, it slices the web3 footprint of a persistent identity to generate custom user-defined (or DApp-defined) reputation scores. In this fashion, DApps (and even protocol governance itself) can be designed to reflect the merit rather than the mere number of tokens held.

Figure 4: Reputation Root Contract

An important note is that there are two distinct forms of reputation functions:

1. The first type depends only on public, on-chain data, this can be calculated by everyone for anyone because it uses public data. The function works for only one address and only with the data the user has already publicly disclosed on-chain.
2. The second type partly depends on private data hidden in zkCertificates, it can use information hidden therein to include KYC details, education certificates, links addresses. But it can only be computed by a person for himself and needs a ZKP for on-chain verification. In other words: for reputation functions of the second type, one can not get the reputation score directly. Instead one has to prove their reputation score with ZKPs to keep the data private.

Reputation is a key ingredient to Galactica Network’s value proposition. The RRC’s unique malleability affords projects the ability to cultivate a specific user base for each of their products or governance systems.

Contingent Transactions

With the importance and use of the RRC established, the ability to whitelist and screen users or interactions allows much greater scope for innovation in the field of user interactions; Galactica Network, and many others, denote this area as “Contingent Transactions”, and any account may utilize the output of the RRC, to create their own sophisticated rulesets when interacting with other users of Galactica Network.

Figure 5: Example, simplified RRC interaction

In more digestible terms contingent transactions can be understood in several key ways:

1. First, the output of the RRC can be used to determine whether an account is allowed to submit a transaction to another account. An example could be a KYC’ed user can interact with leveraged DEX only after proving that one is: (a) over 18 years old and (b) is not a resident of a prohibited jurisdiction.
2. Secondly, the inner logic of a decentralized application (DApp) can be conditioned upon the score produced by the RRC to enable specific functions, products, and more. With that in mind, scenarios where Oracle Node approved users are allowed to borrow at a 90% collateral ratio, while non-approved users need to post 200% collateral, become feasible.

Contingent transactions have use cases beyond the scope of the financial interactions detailed above; they are capable of supporting extremely niche use cases creating space for more complex rules of interaction. While seemingly trivial at the outset, the significance of contingent transactions cannot be understated, especially when combined with other primitives discussed above. More details on contingent transactions can be found in the Whitepaper in the Contingent Transactions section and in Appendix II’s Galactica’s Reputation Framework Design section.

As a small disclaimer for this section, Contingent Transactions are still very much WIP. The ultimate design is subject to change.

The four technologies outlined in this article are both the technical basis of all mechanisms found on the Galactica Network, and the pillars upon which its institutions, derivative institutions, and ideas that guide the protocol rest. zkCertificates, the RRC, Contingent Transactions, and Oracle Nodes are the framework that will allow the teams building on Galactica Network to unlock the full potential of what the protocol has to offer.

Case In Point

The authors of a recent article [1] by a16z on privacy, regulation, and ZKPs note:

“Reconciling the privacy needs of users and the informational and national security needs of regulators and law enforcement is both possible and necessary.” p. 2

In this sense, the articles released so far as well as the remainder of the documentation provided, hint, among others, that there is a practical possibility to meet the needs of users and satisfy the requirements of regulators alike.

For example, compliant privacy roll-ups and DApps whereby users can retain the privacy of transactions without compromising compliance. If a privacy roll-up is accessible exclusively to KYC’ed users and supports the generation of arbitrary proofs about transactions settled therein (e.g. one’s only counterparties are one’s employees and all transfers are <$10,000), it manifests a full privacy solution with effective AML proofs. With that in mind our Oracle Node solution introduces a more nuanced, pragmatic check of deposits and withdrawals. Users’ identities can be verified and cross checked with sanction lists, or rulesets that prohibit or track specific users without locking users into specific addresses. Thus they can still use fresh wallets to improve privacy while still proving compliance. The figure that follows illustrates graphically the example above:

Figure 6: Compliant Privacy Interaction Example.

The strength of our approach is found in its generality. Our Oracle Node system, reputation and selective disclosures can not only be applied to the aforementioned deposits, withdrawals and retroactive transaction proofs, but also during each on-chain transaction. This can provide proactive compliance, even for activities that stay inside the on-chain ecosystem.

Website | Medium | Twitter | Reddit | Telegram Announcement | Deck | Contact Us | Discord