Technical Architecture
ZeroTick is a frontend interface to on-chain smart contracts. All operations, including trading, token launches, and protections, execute through smart contracts on the blockchain. ZeroTick provides the tools; the platform itself is fully decentralized and non-custodial.
Smart Contracts & On-Chain Execution
Every core operation on ZeroTick is executed and enforced by smart contracts on the blockchain:
Token launches deploy smart contracts on the selected chain. Once deployed, the contract governs all trading activity for that token: ZeroTick has no ability to alter or intervene in its behaviour.
Protections (Anti-Insider, Anti-Whale, Anti-Bot, Anti-Bundle, Buy Caps, Sell Limits) are code-enforced directly in the smart contract. They are not policies that ZeroTick applies or can override: they are immutable rules written into the contract at deployment.
Bonding curve pricing is defined mathematically in the smart contract. Prices follow the curve formula on every trade with no external input.
Vesting and distribution are enforced by escrow smart contracts. Allocated tokens unlock on the schedule defined at launch: no party, including the creator, can withdraw early.
DEX migration (graduation) is an automated on-chain event. When a token's bonding curve reaches its threshold, the contract migrates liquidity to a decentralized exchange without any manual intervention.
ZeroTick never has custody of user funds. All transactions are signed by the user's own non-custodial wallet and settle directly on the blockchain.
Wallet Infrastructure, Openfort
ZeroTick uses Openfort to provide embedded, non-custodial MPC wallets.
Key Security, MPC with Shamir's Secret Sharing
Openfort wallets are MPC (Multi-Party Computation) wallets that use Shamir's Secret Sharing (SSS) as the cryptographic primitive for key management. SSS is an audited algorithm (Cure53, August 2024) that uses GF(256) finite field arithmetic to split a private key into multiple shares.
The private key is split across three independent storage locations:
Device storage: a share stored locally on the user's device
Hot storage: a share held in a cloud-accessible service (Openfort Shield), encrypted by the user's wallet password
Cold storage: a backup share included in the user's recovery kit
No single share can reconstruct the key: at least two shares are required. The complete key is reconstructed ephemerally in memory only at the moment a signature is needed, then immediately discarded. At no point does the full key persist in any storage location.
This architecture ensures:
ZeroTick never holds any key material: the platform has no access to any share
Openfort alone cannot access user keys: the Shield share is encrypted by the user's password, which Openfort does not store
No single point of failure: compromising one storage location is insufficient to reconstruct the key
Chain Support
Openfort natively supports two signer types:
EVM signer (secp256k1): a single address shared across Ethereum, BSC, and Monad
SVM signer (ed25519): a distinct Solana address using a different cryptographic curve
Sui, Local Key Derivation
Sui uses the Move VM, which Openfort currently does not support natively. ZeroTick derives a Sui keypair locally using deterministic key derivation from the user's wallet password. The Sui private key exists only on the user's device and is included in the recovery kit as a mnemonic for external wallet import.
SSS is an audited algorithm (Cure53, August 2024) that uses GF(256) finite field arithmetic to split a private key into multiple shares.
Cross-Chain Routing, DeBridge
ZeroTick uses DeBridge for cross-chain operations between EVM chains and Solana.
Supported Routes
EVM to EVM: Ethereum, BSC, Monad (any direction)
EVM to Solana: bidirectional
Architecture
DeBridge provides a four-stage execution flow:
Quote: the DeBridge API calculates estimated output, fees, and optimal routing
Order: an order is created with locked parameters (amount, slippage tolerance, destination)
Execute: the transaction is signed by the user's wallet and submitted to the source chain
Track: order status is tracked until tokens arrive on the destination chain
Cross-Chain Routing, Wormhole
ZeroTick uses Wormhole for any cross-chain route involving Sui.
Why Wormhole
DeBridge does not support the Sui blockchain. Any operation where the source or destination chain is Sui routes through Wormhole automatically.
Supported Routes
Sui to EVM: e.g., SUI to ETH, SUI to BNB
Sui to Solana: e.g., SUI to SOL
Architecture
Wormhole uses a decentralized guardian network to verify cross-chain messages:
Transfer created: Wormhole prepares the cross-chain transfer message
Transaction signed: the user's wallet signs and submits the transaction on the source chain
Guardian verification: Wormhole's guardian network verifies the transaction and produces a VAA (Verified Action Approval)
Destination delivery: tokens are released on the destination chain once the VAA is confirmed
Auto-Routing
ZeroTick automatically selects the appropriate routing service based on the chains involved:
Solana
Ethereum
DeBridge
Ethereum
BSC
DeBridge
BSC
Monad
DeBridge
Solana
Sui
Wormhole
Sui
Ethereum
Wormhole
Sui
BSC
Wormhole
Same chain
Same chain
Direct (no bridge)
The current routing rule: if Sui is involved, Wormhole handles it. All other cross-chain operations go through DeBridge. Same-chain operations execute directly through the chain's DEX with no bridge. As additional chains are added to the platform, routing rules and bridge integrations will expand accordingly.
Last updated