Kinto is now a Stage1*Appchain
Kinto is the modular exchange. Access the best opportunities in DeFi through our tailored blockchain and non-custodial smart wallet, engineered for maximum security and seamless user experience.
TLDR:
- Kinto is now a Stage1 AppChain* marking an extremely important milestone in our commitment to user safety, decentralization and transparency.
- L2BEAT has been auditing and analyzing Kinto in detail for the past six months. Both teams worked together to understand where Kinto and other AppChains in the future will fit in the ecosystem.
- Kinto has in place a proof system, validators, a properly set up Security Council and escape hatches.
- Kinto extra security features and KYC systems require a redefinition of the L2BEAT stage framework.
What is Kinto?
Kinto is the first modular exchange. The modular exchange is built on decentralized technology, with non-custodial wallets and fintech level UI/UX. Featuring the best features from CEX like fiat onramps and account recoverability without becoming a honeypot of user’s private information.
The modular exchange is non-monolithic and permeates every layer of the stack. Each layer is built upon the leaders of DeFi. Same way the apple store is not a separate application that you need to visit before opening a mobile app or the browser is not a separate app that you need to use before browsing a site. They are seamless integrated experiences.
One of the technological layers that make Kinto possible is its custom L2 rollup to provide gasless transactions and preserve the KYC/AML compliance requirements.
Today we are announcing Stage1 AppChain* status for our L2 rollup.
What is L2BEAT and what role do they play in the ecosystem?
L2BEAT is a non-profit organisation that is dedicated to bring forward to end-users all the trust assumptions that are associated with Ethereum scaling solutions. This requires constant monitoring of hundreds of systems that are already in production, assessing every change that is associated with either an upgrade or a change to an important security parameter and informing end users about the various rollup parameters such as total value secured, finality, history of upgrades, current security and trust assumptions, etc…
What does it mean to be Stage1?
In November 2022, Vitalik wrote a post about trust in rollups. While all L2s start with necessary training wheels that allow to operate (and therefore to a degree censor), the rollup they should strive to remove these training wheels in a clear roadmap to become fully-trustless and governed by code alone.
As a result and in due time L2BEAT defined their “stages framework” that became the roadmap for all of those committed to decentralized and secure rollups. This of course included Kinto.
Intuitively Stage1 systems are somewhere between Stage0 systems that are managed by team’s internal MultiSigs and Stage2 systems that are fully managed by smart contracts. They are required to have a fully automated proof system that — in exceptional circumstances — could be overridden by a special MultiSig called a “Security Council” that should comprise a diverse set of independent participants with high reputation. They should allow users to circumvent the typically centralised and privileged sequencer in case users are censored by it.
The exact requirements for an L2 to be called a “Stage1 system” that need to be met evolve along with the space that is in constant search of new, innovative scaling solutions.
As of today being Stage 1 means:
- Having a proper proof system. Kinto as a fork of the Arbitrum Orbit stack benefits from Arbitrum’s interactive fraud proofs.
- There are 5 external actors that can submit fraud proofs on Kinto. Five Industry leaders are in charge of running these validators and have been whitelisted for this task by the Kinto Foundation.
You can learn more about current validators and how to run one in our docs:
https://docs.kinto.xyz/kinto-the-modular-exchange/security-kyc-aml/kinto-validators
If you want to learn more about validation strategies, Arbitrum has an excellent page in their documentation as well:
https://docs.arbitrum.io/run-arbitrum-node/more-types/run-validator-node#validation-strategies
- Kinto has a properly set-up (and publicly disclosed) Security Council.
The Security Council is a group of 8 signers of a Gnosis multi-sig wallet, which has powers to perform certain Emergency and Non-Emergency Actions (technical upgrades), as delegated to it by the Kinto DAO and the Kinto Foundation. It is responsible for upholding critical aspects of the Kinto Constitution. The Security Council is of course subject to oversight and control of all DAO members.
The Security Council is represented in the following multisig: https://app.safe.global/home?safe=eth:0x17Eb10e12a78f986C78F973Fc70eD88072B33B7d
- In Kinto users have at least seven days to exit in case of unwanted upgrades (excluding Security Council and governance decisions).
Any and all new hard forks or technical upgrades require now Security Council 6/8 votes. For all other cases a series of time locks have been implemented to guarantee those windows (like this, or this, among other changes that can be seen in our GitHub).
However, bad actors can be stopped from leaving the chain if they are sanctioned and those sanctions are later confirmed by the Security Council demonstrating Kinto’s strong security system and bringing us to the final point below.
- In Kinto users can exit without the operator’s coordination.
Thanks to the well known (and now fully tested by Kinto) retryable tickets from our Arbitrum stack users can force any transactions (including those that require Kinto Wallet signatures and EntryPoint access), such transactions cannot be stopped by let’s say a compromised sequencer or other bad actors in the operator side.
However, once more, Kinto’s security takes precedence over this feature and while the team cannot stop users our KYC/KYT/AML/OFAC automated systems can and will sanction a bad actor stopping them from removing funds from the chain until these sanctions are either confirmed by the Security Council or allowed to expire.
However, we do understand that the differences between Kinto and what can commonly be understood as Stage 1 requires an explanation which is why we have invited our friends at L2BEAT to co-author this article and explain…
… why the asterisk*?
Rollups, and more generally L2s are typically thought of as scaling solutions for Ethereum allowing to offload computation from the main chain that is only tasked at verifying the correctness of a new L2 state resulting from the execution of the batch of transactions rather than validating and executing every single transaction in the batch.
The design space for rollups is not restricted and it allows infrastructure developers not only to build general purpose, permissionless chains similar to Ethereum but also chains that impose various restrictions on the users of these chains. To be more specific we can imagine chains that:
- restrict the functionality of a chain to specific functions such as payments, trading, gaming
- restrict access to a chain to a specific group of users via various mechanisms such as whitelists, compulsory usage of specific wallets and/or addresses
- enforce use of specific tokens (for example Omnichain Fungible Tokens — OFTs) for gas payment imposing additional trust assumptions that are specific to transfers of these OFTs
- Implement custom sequencing rules prioritising certain classes of users and/or operations
L2BEAT uses a general umbrella-term for chains that are not fully permissionless and general-purpose: AppChains. Given Kinto’s specific architecture and enforcement of KYC rules via restrictions imposed on EOA-initiated transactions by node software, according to L2BEAT’s definition, Kinto is a good example of such an AppChain.
General purpose, permissionless L2s can host various applications that impose on users different sets of trust assumptions. For example to use $USDC one needs to trust Circle. To use various DeFi protocols one needs to trust governance of these protocols that can potentially upgrade their contracts, often with no delay. At the same time users are free to choose permissionless tokens and immutable applications that do not impose any additional trust assumptions other than the chain itself.
In contrast to general purpose chains, restrictions imposed by AppChains affect every single AppChain user and to fully understand the nature of these restrictions one needs to analyse both the infrastructure-level trust assumptions and application-level restrictions where the line between the two is somewhat blurry.
The application of the current version of Stages framework to AppChains is somewhat tricky as the intuitive guarantees that come with the Stage designation (for example users should be able to always withdraw their tokens) may not hold place given the restrictions imposed by the AppChain. It is worth noting though that even in general purpose chains such guarantees are also application dependent — as noted before withdrawing $USDC from a permissioned DeFi protocol may depend not only on the Rollup itself but also on Circle and DeFi protocol governance team.
L2BEAT is working on a more comprehensive Stage framework for AppChains that will specify in details the guarantees of a given chain, for example:
- It is possible to deposit and withdraw ETH
- It is possible to withdraw deposit and withdraw a ERC-20 token unless the token itself prevents that action
- It is possible to send an arbitrary message from L1 → L2 and from L2 → L1 that cannot be censored by the operator
This will require a detailed analysis of every single AppChain along with building a custom, bespoke monitoring gadget that monitors the trust assumptions of the AppChain continuously.
In the meantime, L2BEAT, along with the standard Stage designation, will display the warning for every single AppChain so that users are aware that there are some additional restrictions that should be further investigated if they want to fully understand associated trust assumptions
Final thoughts and where to learn more
Kinto’s commitment to transparency, security and decentralization does not end here. In the next few months Kinto will continue to work towards providing L2BEAT and the community at large with custom monitoring features that allow anyone to check the unique features of our chain.
In addition to this we are excited to continue to work towards further decentralization and get Kinto to the almost mythological Stage 2 starting with implementing in a future hard fork fully decentralized fault proofs thanks to Arbitrum Bold.
About the authors
Bartek is a long-time Ethereum researcher and entrepreneur. Having spent many years working in various capacities for MakerDAO he founded L2BEAT, a research organization focused on scaling and interoperability of Ethereum. In his pre-blockchain life he worked on building software for the financial sector. He holds PhD in computer science from Queensland University of Technology.
Víctor is a developer, lecturer and entrepreneur. He co-founded Kinto.xyz, the first crypto modular exchange and previously ran mashme.io that provided video collaboration applications to universities and companies all over the world with users in 71 countries. For the last couple of years, Víctor has been organizing tech events and conferences for kids and adults at places like Hack4Good Spain or JuntosDesdeCasa — in order to extend computer science and STEM. He has been recognized by Google as a “Google Developer Expert in Web Technologies” for the past 10 years.
Join us!
