CrossSpace QA – Automated Core Space and eSpace Integration Testing

#1

CrossSpace QA – Automated Core Space and eSpace Integration Testing

  1. Project Overview

Project Name: CrossSpace QA
Category: Developer Tooling / Infrastructure
Target Network: Conflux Network, with an initial focus on Core Space and eSpace interoperability
Proposed Duration: - 6 weeks
Funding Requested: - $12,000 USD equivalent, disbursed in CFX subject to grant approval and the agreed terms
Project Status: - Proposed
Repository: - To be created

Executive Summary

CrossSpace QA is a proposed open-source developer testing toolkit designed to help developers validate applications that interact with both Conflux Core Space and eSpace.

Conflux provides two complementary execution environments. Core Space supports native Conflux functionality, while eSpace offers Ethereum Virtual Machine compatibility and supports familiar Ethereum development tools. Although these environments can communicate through Conflux’s cross-space mechanisms, developers must account for differences in transaction interfaces, address representations, execution behavior, and application state.

The objective of CrossSpace QA is to make these integration workflows easier to test, reproduce, and debug before deployment.

Rather than creating another blockchain node, SDK, or general-purpose testing framework, CrossSpace QA will investigate the limitations of existing Conflux development tools and build a focused set of reusable integration tests, fixtures, assertions, and reference examples for the scenarios that remain inadequately covered.

The project will initially prioritize cross-space calls, address mapping, CFX transfers, state verification, and relevant failure-handling scenarios. The final implementation scope will be determined by a technical audit of existing tools and feedback from developers.

The project will use existing Conflux infrastructure wherever practical, particularly the CFX DevKit development environment and compatible SDKs. Its deliverables will be open-source, documented, and designed for integration into developers’ local workflows and continuous integration pipelines.

The intended ecosystem benefit is to reduce the effort required to test cross-space applications, improve the reliability of integrations, and make Conflux development more accessible to teams building applications that use both spaces.

The first milestone will serve as a formal validation gate. Development beyond the initial research phase will proceed only after identifying concrete gaps in existing tooling and obtaining credible evidence that external developers would benefit from the proposed solution.

  1. Problem Statement

2.1 Background

Conflux supports two logically distinct execution environments: Core Space and eSpace.

Core Space uses native Conflux transaction formats and tooling. eSpace provides an EVM-compatible environment in which developers can use familiar Ethereum tools, including Hardhat, Foundry, ethers.js, and other compatible libraries.

Cross-space functionality allows applications to interact across these environments. However, the development workflows involved are not identical to those of an application operating exclusively within one environment.

Developers working across spaces may need to handle different SDK interfaces, address representations, contract interactions, transaction execution, and state verification. These interactions can introduce integration cases that are difficult to validate through isolated contract unit tests alone.

2.2 The potential gap

Existing Conflux documentation, SDKs, and developer tooling already cover important parts of this workflow. CFX DevKit also provides a dual-space local development node and associated development utilities.

Consequently, CrossSpace QA will not assume that developers lack a local testing environment or that cross-space testing is entirely unsupported.

Instead, the project will investigate a narrower question:

Do developers lack reusable, well-documented, automated integration scenarios for validating important cross-space application workflows and their failure conditions?

Potential areas for investigation include:

  • Whether documented cross-space workflows have complete, executable reference tests.
  • Whether developers can easily verify expected state changes across spaces.
  • Whether common failure conditions and recovery behavior are adequately represented in existing examples.
  • Whether current testing utilities provide sufficiently clear diagnostics for cross-space integration failures.
  • Whether these scenarios can be incorporated into existing CI pipelines without substantial custom setup.

These are hypotheses to validate, not established deficiencies in the current Conflux tooling.

2.3 Why this matters

When integration behavior is difficult to reproduce, developers may need to create custom test scripts, rely on manual checks, or spend additional time diagnosing unexpected results.

A reusable testing suite could reduce this repeated work by providing consistent test scenarios and expected outcomes.

For Conflux, this could strengthen the developer experience and support the development of applications that use both Core Space and eSpace.

The project will measure its usefulness through successful test execution, external developer evaluations, integration into existing workflows, and documented evidence of time or effort saved where measurable.

  1. Proposed Solution

CrossSpace QA will be an open-source testing toolkit that extends existing Conflux development infrastructure with reusable cross-space integration tests.

The toolkit will provide test fixtures, assertions, reference contracts, sample workflows, and automated checks for selected interactions between Core Space and eSpace.

3.1 Core features

A. Cross-space integration fixtures

Reusable test setup utilities will help developers initialize the supported testing environment, prepare contract deployments, and execute documented cross-space workflows.

The implementation will reuse existing local development infrastructure instead of building a separate blockchain node.

B. Cross-space call validation

The suite will include tests for supported cross-space calls, verifying expected return values, relevant transaction outcomes, and resulting application state.

C. Address mapping and transfer verification

Selected tests will validate documented address-mapping behavior and supported CFX transfer workflows, including expected balance changes and relevant invalid-input cases.

D. Failure-handling scenarios

The suite will include reproducible tests for selected failure conditions, such as invalid inputs, reverted operations, unexpected results, and applicable asynchronous workflow failures.

The precise cases will depend on what existing tooling already covers and what can be reliably reproduced in the chosen environment.

E. Automated execution and diagnostics

The project will provide a straightforward way to execute the supported test suite locally and through continuous integration.

Failure output should identify the scenario that failed and provide useful context for debugging.

F. Reference application and documentation

A minimal example application will demonstrate how to use the toolkit. Documentation will cover installation, configuration, supported workflows, test execution, known limitations, and contribution guidelines.

3.2 What the project will not build

To maintain a realistic six-week delivery schedule, the initial scope will exclude:

  • A new Core Space or eSpace blockchain node.
  • A replacement for existing Conflux SDKs.
  • A general-purpose EVM testing framework.
  • A blockchain explorer or analytics dashboard.
  • A production monitoring service.
  • A new bridge or cross-chain protocol.
  • A financial application requiring its own liquidity or user incentives.

The objective is to solve one focused developer infrastructure problem rather than create another broad platform.

  1. Technical Architecture

CrossSpace QA will be structured as a testing layer above existing Conflux development infrastructure.

Layer 1: Existing development environment

The toolkit will use the CFX DevKit dual-space development node and compatible Conflux SDKs where suitable. The initial audit will establish package compatibility, available APIs, supported versions, and appropriate integration points.

Layer 2: CrossSpace QA testing utilities

This layer will contain reusable fixtures, helper functions, test assertions, scenario definitions, and diagnostic utilities.

Layer 3: Reference contracts and scenarios

A small collection of reference contracts and test scenarios will demonstrate the supported cross-space workflows.

Layer 4: Developer workflow integration

The test suite will support repeatable local execution and a documented CI configuration so that teams can run the relevant checks as part of their development process.

Technical stack

The initial implementation is expected to use:

  • TypeScript or JavaScript.
  • Existing Conflux SDKs and development utilities.
  • Solidity for any necessary reference contracts.
  • A compatible automated testing framework.
  • GitHub Actions or an equivalent CI service.
  • Markdown documentation and reproducible example projects.

The final stack will be selected after reviewing existing repositories and determining the most maintainable integration approach.

Engineering principles

The implementation will prioritize:

  1. Reuse of existing Conflux infrastructure.
  2. Reproducible and understandable test cases.
  3. Automated validation wherever practical.
  4. Clear error messages and documented limitations.
  5. Compatibility with existing developer workflows.
  6. An open-source codebase that external contributors can inspect and extend.

The project will not introduce unnecessary dependencies or require production credentials for routine testing.

  1. Research and Demand Validation

A major part of the project is determining whether the proposed testing layer provides value beyond existing tools.

5.1 Existing solutions to review

The initial audit will examine:

  • Conflux’s official Core Space and eSpace documentation.
  • Existing cross-space examples and SDK functionality.
  • CFX DevKit’s local development node and testing utilities.
  • Existing public testing repositories and developer issues.
  • Other relevant Conflux developer tooling proposals.

The review will distinguish between functionality that already exists, functionality that exists but lacks sufficient examples, and functionality that remains genuinely unaddressed.

5.2 Developer validation

The project will seek feedback from at least five developers or development teams, prioritizing those who have built or are actively building applications involving cross-space interactions.

Questions will focus on:

  • Their current cross-space testing workflow.
  • The integration failures or debugging challenges they have encountered.
  • Which scenarios they cannot easily test with existing tools.
  • How they currently reproduce and diagnose these problems.
  • Whether the proposed toolkit would fit their development process.
  • Whether they would be willing to test or integrate an initial release.

The target is to obtain feedback from five developers or teams, with at least three providing substantive feedback on a working example or test specification.

These are proposed research targets; no interviews or partnerships are claimed to have been completed.

5.3 Validation gate

Milestone 1 will produce a public technical findings report and a documented implementation specification.

The report will identify:

  • The existing tools reviewed.
  • The concrete problem selected for implementation.
  • Evidence supporting the problem’s relevance.
  • Feedback received from prospective users.
  • The functionality that will be built.
  • The functionality deliberately excluded from the MVP.

If the audit shows that existing tools already address the proposed problem adequately, or if no meaningful user need can be established, the project will pause for scope review before proceeding to substantial implementation.

Any material scope change will be agreed with the grant contact before additional work is undertaken.

  1. Project Objectives

The project has five primary objectives.

Objective 1: Identify a concrete tooling gap.

Audit existing Conflux development infrastructure and validate a specific cross-space testing problem through developer feedback.

Objective 2: Deliver a working integration testing toolkit.

Build reusable fixtures, assertions, reference examples, and tests for the selected workflows.

Objective 3: Improve test reproducibility.

Enable developers to execute the supported scenarios locally and through CI with documented setup instructions.

Objective 4: Encourage external adoption.

Make the toolkit accessible to independent developers and development teams through a public repository, examples, and documentation.

Objective 5: Strengthen the Conflux developer ecosystem.

Contribute maintainable open-source testing resources that complement existing tooling rather than duplicate it.

  1. Milestones and Deliverables

The proposed implementation period is six weeks.

Milestone 1: Research, technical audit, and specification

Duration: Week 1
Funding requested: $2,000

Activities:

  • Review existing Conflux documentation, SDKs, CFX DevKit, and related public repositories.
  • Identify the specific testing scenarios that are not adequately addressed.
  • Seek structured feedback from prospective users.
  • Verify technical feasibility and dependency compatibility.
  • Define acceptance criteria and finalize the MVP scope.

Deliverables:

  1. Public research and findings report.
  2. Documented description of the validated problem.
  3. Initial repository and project specification.
  4. Prioritized list of test scenarios.
  5. Acceptance criteria for the implementation milestone.

Success criteria: The report identifies a specific, technically reproducible gap and provides credible evidence that the proposed work would benefit developers.

Decision gate: The next milestone will proceed only after the scope is validated and agreed upon.

Milestone 2: Core implementation

Duration: Weeks 2–4
Funding requested: $5,000

Activities:

  • Implement the core testing utilities and fixtures.
  • Add the selected cross-space integration scenarios.
  • Develop reference contracts or examples where necessary.
  • Implement assertions for expected results and state changes.
  • Add selected negative and failure-handling tests.
  • Configure automated test execution.

Deliverables:

  1. Working open-source toolkit.
  2. Automated test suite covering the agreed scenarios.
  3. Reproducible reference example.
  4. Initial CI configuration.
  5. Technical documentation describing supported functionality.

Success criteria: The agreed scenarios execute reproducibly in the target environment, with expected outcomes verified by automated assertions.

Milestone 3: External testing, documentation, and release

Duration: Weeks 5–6
Funding requested: $5,000

Activities:

  • Complete installation and usage documentation.
  • Test the toolkit with external developers.
  • Fix validated issues discovered during testing.
  • Publish a stable initial release.
  • Demonstrate the toolkit through a recorded or live technical walkthrough.
  • Publish the final progress and completion report.

Deliverables:

  1. Public repository with release documentation.
  2. Completed automated tests and CI workflow.
  3. Reference application and usage examples.
  4. External testing and feedback summary.
  5. Public release announcement and final report.

Success criteria: The toolkit can be installed and used by an external developer following the documentation, and the project publishes verifiable implementation and testing results.

  1. Budget Breakdown

Total funding requested: $12,000 USD equivalent, payable in CFX according to the grant agreement.

The budget covers engineering work, technical validation, testing, documentation, and release preparation.

8.1 Budget by category

  1. Technical audit and developer validation - $1,500
    Review existing tools, gather feedback, validate the gap, and define acceptance criteria.

  2. Core test framework development - $4,000
    Develop reusable fixtures, assertions, integration scenarios, and reference contracts.

  3. Failure testing and CI integration - $2,500
    Implement negative tests, automated execution, diagnostics, and CI configuration.

  4. Documentation and reference project - $1,500
    Prepare installation instructions, API documentation, sample workflows, and a reference application.

  5. External testing and release preparation - $1,500
    Support external evaluations, address validated issues, and prepare the public release.

  6. Test infrastructure and contingency - $1,000
    Cover necessary development infrastructure, testing-related expenses, and limited unforeseen implementation costs.

Total: $12,000

8.2 Budget by milestone

Milestone 1: Research and specification $2,000
Milestone 2: Core implementation $5,000
Milestone 3: Testing and release $5,000

Total $12,000

8.3 Budget justification

Technical audit and validation: The project must establish a defensible problem before building software. This allocation covers the initial review, technical specification, and structured developer feedback.

Core development: This is the largest allocation because the main deliverable is a working, reusable software package with integration tests and examples.

Failure testing and CI: Testing cross-space workflows requires verification of expected outcomes and appropriate handling of failed operations. CI integration will make the resulting tests repeatable for other teams.

Documentation and examples: The toolkit will have limited ecosystem value if developers cannot understand how to install, configure, and use it. Documentation and a reference application are therefore core deliverables.

External testing and release: Independent feedback is necessary to establish whether the toolkit is usable beyond its original author. This allocation supports evaluation, fixes, and release preparation.

Infrastructure and contingency: This covers reasonable development-related expenses that arise during implementation. Any material budget reallocation will be documented and agreed with the grant contact where required.

The project does not budget for liquidity mining, token incentives, a proprietary token, or the development of a separate blockchain node.

The requested amount is a planning estimate and may be adjusted following the Foundation’s feedback and agreement on the final scope.

  1. Key Performance Indicators

The following KPIs will be used to evaluate progress.

Technical KPIs

  • One publicly accessible, documented open-source repository.
  • At least 10 meaningful integration test cases across the agreed supported workflows, including relevant failure cases.
  • Automated execution of the supported test suite in the documented environment.
  • A reproducible reference application.
  • Documented installation and CI integration instructions.

Adoption KPIs

  • Feedback sought from at least five developers or teams.
  • At least three substantive evaluations of the test specification or working implementation.
  • At least two external teams testing the released toolkit.
  • A target of one external project integrating the toolkit during the grant period, provided a suitable project is identified and agrees to participate.

Ecosystem KPIs

  • Public documentation and release notes.
  • A public technical findings report.
  • A final report documenting implementation, limitations, feedback, and adoption.
  • Evidence of improvements made in response to external developer feedback.

These targets will be refined after the initial audit. The project will report actual outcomes and explain any targets that were not achieved rather than presenting targets as completed results.

  1. Expected Ecosystem Impact

CrossSpace QA is intended to create value for Conflux through developer infrastructure rather than direct user incentives.

For developers

The toolkit should provide ready-to-use tests for selected cross-space workflows, reducing the need for developers to repeatedly write custom integration checks.

For application teams

Reusable tests and CI examples could help teams identify integration issues earlier and improve the reproducibility of their development processes.

For Conflux

A maintained library of integration tests could strengthen the developer toolchain and make cross-space application development easier to understand and validate.

For the broader ecosystem

Because the toolkit will be open-source, developers outside the original project can inspect the implementation, contribute additional scenarios, report issues, and adapt the tests to their applications.

The project will not claim that the toolkit directly increases TVL or transaction volume. Its initial impact will be measured through developer adoption and the quality of the technical deliverables. Any subsequent effect on application launches or network activity will be reported only when supported by evidence.

  1. Maintenance and Sustainability

Following the initial release, the project will aim to maintain the repository, resolve reproducible issues, and incorporate community contributions.

The maintenance approach will include:

  • Documented contribution guidelines.
  • Versioned releases and a public issue tracker.
  • Compatibility notes for supported dependencies.
  • Automated tests to reduce regression risk.
  • Clear documentation of unsupported scenarios and known limitations.

Where appropriate, the project will seek collaboration with existing Conflux tooling maintainers to ensure the work complements the ecosystem and avoids unnecessary fragmentation.

No formal partnership or upstream contribution commitment is assumed at this stage.

The initial grant will fund the MVP and public release. Longer-term maintenance commitments will be based on actual adoption, community feedback, and available resources.

  1. Team and Execution

The application will identify the individuals responsible for project delivery before submission.

The proposed responsibilities are:

Project Lead: Carl
GitHub; https://github.com/duongja
Responsible for project coordination, grant reporting, developer validation, milestone delivery, and community engagement.

Technical Lead: Kitsune
GitHub; https://github.com/0xkitsune
Responsible for the architecture, implementation, test design, CI integration, code quality, and technical documentation.

External Evaluators: Developers who provide feedback on the selected workflows and test the implementation.

The final application must include the actual team members, their relevant experience, public profiles, and GitHub repositories where available. No unconfirmed technical lead or external partnership will be presented as established.

The project is designed for a small team and a focused MVP. Its scope will be adjusted to match the confirmed technical capacity and the findings from the initial validation phase.

  1. Risks and Mitigation

Risk 1: Existing tools already solve the proposed problem

Mitigation: Conduct a technical audit before substantial development. If the proposed gap is not substantiated, revise the scope with the grant committee.

Risk 2: Limited developer demand

Mitigation: Seek feedback from prospective users and test the proposed scenarios before committing the full implementation budget.

Risk 3: Compatibility issues with existing tooling

Mitigation: Verify supported packages and APIs during the first milestone and avoid unnecessary dependencies.

Risk 4: Cross-space scenarios are difficult to reproduce consistently

Mitigation: Use a documented test environment, isolate test cases, and explicitly document any limitations or nondeterministic behavior.

Risk 5: Limited external adoption during the grant period

Mitigation: Engage developers early, provide a reference project, publish clear onboarding documentation, and measure actual usage rather than relying solely on repository metrics.

Risk 6: Scope expansion

Mitigation: Limit the initial implementation to the scenarios approved after Milestone 1. Additional features will be deferred unless they are necessary for the agreed deliverables.

  1. Open-Source Commitment

CrossSpace QA will be released as open-source software under a permissive license, subject to compatibility with the licenses of any upstream code and dependencies.

The project will publish its source code, documentation, supported test scenarios, known limitations, and progress reports.

The team will avoid unnecessary duplication of existing Conflux tooling and will seek to contribute reusable improvements to the broader ecosystem where technically appropriate.

  1. Grant Compliance and Reporting

The team acknowledges that funding is conditional on approval by the Conflux grant committee and execution of the applicable grant agreement.

If approved, the team will:

  • Provide the KYC information required by the Foundation.
  • Comply with the applicable no-sale rule for grant-received CFX.
  • Publish progress updates as required.
  • Submit evidence and deliverables for each milestone.
  • Report changes in scope, timelines, or budget transparently.
  • Cooperate with milestone reviews and other grant requirements.

The exact payment schedule, milestone acceptance criteria, and reporting cadence will be finalized with the assigned grant contact.

  1. Conclusion

CrossSpace QA proposes a focused contribution to Conflux’s developer infrastructure: an open-source integration testing suite for selected workflows involving Core Space and eSpace.

The project will build on existing tooling rather than recreate infrastructure that is already available. Its main deliverables will be reusable test fixtures, automated integration scenarios, failure-handling checks, CI examples, documentation, and a reference application.

The proposed six-week project requests $12,000 to fund validation, engineering, testing, documentation, and release preparation.

The first milestone is deliberately structured as a decision point. It will establish whether the problem is real, whether existing tools leave a meaningful gap, and whether developers are willing to evaluate the proposed solution. Subsequent development will follow only after that scope is validated.

The intended outcome is a maintainable open-source resource that makes cross-space development more testable and reproducible, supports external developer adoption, and strengthens the Conflux technology stack.

The project will be judged by its verified technical contribution and actual developer adoption, not by unsupported claims about demand or ecosystem impact.

References

  1. Conflux Network, eSpace Overview: https://doc.confluxnetwork.org/docs/espace/Overview/
  2. Conflux Network, Spaces Documentation: https://doc.confluxnetwork.org/docs/general/conflux-basics/spaces/
  3. CFX DevKit: https://www.cfxdevkit.org/
  4. CFX DevKit Local Development Node: https://www.npmjs.com/package/@cfxdevkit/devnode
  5. Conflux Grant Documentation: https://doc.confluxnetwork.org/docs/general/build/grants/
  6. Conflux Developer Grants: https://confluxnetwork.org/en/developers/grants
  7. Conflux Forum: https://forum.conflux.fun/