Ill be honest the private transaction feature will be incredible later on mixed in with xgov-108 if this goes ahead since this has offline signing aswell. Fully airgapped. What a great combo … this ill be honest a private transaction feature will bring an entirely new perspective on this coin and ppl will stop calling it a government coin or cbdc and it will bring entire new users onboard. Privacy is a hot topic in this era of suppression and cancellation culture
VERSEWARE PTY LTD
is now a registered Australian Proprietary Limited company, which legally represents Zorkin in trade and commerce. The entity will also represent most (if not all) business activities I conduct in this space.
In the proposal, “Helium Labs” is a placeholder for VERSEWARE PTY LTD
.
I may rename the company sometime in the future, but it’s honestly fine. The name sounds good, and I’ve thought about existing trademarks and don’t see any cause for concern.
I agree privacy is important. While I’m open to considering privacy-enhancing features in the future, I cannot make any promises as previously mentioned. The current focus is on the core experience per the proposal.
Private transactions often face legal restrictions due to their potential for facilitating crimes (e.g. Tornado Cash). Privacy features we implement, if any, will be legal and ethical.
Having thought about it, chances are I won’t add private transactions of any kind, however other types of privacy-enhancing features will be considered for inclusion.
Notes:
- My understanding is certain types of private transaction, such as using a single record-keeping custodian or engaging in non-monetary exchanges, may be legally permissible. Further due diligence is essential.
- This post is not intended as legal or investment advice. Please conduct your own research.
Thanks .
just an FYI ZEC is sold in every exchange without any issue maybe the exchange has certain rules you must abide by and i agree if the exchange says mst be unsheilded then thats what you must do but between 2 private parties why cant you make a shielded TX ., by the way most exchanges i have seen in Aus sell monero if the exchange doesnt allow shielded it will stipulate , and its only an option if the wallet provider decided to implement it. Some countries require this privacy from their tyranical goverments, oThat is why the standard transaction is non zk-snarks you have to decide wether you want to make this transaction or not , z-cash has been approved by some government entity which is basically the same it has shielded and non shielded unlike monero where it is the standard and you must transact privately
I have a bunch of updates regarding xGov119 (Zorkin). It is difficult to speak in absolutes since AF’s WebAuthn solution is still a work in progress. I welcome corrections for any unintended inaccuracies in my interpretation.
AF Webauthn vs. Zorkin: A Clarification
I want to clarify once again the significant differences between the Webauthn approach that AF is developing and Zorkin. Let me explain.
My understanding is that AF is developing a Webauthn authentication method without an OAuth provider, initially focusing on authentication and then transaction authorization. Below, I compare this to Zorkin.
Webauthn for OAuth Authentication
OAuth2, utilized by Zorkin, can use Webauthn as an authentication factor if offered by the OAuth provider. This inherits the provider’s setup, such as passkeys and Web2 account recovery options (for example, see Google Webauthn).
After OIDC authentication, a user can authorize transactions from a linked Algorand account, with access proven via a ZK-SNARK proof through Zorkin.
Zorkin’s Additional Efforts
Zorkin will provide additional features such as simplified Asset Opt-In and a Fiat On-Ramp. I’m fairly certain AF won’t go this far, focusing solely on auth.
Integrating Zorkin Seamlessly
A business can integrate Zorkin seamlessly, enabling existing users to access a linked Algorand account, assuming they use a supported OAuth provider.
Conversely, WebAuthn alone would require explicit linking to existing user profiles and, without passkeys, ties the authentication factor to a specific device. It’s unclear if AF’s solution will include passkeys.
In short, Zorkin can use a number of OIDC authentication methods, including Webauthn, depending on what is supported by the chosen OAuth provider. With the fiat on-ramp and other features, it will provide a nearly frictionless Algorand onboarding experience.
Open-Source Licensing with the Apache License v2 (APLv2)
I have decided to make all source code for xGov119 software deliverables available under APLv2 to the fullest extent legally possible, if the proposal passes this xGov session. This does not mean the service will be free to use; charges will still apply for usage.
Should the proposal not be approved, I retain full discretion over its future. In such a scenario, I cannot commit to releasing the product or making it open source.
Approaching the Finish Line
Finally, the proposal is close to achieving 90% of votes needed to pass. In these final moments, your support is crucial to help it succeed. I will devote all my energy to fully realizing its potential, if it passes.
The funding will primarily cover my salary for several months of intense R&D work and any incidental expenses I may incur along the way, such as a hypothetical registration fee or external freelance tasks, like creating a marketing website.
For more details, see the proposal on GitHub with its video demo. GovernorHat on Twitter ranked xGov119 with a select few in the S-tier after thoroughly reviewing them all.
Give this man a vote already! almost there brother, you’ll make it.
I would like to clarify a few things I’ve said so far in case I have miscommunicated them unknowingly. Please understand the following:
Clarification on APLv2 licensing
By saying the source code is licensed under APLv2 where legally possible, I mean in respect of any license terms I must oblige by such as copy-left licenses, and such. Anything that may legally compromise me will be respected first and foremost. Read about APLv2 online to understand how that license works.
Clarification on Self-Custodial meaning
By self-custodial, I mean user assets are not actively managed and the sensitive user access keys are not in direct control of Zorkin (i.e. assets won’t be in my custody). However depending on how it’s implemented, parts of the implementation will require innate trust in a 3rd party to not act maliciously. It is almost unavoidable, even in most respectable self-custodial wallets I won’t name.
Examples of how trust is required include compromised client code integrity (e.g. a frontend or app is updated to use a hidden malicious version), or more specifically in Zorkin’s current design having the Chainlink SC be updatable to allow updating OAuth provider JWK signing links should they change.
I will do everything I can to ensure the trust is minimized and security is maximized at every opportunity. For example having client-code integrity verification by having a webapp build to a single file whose hash can be verified in the client, DNSSEC/DNSLINK, open-source code, and consideration of a DAO for community voted upgrades to infrastructure with immutable versioning.
These are examples of small design choices that may be made during development should this project be funded. This is to be expected as the proposal is R&D intensive and not fully complete, which is why I was liberal with disclaimers and vagueness in the proposal.
Deliverables
Following on from the last section, since it’s R&D intensive, please understand the final concrete design will of course be different to some degree. There are numerous small design choices that are yet to be made, as I continue to refine and iterate. But rest assured the high level gist, “Self-Custodial social login to authorize transactions with ZK-SNARKs”, will be delivered by EOY if passed. The way that is achieved and presented will inevitably evolve during development. Where “self-custodial” is the definition given, as clarified above.
I look forward to the outcome. If you have any questions please let me know and I’d be happy to answer.
I mistakenly believed I had signed the contract by completing the Google Docs form. However, I now realize a Docusign digital signature is also required, which will be delivered separately. Sorry for any confusion. I’ll keep you updated.
I’m reviewing the contract again to ensure I haven’t accidentally overlooked or misunderstood any crucial details. For instance, I may need to do more than write articles to fulfill the promotion part of the “purposes” as defined in the contract. I’ll inform you if I decide to modify my plans, such as my promotional strategy, to satisfy that requirement.
As explained earlier (see the proposal), given that this is an R&D-intensive project that is non-trivial, expect things to change within some reasonable tolerance. For example, I may code something one day and write an article (or make a public Git commit), and then iteratively refine it later after discovering a better way to do something for the betterment of the project.
Disclaimer:
As always, nothing I say is intended to be legal or financial advice. I’m not a lawyer or financial professional. While I believe my layman interpretations of the contract are accurate, please seek professional guidance if you have the same contract.
Business Entity
I recently registered the Australian company Inter Auth Systems Pty Ltd
last night. This company signed the contract and assumes full legal ownership and responsibility for the proposal and intended business. What I meant in saying “I may rename the company sometime in the future” above, is that I may change the company and that’s what I’ve done.
Please disregard the above business entity I have previously mentioned. As explained, Helium Labs in the proposal is a placeholder, and it is actually my Github organization, which I’m going to rename.
I am currently receiving legal advice regarding the open-sourcing of the solution. Once I have received the necessary guidance, I will prepare a statement addressing the matter. I will share the statement as soon as it is ready.
Yo only need to create an article after deliverables are completed. The main purpose of the article is for the community to try out your product and also to know the benefits the product may offer.
So the article should be less of a tecnical thing.
Zorkin: Beta Release & Design Document Expectations
Hi Everyone,
I have an update regarding Zorkin, which I’ve been working on.
I’m nearing a beta release of the product, which will hopefully be ready for testing by Friday. It should have all the core features to be approved for the xGov grant, except for legal consultation and the on-ramp integration.
If you’d like to sign up for the beta release, please register here: Beta Release Signup.
I’ve made several refinements to Zorkin’s architecture since the first version of the design document. These changes are publicly documented here: Zorkin GitHub Repository.
I want to make it clear that the repository, along with any related public musings, is not a roadmap of expected features. Most of the features listed there won’t appear in the xGov release. It’s a place to record my design thoughts as they develop, particularly in a public space to guard against patents.
Zorkin is research-intensive, as it’s a full-on product and startup that hasn’t been done before. This means we can’t realistically predefine all the features upfront. Instead, we’re delivering the promised big picture, which is what I’ve focused on. That’s why I emphasized that the design documents are subject to change and shouldn’t be considered a roadmap of features that will definitely appear in the release.
The big picture will be delivered as described in the actual grant proposal, which specifies a list of high-level deliverables to expect if all goes well. You can view it here: Grant Proposal Document. It’s nearly done, and I’ve made several refinements over time. Some specific approaches, like the initial architecture described in the early design document, likely won’t be followed as they’ve been revised.
For example, I have decided it’s best not to verify RSA signatures within the circuit and instead do it on-chain. I’m currently adding modular exponentiation as a new opcode to Algorand, which will hopefully be available in AVM 11. You can see more details here: Algorand Issue #6139. This innovation was only recently conceived, which means the old design will not be followed.
If you have any questions, please feel free to ask.
Kind regards,
Winton
Announcing the Release of Beta v1
I’m excited to announce that beta v1 is available today. Unfortunately, due to time constraints, not all features could be included. These features will be added in subsequent beta releases. Please see the email sent to participants below:
Hi everyone,
We are excited to announce that the Zorkin Beta v1 Testing Program is now open to all who signed up via our Google form. This closed beta is designed to minimize cloud resource usage due to the prover’s compute-intensive nature and will remain available until further notice.
What’s Included in Beta v1:
- Demo Frontend on the Testnet: Experience the functionality firsthand with our demo frontend.
- Early Access to the Zorkin SDK: Provide your valuable feedback as you explore the SDK.
- Open-Source Components: The demo frontend and Zorkin SDK are open-source, allowing you to view and contribute to the code. While most of the backend infrastructure remains closed-source, the prover-server and MIMC hasher are available for your review.
We will continue to add new features in waves leading up to the production release. Looking ahead, Beta v2 will introduce a dashboard for provisioning Zorkin instances and a billing system.
Next Steps:
-
Try the Testnet Demo: Access the demo by signing in with the same Google account you used to register. Please note that email addresses not associated with a Google account cannot access the program due to our Google sign-in authorization method. If you’re using a non-Google email, please fill out the form again using a Google email address.
-
View Source Code: We welcome your feedback on the demo source and the Zorkin SDK source.
A follow-up survey will be sent later for you to provide your feedback on Beta v1.
Thank you for your participation and support. We look forward to your feedback and collaboration as we work towards the production release of Zorkin.
Best regards,
Winton Nathan-Roberts
CTO of Inter Auth Systems Pty Ltd
Disclaimers:
Please be aware that the beta program is provided “as is” without any warranties or liabilities. Features present in the beta, and any claims made, are not guaranteed to appear in the final release, as our work is research-intensive and subject to change. Any misrepresentation is unintended.
Beta v1 Testing Completed – Thank You & Upcoming Feedback Survey
Hi everyone,
Thank you for testing the Beta v1 release. The testing phase has now concluded, and we have gathered valuable insights from your feedback. We will be sending out a survey soon to collect additional input from all participants.
Please note that the prover server has been disabled, so authorization attempts will no longer be successful.
Kind regards,
Winton
Announcing Beta V2: New Features Now Available for Testing
Hi everyone,
Beta V2 is available for testing.
-
Beta V2 is the second stage of Zorkin’s Beta Testing program.
-
This stage introduces new features that closely resemble the production release, including splitting proof generation into two parts for speed gains, a dashboard to set up Zorkin instances, and the ability to manage your Zorkin subscription via Stripe. Additionally, various bug fixes have been made based on feedback from Beta V1.
If you’re interested in participating, you can follow the instructions here to create your own client and use it on your website to authorize your users.
Alternatively, you can test the new version without creating your own client by using the dashboard at Zorkin’s Demo Frontend.
Please note that only users registered for the beta program can access the dashboard. It will remain live until further notice. The focus of testing should primarily be on usability issues, bugs, and suggestions for improvement. Questions are welcome, and I appreciate your interest and assistance with testing.
Kind regards,
Winton
Disclaimer:
Please be aware that the beta program is provided “as is” without any warranties or liabilities. Features present in the beta, and any claims made, are not guaranteed to appear in the final release, as our work is research-intensive and subject to change. Any misrepresentation is unintended.