ZKX Explained: Gamified Perp Trading in the AppChain
In this article, we explore what Application Chains are, the pros and cons of such solutions, and how ZKX works with gamification of the trading process.
Disclaimer: The content presented in this article, along with others, is based on opinions developed by the analysts at Dewhales and does not constitute sponsored content. At Dewhales, we firmly adhere to a transparency-first philosophy, making our wallets openly available to the public through our website or DeBank, and our articles serve as vehicles for self-expression, education, and contribution to the ecosystem.
Dewhales Capital does not provide investment advisory services to the public. Any information should not be taken as investment, accounting, tax or legal advice or as a recommendation to purchase, sell or hold or to pursue any investment style or strategy. The accuracy and appropriateness of the information is not guaranteed by Dewhales Capital.
1. Introduction: A Brief Look Into Application Chains
2. Examples of Application Chains
3. Upsides of AppChains
4. Downsides of AppChains
5. Quick Summation
6. AppChain Design Considerations
7. Introducing ZKX - Built on Starknet
8. Product overview
9. Tokenomics
10. Backers
11. Conclusion
1. Introduction: A Brief Look Into Application Chains
When we take a look at the blockchain landscape across various ecosystems, technology, consensus mechanisms and approach, it shows how proliferated the Web3 space has developed and how complex protocol dependencies with each other have become. With that, the number of verticals and applications have also grown, and their performance needs have increased over time with the expectation of user experience. With multiple general layer ones not being able to keep up with the demand of these applications, especially when it comes to customization and robust business models that scale.
Application chains are not a new concept however and their designs are not limited to monolithic blockchains but modular execution layers as well. Rollups and sidechains are great examples of how a split in the infrastructure handles execution and settlement separately. New chains could then customise their own technology stack, security model, fee tokens and permissions in accordance with their user base and protocol offering.
2. Examples of Application Chains
Cosmos Zones
Cosmos was one of the first drivers of application-specific chains, with its core product being the Cosmos Software Development Kit (SDK), which is a suite of modules for building independent networks with the ability to control operations. Moreover, Cosmos Zones can interact with each other via Cosmos Hub using its inter-blockchain (IBC) protocol, essentially hosting a hub-and-spoke model.
dYdx V4
Osmosis
Akash
Juno
Polygon Supernets
Custom-built blockchain networks dedicated to service individual applications powered by Polygon’s Edge. Their approach was to first solve the issue of bootstrapping a reliable validator group by implementing a shared security model, where each Supernet can opt into a validator service comprising those who have staked MATIC. Developers can then focus on designing tokenomics on an application level to grow their user base instead of designing a protocol-level token.
Sony (via Kaleido)
Pepsi (via Kaleido)
Avalanche Subnets
Sovereign networks with a dynamic validator set providing consensus, a subnet can have one or more blockchains. They can configure components of the blockchain that involve setting fee models, governance, processing speeds, finality and permissions where applicable. Subnet creators can also control read/write access, making adoption of the technology more “palatable” for traditional enterprises expanding into Web3. However, considering that each subnet is responsible for its security, projects will need to incentivise validators to join a specific Subnet in order to improve overall network security.
Crabada
DeFi Kingdoms
Dexalot
Polkadot Parachains
Parachains are independent blockchains running in parallel with Polkadot’s Relay Chain, which comprises validators from both the Polkadot and Kusama networks. A unique difference on parachains is that Polkadot uses an auction mechanism to assign parachains and different projects bid for spots to build out a new parachain. Polkadot parachains are expected to have full composability to exchange data and read states to ensure interoperability via the Cross-Consensus Message Format (XCS) system.
Acala
Astar
Moonbeam
Kylin
Ethereum Sidechains and Layer 2’s
One of the most popular by choice of developers and protocols alike due to Ethereum’s status. There is a wide variety of implementations in this space, such as app-specific rollups and liquidity bridging. Moreover, these implementations are usually designed to target improvements on Ethereum in the areas of throughput and gas fees.
Ronin
ImmutableX
Arbitrum
Optimism
Starkware
zkSync
3. Upsides of AppChains
Performance
Due to blockspace competition on the same network, popular dApps consume a disproportionate amount of resources that increases transaction costs and latency
With the implementation of AppChains, it is possible to keep transaction costs and latency lower and more predictable - this provides users with a more consistent and smoother experience overall similar to traditional Web2 apps
Customization
Optimization of applications for users is usually top priority for any protocol as they seek to serve their user needs while keeping them engaged and sticky
Larger dApps are going to require to make design tradeoffs to ensure continuous smoothness of the user experience and performance of their dApp - throughput, finality, permissions, composability and integrations to name a few
Transitionary options for traditional Web2 enterprises exploring expansion into Web3 without having to take a leap into overall permissionless networks - gradual adoption from a technology perspective in public permissioned blockchains for a specific scope of functionality
Value
dApps are able to monetize easier within a smaller ecosystem, niche user base and more direct revenue capture
Additional token sinks originating from security models and gas consumption (referring to AppChains that do not use a layer 1 currency as their gas token directly)
New crypto-native business models through ability to run their own validators and sequencers on the AppChain to capture MEV or fee competition
4. Downsides of AppChains
Infrastructure Isolation
Isolated infrastructures potentially affects the atomic properties of a base layer blockchain on transactions but assessment on the need for atomicity should be carried out to evaluate its role and importance
Liquidity fragmentation with a dependency on bridging services can cause friction for users (however the flipside to this argument could be stickier liquidity, albeit not by choice)
Depending on the usership of the AppChain, validators could view their resources better deployed elsewhere to recover their base costs as they risk inconsistent network usage potentially unless the AppChain has an already established user base
Network security might be compromised in the case where the AppChain token value drops to zero
Ecosystem Support
Additional complexities that stem from varying technology stacks could result in non-reusable code and more custom engineering might be required (security on infrastructure on code can be seen as two sides of the same coin in a more custom built architecture)
Lesser out-of-the-box tools that can be leveraged on, which includes RPC providers, oracles, data indexers and so on
Permissions
Creation of gating functions may attract more traditional enterprises but goes against the ethos of public and permissionless blockchains in Web3
Limitation of access may reduce innovation speed and composability between protocols that could hinder product development
5. Quick Summation
By evaluating the upsides and downsides of AppChains on a high level, we see that due to a greater level of network isolation, it is important to note that such implementations are more suited to dApps that have:
Reached a certain level of scale and product usage (metric measurements may vary but in general would consider number of users, protocol revenue, volumetrics and TVL)
Significant and provable performance benefits for users and user journeys through dedicated blockspace versus shared blockspace
Economies of scale on future user growth and protocol revenue upside considering that infrastructure costs will increase in direct relation to user activity
Finding a balance on robustness of network level security, developer onboarding, atomicity and ecosystem support mechanisms
6. AppChain Design Considerations
Security Type
Shared - State is secured by multiple validators and are likely to be run by different parties (e.g. Polkadot parachains, Skale)
Isolated - Application provides the security and mostly using application-owned validators or sequencers while leveraging on its own token for economic security (e.g. Cosmos Zones, Axie Ronin)
Inherited - Provided by underlying settlement and/or consensus layer (e.g. zkSync, Optimism)
Security Source
Ethereum - Used as the settlement layer for fraud proofs, validity proofs and double spend protection (e.g. Arbitrum, zkSync)
Non-Ethereum Layer 1’s - Uses non-Ethereum security and may potentially have a different consensus model (e.g. NEAR Aurora, Tezos rollups)
Application token - the application token is used for economic network security (e.g. Avalanche subnets, Cosmos Zones)
Permissioning
Permissionless - No specific controls on read/write access to contracts and states (e.g. Optimism, StarkNet)
Permissioned - Whitelisting applied on validators, developers and participants on read/write/validate functions on the chain (e.g. Polygon supernets, Avalanche subnets)
Composability
Full - Ability to move from any application with minimum latency and maximum security (e.g. Cosmos IBC, Polkadot XCMP)
Partial - Limited connectivity, latency and/or security (e.g. Polygon supernets, Avalanche subnets)
Finality
Instant - Usually with Byzantine Fault Tolerance consensus mechanism (e.g. NEAR Aurora, Evmos)
Eventual - Usually with rollups where transactions can be considered final once blocks have been posted to the layer 1 (e.g. Arbitrum, zkSync)
Gas Currency
Application token - Native token of applications running on an application-specific layer 1 or layer 2 (e.g. Avalanche subnets, Osmosis)
None - Layer 1 or Layer 2 validators or applications subsidise hardware costs (e.g. AltLayer, Skale)
Others
Staking requirements - To secure the chain and are requirements set for applications to implement on their validators
EVM support - For ability to support Solidity and EVM based opcode without the need for developers to modify and support multiple codebases
7. Introducing ZKX - Built on Starknet
ZKX is an omnichain protocol for derivatives built on Starknet for DeFi users. Their focus has been to deliver the performance of a CEX with the security of a DEX. To make this a reality, ZKX addresses challenges such as high transaction costs, scalability issues, security and fragmented liquidity.
The following components help to provide this:
ZKX Account - a self-custodial account abstraction-based wallet gives users absolute control over their funds at all times, ensuring safety and ease of use.
ZKX's AppСhain delivers lightning-fast execution, transparent order matching, and gasless trade. This layer also contains a number of ZKX nodes that communicate with each other using a consensus algorithm and can perform decentralised order matching. Each node can operate as
Compute node (provides storage, memory and processing resources),
Signature node (collects consensus),
Dispatch node (gateway to connect to the platform) at any given time.
The Node Network in turn consists of two parts:
Decentralised Limit Order Book (DLOB) - there is a direct interaction between users, the ZKX node and smart contracts. One of the most innovative features is the use of partial knowledge of state principles, which allows orders to be placed in the DLOB, data and transactions to be matched, while ensuring the security of the DLOB.
Data Provider Service (DPS) - is the gateway between the pricing engine and external data sources. DPS does not need to obtain data. Instead, it has its own vendor library standard that connects to third-party data providers. In this case, the Data Oracle is a layer between the ZKX system and a number of external data providers, which will be RedStone, major CEXs, like Binance, OKX, Coinbase, etc. as sources, which means ZKX refresh prices sub-second time.
The protocol’s design emphasises user experience with self-custody built in user accounts. The ZKX principal architecture is organised as follows:
Some key innovations the ZKX brings to users are:
Modular self-custody L2 wallet with multiple login and security features
Native L1/L2 bridges with on/off-ramp capabilities
Money pools to be built on top of (e.g. market making pools, copy trading pools, managed funds pools)
Adaptive balancing rate for funding rate calculations - aimed to stabalise rates during times of high volatility
T-SWAP for traders to run underlying options strategies
ZKX's vision is to build products that bring value to all types of traders. Building on that strategy, they have 2 products
OG Trade - A gamified exchange designed to cater to short-term traders, scalpers and swing traders.
Pro Trade - Designed for advanced traders, it offers a suite of perks and tools for sophisticated trading, including complex trading orders and APIs. Their second product is releasing on 19th February.
8. Product overview
ZKX recently launched their first product - OG Trade exchange. As mentioned above, it is a gamified perpetual swaps exchange on Starknet designed for scalpers and short-term traders. It breaks away from the usual paradigm of dry and austere interfaces and brings gamification and spice to the trading process. Users can participate in one-click trading and battle with traders for every asset: ETH, SOL and BTC. Your trading skills will earn you locked ZKX rewards, PVL (profit, volume and loss) badges and exclusive clan NFTs. You can read more about clans and terms of participation in a separate article on the ZKX blog and in a OG Trade launch announcement.
Traders will be able to compete in 30-minute competitions for awards in the following categories: Profit, Loss and Volume. All of these categories have distinctive gold, silver and bronze badges unique to each category. Depending on users trading skills, they will enter the rewards area if traders are on the leaderboard in any of the following categories: profit, volume or loss (that's right, even loss).
9. Tokenomics
Trading Incentives - 18% will be designated for Trading Rewards. Out of this, 7M $ZKX tokens have been allocated to bootstrap the mainnet launch campaign and establish steady distribution rewards for OG Trade and Pro Trade products. This strategy is geared towards fostering a dynamic trading environment and active participation.
Core Contributors - 17% will be allocated to core contributors representing the ZKX team's holdings.
Advisors - This embodies the 1% advisor allocation reserved for our current protocol advisors. Advisors are pivotal in shaping ZKX's strategic trajectory, offering insights and guidance throughout our journey.
Investors - 20% of ZKX tokens will be allocated to our early investors who have supported our vision during the last two years.
DAO Treasury - The ZKX treasury overseen by the ZKX DAO (once formed) is allocated 20%. The DAO Treasury allocation will be fully controlled by the ZKX community and is a strategic reserve to be deployed across a variety of uses, including (but not limited to):
Operations
Grants
User Adoption
Sub-DAOs
Token Community Launch - 15% is allocated to the community for their contribution to building and shaping the ZKX community, distributed through two phases of locked retroactive airdrops before the mainnet launch. The first phase is dedicated to our early adopters of the community, and the second phase will align with our forthcoming Road to Mainnet Journey.
Liquidity Provisioning - 9% of ZKX tokens are earmarked for incentivizing users and market makers to provide liquidity to the exchange and the token on AMMs and exchanges. Deep liquidity is pivotal in achieving ZKX's vision of becoming the leading DEX.
Token Utility
App-chain token for ZKX L3
Governance
Trading rewards (High-Tide algorithm designed to track trading size, frequency, consistency)
15% total supply allocated to trading rewards
Decay of digital shares if trader stops using ZKX products
Staking rewards (distributed in USDC)
20% of trading fees
10% of liquidations
10. Backers
ZKX has Backers, which have contributed $4.5m such as:
Starkware: STARK-Based scaling solutions on Ethereum
Dewhales Capital: Disruptive crypto-native fund focused on early-stage protocols and fueled by OGs, founders, and key investors
Orange DAO: Orange DAO is made up of a founder community of 1300+ Y Combinator and Orange DAO-backed founders building and investing in the future of crypto
Angel DAO: AngelDAO is a Venture Decentralized Autonomous Organization supporting a wide variety of projects with funding, software development, network participation and community building
Amber Group: Global leading digital asset company located in Singapore providing crypto financial services to both institutional and high net worth investors globally
Cluster Capital: A distributed network of crypto insiders, influencers, builders, and investors providing support, connections and traction for projects
Hashkey Capital: HashKey Capital is a digital asset and blockchain leader helping institutions, founders and talents advance the blockchain industry and find adoption anywhere
DWEB3 Capital: Digital fund focused exclusively on digital assets related to Decentralized Finance, WEB 3.0 and NFTs
Caballeros Capital: Early-stage venture firm focused on investing in innovative and founder-driven Web3 protocols and companies
Huobi Global: Cryptocurrency exchange
Crypto.com: Cryptocurrency exchange
Gate.io: Cryptocurrency exchange
Sandeep Nailwal (Polygon)
Aswin Ramachandran (Dragonfly Capital)
Ben Lakoff (Bankless Ventures)
Fawaz Hourani (Stanford Bitcoin Club)
11. Conclusion
Overall through this article, we can get a better understanding of why application chains may make sense for certain protocols and when they value-add to the overall user experience. It will always remain a challenge to convince seasoned crypto users to move their funds onto a new chain that has not proven itself, but there is also an allure to better performance and transaction finality, especially for cases such as ZKX, which has taken a bold step towards building its own ecosystem.
It is also evident from the list of investors that there is significant interest in seeing if layer-3 solutions can become the norm for protocols with high performance requirements. Moreover, it further tests the foundational roles layer-1 blockchains should play in the blockchain infrastructure space.
ZKX links:
Website | Twitter | Discord | Documentation | Blog