Integration Grants Application '26: Conflux Liquidity & Execution Analytics

Application Introduction
1. Project Name
Conflux Liquidity & Execution Analytics

2. Problem Statement and Proposed Solution
Conflux eSpace has an active DeFi ecosystem with multiple DEXs and liquidity venues. Developers, traders, liquidity providers, researchers, and analytics applications can access individual pieces of market information through DEX interfaces, blockchain explorers, and RPC infrastructure. The problem is that this information is not presented through one standardized, reproducible analytics layer focused on the relationship between liquidity and actual trade execution.

For a developer or researcher, answering basic execution questions can require separate work to identify pools, retrieve token metadata, read pool state, determine applicable fees, obtain a quote, estimate gas, collect historical events, and then calculate comparable execution metrics.

This project addresses that gap by providing an open-source analytics layer for Conflux eSpace.
The system collects real on-chain and DEX data, normalizes it into a common data model, calculates liquidity and execution metrics, stores observations with their blockchain provenance, exposes the results through a REST API, and provides a dashboard and reproducible reports.

The current MVP already demonstrates this architecture with live Conflux eSpace integrations for:

  • Swappi V2 constant-product pools
  • vSwap V3 concentrated-liquidity pools
    The system currently supports real pool discovery, pool-state collection, execution quotation, execution analytics, historical event collection, SQLite persistence, API access, dashboard presentation, and reproducible reporting.

The proposed grant will expand this working foundation into a broader public developer and research infrastructure layer for Conflux eSpace.

3. Alignment with Conflux Network
The project is primarily an Infra & Developer Tooling project with DeFi as its principal use case.
Conflux identifies Infra & Developer Tooling as a grant category for infrastructure, protocols, and SDKs that support and enhance the ecosystem. The current grant program also identifies attracting liquidity, increasing network activity, and building the Conflux technology stack as objectives. This project contributes to those objectives by providing reusable infrastructure that other Conflux applications can consume rather than building another standalone trading interface.

Benefit to the Conflux ecosystem
The system can provide a common analytics interface for:

  • DEX applications
  • trading interfaces
  • portfolio applications
  • liquidity management tools
  • market-making systems
  • DeFi dashboards
  • research platforms
  • risk monitoring systems
  • automated strategy developers
  • developers building new Conflux applications
    The adapter architecture allows additional DEXs to be integrated without changing the underlying analytics engine. A developer can therefore build against a common API rather than implementing a separate market-data and execution-analysis pipeline for every DEX. The current MVP already demonstrates that approach through separate Swappi V2 and vSwap V3 adapters.

Economic benefit
The project does not directly execute trades or custody assets. Its economic contribution comes from making existing liquidity more measurable and usable. Better visibility into liquidity depth, execution quality, fees, and gas costs can help developers and market participants identify where liquidity is available, compare execution conditions, and build applications around Conflux markets.

As the system expands to additional venues and historical datasets, it can also provide infrastructure for applications that direct more trading activity and liquidity toward Conflux markets. The project therefore supports the wider economic activity of the eSpace ecosystem without introducing a separate token or financial product.

4. Competitive Edge
The project’s main distinction is that it is not simply a market-data display.
It combines:

  1. On-chain data collection
  2. DEX-specific adapters
  3. Pool-state normalization
  4. Execution quotation and simulation
  5. Liquidity analysis
  6. Price-impact calculation
  7. Fee analysis
  8. Gas estimation
  9. Historical event collection
  10. Data provenance
  11. Reproducible calculations
  12. REST API access
  13. Dashboard presentation
  14. Machine-readable reports

The system also handles different DEX architectures separately. Swappi V2 is treated as a constant-product market. vSwap V3 is treated as a concentrated-liquidity market. The analytics engine does not force both pool types into the same mathematical model. This is important because execution and liquidity calculations for concentrated-liquidity pools cannot simply be treated as reserve-based constant-product calculations. The current implementation demonstrates this protocol-specific adapter model.

5. Project Links
GitHub Repository


Company
Pillar-5 GmbH
Company website
https://pillar-5.com

6. Conflux eSpace Grant Recipient Wallet
0x278043f15938dffe881ebf0A7eD3Ab3C3BC8BD6c
The wallet will be a dedicated project/grant wallet controlled by the grant recipient and will not be used for personal funds.

7. Incorporated Startup
Yes.
The project is being developed through Pillar-5 GmbH, a Swiss limited liability company registered in Basel-Stadt. Pillar-5 GmbH is registered with the Commercial Register Office of the Canton of Basel-Stadt under CH-270.4010389-6 and UID CHE-459.121.192. The company’s registered office is in Basel, Switzerland. Gian Seyitcan Senpinar is the managing director and authorised representative.

Technical Introduction
1. Relationship to the Problem Statement
Conflux eSpace provides EVM-compatible infrastructure and public RPC access, while individual DEX protocols expose their own market structures and interfaces. The proposed system provides a common layer between those protocols and applications that need normalized market and execution information. The MVP has already established the core technical path. It connects to Conflux eSpace, discovers and verifies supported DEX infrastructure, reads market state, obtains execution quotations, calculates execution metrics, stores the results and exposes them through an API and dashboard. The grant will extend this existing implementation rather than begin development from scratch.

2. Existing Solutions and Feasibility
Existing Conflux ecosystem infrastructure already provides important components, including blockchain explorers, RPC infrastructure and DEX interfaces. The purpose of this project is not to replace those systems. Instead, it addresses a narrower technical problem: creating a reusable execution and liquidity analytics layer that combines data from different DEX architectures and presents the resulting measurements through a common interface. The feasibility of the approach has already been demonstrated.
The current public MVP successfully implements:

  • Conflux eSpace mainnet connectivity
  • Chain ID validation
  • Public RPC collection
  • Swappi V2 integration
  • vSwap V3 integration
  • Pool discovery
  • Contract verification
  • Token metadata collection
  • Pool-state collection
  • Execution quotation
  • Execution metrics
  • Gas estimation
  • Historical event collection
  • Checkpointed collection
  • SQLite persistence
  • FastAPI endpoints
  • Server-rendered dashboard
  • CSV, JSON and Markdown reports
  • Automated tests
  • Reproducibility documentation

The current repository is publicly available and provides the implementation and documentation required to inspect the technical foundation.

Current MVP status
Repository commit:
bc38ee7
Commit description:
Conflux Liquidity & Execution Analytics MVP: real on-chain Swappi+vSwap analytics, API, dashboard, reports. The repository currently contains the implementation, tests, configuration, documentation, API and reporting components. This MVP provides the technical foundation for the proposed grant work.

3. Purpose of the System
The purpose is to provide a reusable open-source analytics layer that makes Conflux eSpace liquidity and execution conditions accessible through standardized data structures and APIs.
The system should allow a user to answer:

  • What markets exist?
  • Which tokens are involved?
  • What is the current market state?
  • How much liquidity is available?
  • What execution would a defined trade size receive?
  • What is the effective execution price?
  • What is the price impact?
  • What fee applies?
  • What gas cost is expected?
  • How have these values changed over time?
  • Where did the data come from?
  • Can the result be reproduced?

4. Scope
In scope

  • Conflux eSpace mainnet
  • Conflux eSpace testnet support
  • DEX market discovery
  • Token metadata
  • Pool-state collection
  • Swap quotations
  • Execution analytics
  • Liquidity analytics
  • Fee analysis
  • Gas estimation
  • Historical event collection
  • Historical market observations
  • Data provenance
  • REST API
  • Dashboard
  • SQLite storage
  • Reproducible reports
  • Additional DEX adapters
  • Developer documentation
  • Automated testing
  • Deployment documentation

Out of scope
The system will not:

  • execute real trades
  • custody user assets
  • store private keys
  • request seed phrases
  • sign transactions
  • provide leveraged trading
  • issue a token
  • operate a liquidity pool
  • provide investment advice
  • guarantee execution prices
  • replace a DEX router
  • require users to connect a wallet to view analytics

5. Objectives and Success Criteria
Objective 1: Expand DEX coverage
Integrate additional active Conflux eSpace liquidity venues using the existing adapter architecture.
Success will be measured by the number of production DEX adapters that successfully discover markets and return verified market data.

Objective 2: Expand historical coverage
Collect and persist historical swap and liquidity events where the relevant DEX interfaces and RPC data make this technically possible.
Success will be measured by:

  • number of blocks processed
  • number of events collected
  • number of markets with historical observations
  • successful checkpoint recovery

Objective 3: Improve execution analytics
Expand execution analysis across:

  • trade sizes
  • trading directions
  • DEXs
  • pool types
  • fees
  • gas estimates
  • historical market states

Objective 4: Provide public developer access
Expose normalized analytics through a documented REST API.

  • Success will include:
  • documented endpoints
  • reproducible responses
  • machine-readable data
  • clear provenance
  • API examples

Objective 5: Provide usable monitoring
Maintain a dashboard that presents:

  • network status
  • market status
  • liquidity
  • execution quality
  • data freshness
  • historical observations

Objective 6: Establish reproducibility
Every analytical result should be traceable to the relevant:

  • chain
  • block
  • pool
  • token
  • contract
  • transaction or event where applicable
  • collection method
  • calculation methodology

Definitions and Abbreviations

  • eSpace: Conflux’s EVM-compatible execution environment.
  • DEX: Decentralized exchange.
  • RPC: Remote Procedure Call interface used to communicate with the blockchain.
  • AMM: Automated Market Maker.
  • CPMM: Constant Product Market Maker.
  • CLMM: Concentrated Liquidity Market Maker.
  • TVL: Total Value Locked.
  • API: Application Programming Interface.
  • MVP: Minimum Viable Product.
  • Price impact: The change in execution price relative to the applicable reference price caused by the trade size.
  • Effective execution price: The output amount received divided by the input amount, using the project’s documented reporting convention.
  • Provenance: Information identifying the source and blockchain state from which an observation was derived.

Technical Proposal
1. Functional Overview
The system is a modular Python application consisting of:

  • Conflux RPC provider
  • Blockchain data collector
  • DEX adapters
  • Market discovery
  • Market-state collector
  • Execution quotation layer
  • Liquidity analytics
  • Execution analytics
  • Historical event collector
  • SQLite storage
  • REST API
  • Dashboard
  • Reporting system
  • CLI
  • Test suite
    The architecture is deliberately modular. A new DEX should require a new adapter rather than changes to the underlying analytics engine.

2. Conflux Infrastructure
The MVP uses Conflux’s public eSpace RPC infrastructure.
Mainnet:

  • Chain ID: 1030
  • HTTP RPC: https://evm.confluxrpc.com
  • WebSocket RPC: wss://evm.confluxrpc.com/ws
  • Explorer: https://evm.confluxscan.org
    Testnet:
  • Chain ID: 71
  • HTTP RPC: https://evmtestnet.confluxrpc.com
  • WebSocket RPC: wss://evmtestnet.confluxrpc.com/ws
  • Explorer: https://evmtestnet.confluxscan.org
    The current Conflux documentation identifies evm.confluxrpc.com as a public mainnet RPC endpoint and confirms chain ID 1030 for eSpace mainnet. It also documents free-tier RPC limits, including request and eth_getLogs limits.
    The collector therefore uses:
  • bounded requests
  • retries
  • rate-limit handling
  • block-range chunking
  • checkpoints
  • resumable collection
    The system does not require the grant to fund a private node for the initial deployment. A self-hosted or higher-capacity RPC service can be introduced later if historical collection volume requires it.

3. DEX Adapter Architecture
The current MVP implements two separate adapters.
Swappi V2

  • Pool model: Constant product
  • Discovery: Factory allPairs and pair lookup
  • Quotation: Router getAmountOut
    vSwap V3
  • Pool model: Concentrated liquidity
  • Discovery: Configured verified pools
  • Quotation: Quoter quoteExactInputSingle through contract simulation

These adapters expose their capabilities to the common analytics engine. The system does not assume that all DEXs use the same pool mathematics. Future adapters will follow the same interface.

4. Market Data
Each market record contains, where available:

  • DEX identifier
  • pool address
  • token addresses
  • token symbols
  • token decimals
  • pool type
  • fee information
  • discovery source
  • verification information
  • active status
    Token contract addresses rather than token symbols are used as the canonical identity.

5. Market State
The system records the state needed to reproduce the applicable analysis.
For constant-product pools this can include:

  • token reserves
  • fee parameters
  • block number
  • block hash
    For concentrated-liquidity pools this can include:
  • square-root price
  • current tick
  • active liquidity
  • fee tier
  • tick spacing
    The exact state fields depend on the DEX adapter.

6. Liquidity Analytics
The system calculates liquidity using the state model appropriate to the pool. The system does not force concentrated-liquidity markets into a reserve-only model. Where a reliable USD price is unavailable, the system reports token-denominated liquidity rather than inventing a USD value. Any USD-derived metric must identify its price source.

7. Execution Analytics
The core analytics layer evaluates defined trade sizes. For each supported market and direction, the system can calculate:

  • input amount
  • output amount
  • reference price
  • effective execution price
  • price impact
  • fee information
  • gas estimate
  • data status
  • block number
  • observation timestamp

8. Price Methodology
Reference price is DEX-derived. For a constant-product market, the reference price is derived from the current pool state. For a concentrated-liquidity market, the reference price is derived from the applicable current square-root price and pool state. The system does not use a hard-coded stablecoin peg as a market price. USD values require an explicit price source.

9. Price Impact
Price impact is calculated by comparing the effective execution price with the applicable reference price. Fees are treated separately where the available DEX information permits this distinction. The methodology is documented so that the same input data produces the same result.

10. Gas Analysis
Where supported, the system uses eth_estimateGas and applicable gas-price information to estimate the native CFX cost of an unsigned transaction. No transaction is broadcast. Estimated gas is clearly distinguished from actual gas consumed by historical transactions.

11. Historical Collection
Historical collection uses block-range queries and checkpoints. The system can collect relevant swap events, liquidity additions, and liquidity removals where the DEX exposes the corresponding events.
Because Conflux’s public RPC imposes limits on log queries and result size, the collector uses bounded ranges and resumable checkpoints. The current Conflux documentation states that the free RPC tier has a 100,000-call daily limit and a maximum result set of 10,000 for getLogs. This is why historical collection is designed as a checkpointed process rather than a single large query.

12. Data Storage
The MVP uses SQLite.
The core data model includes:

  • pools
  • pool states
  • execution observations
  • swap events
  • liquidity events
  • collection runs
  • errors
  • checkpoints
    Raw blockchain quantities are retained in integer form where applicable. Decimal-normalized values are stored separately for analytical use. Each observation retains blockchain provenance.

13. API
The REST API is implemented with FastAPI.
Current API functionality includes:

  • health
  • DEX information
  • pool discovery
  • pool state
  • execution observations
  • collection-run results
  • report information
    The API will be expanded to expose:
  • liquidity history
  • swap history
  • market comparisons
  • execution comparisons
  • historical market state
  • data freshness
  • benchmark results
    OpenAPI documentation is generated automatically.

14. Dashboard
The dashboard provides a direct view of the analytics infrastructure.
It presents:

  • Conflux network status
  • current block
  • DEX status
  • discovered markets
  • liquidity
  • execution observations
  • trade-size comparisons
  • historical observations
  • data freshness
  • provenance information
    The dashboard does not require wallet connection and does not execute transactions.

15. Reporting
The system generates reproducible:

  • CSV
  • JSON
  • Markdown
  • reports.
    A report contains the configuration, collection period, block information, markets covered, observations, analytical results, and known limitations.

16. Non-Functional Requirements
Usability: The project should be usable by a developer with standard Python and EVM development knowledge. The repository will provide a complete installation and reproduction guide.
Reliability: The collector will support:

  • retry handling
  • rate-limit handling
  • timeout handling
  • checkpoint recovery
  • partial-run reporting
  • structured errors
    Performance: The system will use:
  • bounded RPC requests
  • batched reads where appropriate
  • indexed SQLite tables
  • checkpointed historical collection
  • configurable collection limits
    Performance will be measured through reproducible benchmarks rather than unsupported claims.
    Implementation The project will remain a modular monolith during the grant period. The architecture is intentionally simple enough for independent developers to run locally while providing interfaces for future scaling.
    User Interface: The dashboard will prioritize information density, clarity and reproducibility over visual effects.
    Security: The application will not:
  • store private keys
  • store seed phrases
  • sign transactions
  • execute trades
  • custody funds
  • request wallet permissions

17. Legal and Licensing
The current repository is released under the MIT License. The project will remain open-source unless a future dependency or Conflux requirement requires a different treatment for a specific component. The project does not issue a token, hold custody of user assets, or execute transactions on behalf of users. Third-party DEX interfaces, SDKs, ABIs, and documentation will be used in accordance with their respective licenses and terms.

Current MVP Evidence
The current public repository already contains:

  • Python implementation
  • DEX adapter architecture
  • Swappi V2 adapter
  • vSwap V3 adapter
  • Conflux RPC provider
  • pool discovery
  • market-state collection
  • execution analytics
  • historical collection
  • SQLite database
  • FastAPI API
  • dashboard
  • reports
  • configuration
  • tests
  • documentation
  • MIT license
  • reproducibility instructions
    The MVP uses the public Conflux eSpace RPC as its blockchain data source and does not require paid APIs.

Development Roadmap
Milestone 1: Production-ready DEX data layer
Timeline: Month 1
Funding: $6,000
Deliverables

  • Harden current Swappi V2 adapter
  • Harden current vSwap V3 adapter
  • Verify all production contract configurations
  • Improve market discovery
  • Improve pool-state collection
  • Add collection monitoring
  • Improve RPC failure and rate-limit handling
  • Expand integration tests
  • Document DEX interfaces
  • Publish reproducible deployment instructions
    Acceptance criteria
  • Existing DEX integrations operate against live Conflux eSpace
  • Market discovery produces verified market records
  • Collection failures are recorded
  • RPC interruptions do not corrupt stored data
  • Tests pass
  • Documentation is complete

Milestone 2: Historical liquidity and execution dataset
Timeline: Months 2 to 3
Funding: $8,000
Deliverables

  • Historical swap collection
  • Historical liquidity-event collection
  • Expanded checkpoint system
  • Historical pool-state snapshots
  • Execution observations across configurable trade sizes
  • Data-quality monitoring
  • Historical query API
  • Dataset export
    Acceptance criteria
  • Historical collection operates in bounded block ranges
  • Collection can resume after interruption
  • Events contain block and transaction provenance
  • Historical data can be queried through the API
  • Reproducible reports can be generated from stored observations

Milestone 3: Cross-DEX execution analytics
Timeline: Months 3 to 5
Funding: $8,000
Deliverables

  • Cross-DEX market comparison
  • Execution-quality comparison
  • Liquidity-depth analysis
  • Fee comparison
  • Gas-cost comparison
  • Trade-size sensitivity analysis
  • Additional DEX adapter where technically justified by active liquidity and accessible interfaces
  • Developer API improvements
    Acceptance criteria
    A developer can query the system to compare supported markets for a defined token pair, direction and trade size. The response must identify:
  • source DEX
  • market
  • block
  • quote method
  • effective price
  • reference price
  • price impact
  • fee
  • gas estimate where available
  • data status

Milestone 4: Public developer analytics platform
Timeline: Months 5 to 6
Funding: $8,000
Deliverables

  • Production dashboard
  • Public API deployment
  • API documentation
  • developer examples
  • reproducible benchmark
  • monitoring
  • final technical documentation
  • deployment documentation
  • grant-period dataset
  • final public release
    Acceptance criteria
  • Public dashboard deployed
  • API accessible
  • Documentation published
  • Repository updated
  • Reproduction instructions tested
  • Benchmark published
  • Final dataset and methodology documented

Total Budget- Grant Requested: $30,000
DEX data and adapter engineering = $6,000
Historical data collection and analytics = $8,000
Cross-DEX execution analytics and API = $8,000
Dashboard, documentation and public deployment = $4,000
Testing, deployment and infrastructure = $2,000
Infrastructure and operating costs = $2,000
Total = $30,000
The requested funding is for engineering, infrastructure, testing, historical data collection, deployment and documentation required to turn the existing MVP into a maintained public developer tool.
The project does not allocate grant funds to token issuance, trading capital or liquidity incentives.

Team
Gian Seyitcan Senpinar
Role: Project Lead / Product and Analytics. Gian Seyitcan Senpinar is Founder and Managing Director of Pillar-5 GmbH. He has experience across product management, venture development, fundraising, financial modelling, blockchain research and on-chain analytics. His background includes blockchain research at the UZH Blockchain Center, EVM research, arbitrage analysis, Python data pipelines and product/project management. He is responsible for:

  • project direction
  • ecosystem coordination
  • product requirements
  • analytical methodology
  • grant coordination
  • stakeholder communication
  • market research
  • delivery management
    GitHub: Giansensey007
    LinkedIn: linkedin.com/in/seyitcansenpinar

Felix Ritzi
Role: CTO / Blockchain and DeFi Engineering. Felix Ritzi is CTO of Pillar-5 GmbH and founder of Ritzi DeFi. His work focuses on systematic DeFi, blockchain systems and liquidity design. He is responsible for:

  • blockchain architecture
  • DEX integration
  • liquidity modelling
  • execution analytics
  • protocol research
  • technical review
  • system architecture
    LinkedIn: linkedin.com/in/felixritzi

John Kiboi
Role: Data and Analytics Engineering / Research. John Kiboi supports the project through data analysis, research, software implementation, documentation, and testing. He is responsible for:

  • data collection workflows
  • analytical validation
  • research
  • reproducibility
  • testing
  • documentation
  • API and reporting support
  • grant research and technical documentation
    LinkedIn: linkedin.com/in/john-kiboi
    Telegram: @Johnk
    The team structure combines blockchain and DeFi engineering with data analysis, research, product coordination and documentation.

References

  • Conflux Network eSpace documentation
  • Conflux eSpace RPC documentation
  • Conflux Grants documentation
  • Conflux Integration Grants Application Template
  • Swappi documentation and deployed contracts
  • vSwap documentation and deployed contracts
  • ConfluxScan
  • Project GitHub repository
  • Pillar-5 GmbH public company information

Terms of Use
I agree to all of the following terms of use in applying to a Conflux Ecosystem Grant.

  1. I have read and understood the Conflux Grants Ecosystem Overview
  2. I have read about and understood that the Conflux Technical Grants are subject to a No-Sale rule
  3. I agree to provide KYC information to the Conflux Foundation for the sake of overall ecosystem security
  4. I understand that I will be required to follow public grant reporting requirements