TeQoin L2 Blockchain Documentation - Developer Guides & API Reference

A complete analysis of TeQoin’s security architecture, threat model, and security guarantees.

TL;DR:TeQoin inherits Ethereum’s security through data availability on L1, fraud proofs for state validity, and economic incentives that make attacks unprofitable. Even with a malicious sequencer, user funds remain safe due to cryptographic proofs and decentralized verification.

🎯 Security Guarantees

What TeQoin Guarantees

Fund Safety

Your funds cannot be stolenEven with malicious sequencer

State Validity

All state transitions are validInvalid states are proven and reverted

Data Availability

All transaction data on L1Users can always reconstruct state

Censorship Resistance

Transactions cannot be censoredForce inclusion via L1

Liveness

System always operationalCan recover even if sequencer fails

No Custody

Self-custodialOnly you control your private keys

🏗️ Security Layers

Defense in Depth

Layer 1: Cryptographic Security

Foundation: Math and cryptography

    Private Key → Public Key → Address
    
    - ECDSA signatures (secp256k1)
    - Keccak-256 hashing
    - Merkle trees for state commitments

Guarantees:

Only private key owner can sign transactions
Signatures cannot be forged
State roots cannot be faked

Attack resistance:

Requires breaking ECDSA (computationally infeasible)
Would need to break SHA-256 class hashes

Layer 2: Smart Contract Security

L1 contracts enforce rules

    // L1 Bridge Contract
    - Holds all L2 ETH backing (locked)
    - Only releases with valid proof
    - Challenge period enforced
    - Immutable after deployment

Guarantees:

Code is law (deterministic execution)
No admin keys can bypass rules
Audited by multiple firms
Battle-tested on Ethereum

Attack resistance:

Would need to exploit smart contract bugs
Multiple audits reduce risk
Time-tested patterns used

Layer 3: Fraud Proof Security

Invalid states are provably detected

    Invalid State Submitted
    ↓
    Verifiers Detect Fraud
    ↓
    Fraud Proof Submitted
    ↓
    L1 Verifies Proof
    ↓
    Invalid State Reverted

Guarantees:

Any invalid state can be proven wrong
Proof verified on-chain (trustless)
Malicious sequencer slashed
Correct state restored

Attack resistance:

Would need all verifiers to collude
Economic incentive ensures verification

Layer 4: Economic Security

Rational actors stay honest

    Sequencer Stake: $10M
    Daily Revenue: $100K
    Annual Revenue: $36M
    
    Attack Gain: < $1M (gets caught)
    Attack Cost: $10M stake + $36M future revenue
    
    Result: Attack is irrational

Guarantees:

Honest behavior is most profitable
Fraud is always caught (7-day period)
Penalties exceed any possible gain

Attack resistance:

Would require irrational economic behavior
Would need to sacrifice massive value

Layer 5: Ethereum L1 Security

Inherit Ethereum’s security

    L1 Security:
    - $40B+ staked ETH
    - 1M+ validators worldwide
    - 15+ years of security research
    - Battle-tested consensus

Guarantees:

L1 contracts cannot be manipulated
L1 data cannot be censored
L1 state is final

Attack resistance:

Would need to attack Ethereum itself
Requires 51% of validators (~$20B)

🎭 Threat Model

Attack Scenarios & Defenses

1. Malicious Sequencer Attempts Theft

Attack: Sequencer tries to steal user fundsMethod:

    Sequencer posts invalid state:
    - Claims Alice has 0 ETH (was 10 ETH)
    - Claims Sequencer has 10 ETH more
    
    State Root: MerkleRoot(malicious_state)

Defense:

Verifier downloads batch from L1
Re-executes all transactions
Computes correct state root
State roots don't match!
Verifier submits fraud proof
L1 contract verifies proof
Invalid state reverted
Sequencer slashed ($10M loss)
Alice keeps her 10 ETH

Result: ✅ Attack fails, attacker loses stake

2. Sequencer Censors User Transactions

Attack: Sequencer refuses to include user’s transactionsMethod:

    User submits withdrawal TX
    Sequencer ignores it indefinitely
    User cannot withdraw funds

Defense:

    User's options:
    
    Option 1: Force Inclusion via L1
    - Submit TX directly to L1 contract
    - L1 contract forces sequencer to include
    - If sequencer refuses → slashed
    
    Option 2: Exit via L1
    - Submit Merkle proof of L2 balance to L1
    - L1 contract validates proof
    - Withdraw directly from L1 bridge

Result: ✅ Censorship impossible long-term

3. Sequencer Goes Offline

Attack: Sequencer stops producing blocks (DoS)Method:

    Sequencer server crashes
    No new blocks produced
    Users cannot transact

Defense:

    Short-term (hours):
    - Sequencer backup nodes activate
    - Automatic failover
    - Service continues
    
    Long-term (days):
    - Users submit forced transactions via L1
    - Users can exit directly to L1
    - New sequencer can be appointed
    
    State Recovery:
    - All data on L1 (data availability)
    - Anyone can reconstruct L2 state
    - New sequencer resumes from last state

Result: ✅ System remains operational

4. Verifiers Collude with Sequencer

Attack: All verifiers agree to ignore fraudMethod:

    Sequencer bribes all verifiers
    Sequencer posts invalid state
    No verifiers submit fraud proof
    Invalid state becomes final after 7 days

Defense:

    Economic Reality:
    - Verifiers are permissionless (anyone can run)
    - Only need 1 honest verifier
    - Bribe cost: Must pay ALL potential verifiers
    - Includes: Every Ethereum user globally
    
    Cost to bribe everyone: Infinite
    Cost to run verifier: $200/month
    Fraud proof reward: $5M
    
    Result: Economically impossible to bribe everyone
    
    Even if 99.99% bribed:
    - 0.01% honest = attack fails
    - 1 honest verifier = attack fails

Result: ✅ Attack requires bribing everyone (impossible)

5. L1 Contract Exploit

Attack: Find bug in L1 smart contractsMethod:

    Attacker finds vulnerability
    Exploits to drain bridge funds
    Steals locked ETH

Defense:

    Prevention:
    - Multiple security audits
    - Formal verification
    - Bug bounty program ($1M+ rewards)
    - Gradual rollout (start small)
    - Circuit breakers
    
    If exploit found:
    - Pause mechanism activated
    - Governance can upgrade
    - Insurance fund covers losses
    - Community recovery process

Result: ⚠️ Low risk but possible (mitigated heavily)

6. 51% Attack on Ethereum L1

Attack: Attacker controls Ethereum consensusMethod:

    Attacker acquires 51% of Ethereum validators
    Reverts L1 transactions
    Manipulates L1 data

Defense:

    Reality:
    - Would need ~$20B to acquire 51%
    - Would destroy ETH value (self-defeating)
    - Ethereum social consensus would fork
    - Attack detection and response
    
    If this happens:
    - TeQoin is compromised
    - So is all of Ethereum
    - So is all of DeFi
    - Economic apocalypse

Result: ⚠️ Inherits Ethereum’s security assumptions

💰 Economic Security Analysis

Cost-Benefit for Attackers

Attack Costs
Defender Incentives
Nash Equilibrium

What would attacks cost?

Attack Type	Cost	Success Probability
Steal funds (sequencer)	$10M stake +$ 36M/year revenue	0% (fraud proof)
Censor transactions	$10M stake + reputation	0% (force inclusion)
Bribe all verifiers	Infinite (permissionless)	0% (need everyone)
51% Ethereum	$20B+	~0% (social consensus)
Smart contract exploit	Research time + $1M bounty	1% (audited)

Takeaway: All attacks are either impossible or economically irrational

Why people defend the system:Sequencer:

    Honest Revenue: $36M/year
    Dishonest Gain: -$10M (slashed)
    
    Incentive: Stay honest

Verifiers:

    Cost: $2,400/year
    Fraud Proof Reward: $5M (one-time)
    Expected Value: Highly positive
    
    Incentive: Monitor actively

Users:

    Benefit: Secure funds
    Cost: None (just use it)
    
    Incentive: Use TeQoin

Ethereum Validators:

    Benefit: L2 usage increases ETH value
    Cost: None (L2 pays for L1 security)
    
    Incentive: Support L2s

Game theory stable state:

    Players: Sequencer, Verifiers, Users
    
    Strategies:
    - Sequencer: [Honest, Dishonest]
    - Verifiers: [Monitor, Ignore]
    - Users: [Use, Don't Use]
    
    Payoff Matrix (simplified):
    
                        Verifiers Monitor
    Sequencer Honest:   (High, Medium, High)
    Sequencer Dishonest:(-∞, High, Medium)
    
                        Verifiers Ignore
    Sequencer Honest:   (High, Low, High)
    Sequencer Dishonest:(High, Low, -∞)
    
    Nash Equilibrium: (Honest, Monitor, Use)
    
    - Sequencer: Stay honest (maximizes profit)
    - Verifiers: Monitor (profitable)
    - Users: Use system (secure)
    
    No player benefits from deviating!

🔐 Security Assumptions

What We Trust

Cryptographic Assumptions
Ethereum L1 Security
Economic Assumptions
What We DON'T Trust

We assume these are secure:✅ ECDSA (secp256k1)

Used for signatures
Same as Bitcoin/Ethereum
No known attacks

✅ Keccak-256 (SHA-3)

Used for hashing
Cryptographically secure
Collision resistant

✅ Merkle Trees

State commitments
Mathematically proven
Tamper-evident

Risk: Cryptography is broken Likelihood: Extremely low (decades of research) Impact: All of crypto breaks (not just TeQoin)

🛡️ Security Best Practices

For Users

Secure Your Private Key

Critical:

Use hardware wallet (Ledger, Trezor)
Never share private key
Backup seed phrase securely
Use strong passwords

Verify Transactions

Before signing:

Check recipient address
Verify amount
Review contract interactions
Check network (L1 vs L2)

Use Official Interfaces

Only trust:

https://bridge.teqoin.io
https://rpc.teqoin.io
Official documentation
Verified contract addresses

Start Small

Test first:

Send small amount initially
Verify it arrives
Then send larger amounts
Don’t risk everything at once

For Developers

Audit Your Contracts

Before mainnet:

Multiple security audits
Formal verification if possible
Bug bounty program
Test on testnet extensively

Handle Reorgs

L2 blocks can reorg:

Wait for L1 finality (7 days)
For soft finality, wait 5-10 blocks
Don’t assume instant finality
Handle reorg scenarios

Validate Inputs

Never trust user input:

Validate all addresses
Check amount bounds
Verify signatures
Sanitize data

Plan for Emergencies

Emergency procedures:

Pause mechanisms
Upgrade paths
Recovery procedures
Communication plans

📊 Security Comparison

TeQoin vs Other L2s

Security Aspect	TeQoin	Optimism	Arbitrum	zkSync	Polygon
Data Availability	L1	L1	L1	L1	Sidechain
Validity Proofs	Fraud Proofs	Fraud Proofs	Fraud Proofs	ZK Proofs	None
Withdrawal Time	7 days	7 days	7 days	Hours	Instant
Sequencer	Centralized*	Centralized*	Centralized*	Centralized*	Validators
EVM Compatibility	100%	100%	99%+	~95%	100%
Security Level	Ethereum	Ethereum	Ethereum	Ethereum	Lower

*Decentralization roadmap planned Key Takeaway: TeQoin has Ethereum-grade security through L1 data availability and fraud proofs

🔬 Formal Security Properties

Mathematical Guarantees

Safety

Nothing bad ever happensFormal property:

    ∀ state S: 
      validStateTransition(S_prev, TX, S_new) ∨ 
      ∃ fraudProof: proves_invalid(S_new)

In English: For any state transition, either:

It’s valid according to EVM rules, OR
There exists a fraud proof proving it’s invalid

Result: Invalid states cannot persist

Liveness

Something good eventually happensFormal property:

    ∀ transaction TX: 
      eventually(TX_included_in_block) ∨ 
      user_can_force_include(TX)

In English: For any transaction, either:

It will eventually be included by sequencer, OR
User can force inclusion via L1

Result: Transactions cannot be censored forever

Data Availability

All data is always availableFormal property:

    ∀ L2_block B: 
      ∃ L1_calldata D: contains(D, all_transactions(B))

In English: For every L2 block:

Transaction data exists on L1
Available to all participants
Cannot be hidden or deleted

Result: State can always be reconstructed

🎯 Security Guarantees Summary

What You Can Trust

Your Funds Are Safe

✅ Cannot be stolen by sequencer
✅ Cannot be frozen indefinitely
✅ Can always be withdrawn (7 days)
✅ Protected by Ethereum L1 security

State is Valid

✅ All state transitions follow EVM rules
✅ Invalid states are proven and reverted
✅ Economic incentive ensures verification
✅ Fraud proofs work automatically

Censorship Resistant

✅ Transactions cannot be censored permanently
✅ Can force inclusion via L1
✅ Can exit system anytime
✅ Sequencer slashed for censorship

Trustless

✅ Don’t need to trust sequencer
✅ Don’t need to trust verifiers
✅ Don’t need to trust TeQoin team
✅ Only trust math and economics

📚 Additional Resources

Fraud Proofs

How fraud detection works

Optimistic Rollup

Core technology explained

Sequencer Design

Block production system

Challenge Period

Why withdrawals take 7 days

Introduction

Quick Start

Developer Documentation

Bridge

Architecture

Tutorials

Resources

​🎯 Security Guarantees

​What TeQoin Guarantees

Fund Safety

State Validity

Data Availability

Censorship Resistance

Liveness

No Custody

​🏗️ Security Layers

​Defense in Depth

​🎭 Threat Model

​Attack Scenarios & Defenses

​💰 Economic Security Analysis

​Cost-Benefit for Attackers

​🔐 Security Assumptions

​What We Trust

​🛡️ Security Best Practices

​For Users

Secure Your Private Key

Verify Transactions

Use Official Interfaces

Start Small

​For Developers

Audit Your Contracts

Handle Reorgs

Validate Inputs

Plan for Emergencies

​📊 Security Comparison

​TeQoin vs Other L2s

​🔬 Formal Security Properties

​Mathematical Guarantees

​🎯 Security Guarantees Summary

​What You Can Trust

​📚 Additional Resources

Fraud Proofs

Optimistic Rollup

Sequencer Design

Challenge Period

🎯 Security Guarantees

What TeQoin Guarantees

🏗️ Security Layers

Defense in Depth

🎭 Threat Model

Attack Scenarios & Defenses

💰 Economic Security Analysis

Cost-Benefit for Attackers

🔐 Security Assumptions

What We Trust

🛡️ Security Best Practices

For Users

For Developers

📊 Security Comparison

TeQoin vs Other L2s

🔬 Formal Security Properties

Mathematical Guarantees

🎯 Security Guarantees Summary

What You Can Trust

📚 Additional Resources