Create CodeX.md

[CodeXChainOfficial]

Project Abstract

CodeX is a revolutionary platform that makes blockchain development accessible to everyone, whether you're a non-technical user with a groundbreaking idea or a seasoned developer. We offer a hassle-free, no-code approach integrated with EVM and CosmWasm SDK for multi-chain deployment. Supported by a vibrant DAO ecosystem, we aim to make Web3 innovation as easy as saying #ByeCoding.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[Noc2]

Thanks for your interest in our grants program. The default deliverables are mandatory for each milestone: https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#milestone-1-example--basic-functionality and "substrate modules" have nothing to do with the implementation of a front-end. Rather substrate modules/pallets are similar to smart contracts. I would recommend taking another look at our tech stack and updating the application accordingly. Also, it would be nice if you could add more technical details to the specification of the deliverables. And we don't fund the deployment or audit of a grant.

[github-actions]

Thank you for submitting a grant application.

We've assessed your submission and have found that it requires a higher level of technical detail in order to be considered for review. We encourage you to expand on it by providing a more precise specification/technical details. The section on project details in the application template is a good reference as to what type of information we expect applicants to provide, and these category-specific requirements contain more precise guidelines depending on what type of software you're building.

An area of the application that we often find to be insufficiently elaborated are the milestone deliverables. At a minimum, please indicate what languages/technologies you will be using to implement each deliverable, and provide a technical summary of its expected functionality. Note that deliverables should be tangible, reusable by other teams and in most cases not already present in the ecosystem. If they are, you will need to provide a comparison to existing implementations and explain why it makes sense to fund your approach. Also see our FAQ for a breakdown of what we fund and what we don't.

Let us know as soon as you're done with your changes, and we'll give your application another look!

[CodeXChainOfficial]

"Thanks for your interest in our grants program. The default deliverables are mandatory for each milestone: https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#milestone-1-example--basic-functionality and "substrate modules" have nothing to do with the implementation of a front-end. Rather substrate modules/pallets are similar to smart contracts. I would recommend taking another look at our tech stack and updating the application accordingly. Also, it would be nice if you could add more technical details to the specification of the deliverables. And we don't fund the deployment or audit of a grant."

Hi Noc2,

I appreciate your detailed feedback on our application.

We've made significant improvements to our milestones to align them with the template structure and provide more technical context. In response to your suggestions, we've removed unnecessary sections, such as those related to Audit or Bounty.

To clarify, when we referred to "Substrate," we were actually talking about the Chain Name, not the underlying technology. To avoid any potential misunderstandings, we've now assigned specific names to each function.

We've also updated the Figma link to direct you to the precise design for your reference.

To sum it up, we've refined our milestones to focus on the following key areas:

1. API and Configuration
2. Main Dapp
3. Test and TestNet Deployment

Thank you for your guidance, and we hope these revisions address all the previous concerns.

Best Regards,
Andrea

Milestone

Overview

• Total Estimated Duration: 8 weeks
• Full-Time Equivalent (FTE): 5 FTE
• Total Costs: 25000 USD

Certainly, here are your milestones with the specified format:

Milestone 1: Configuration Module

• Estimated Duration: 2 weeks
• FTE: 1
• Costs: 5k

Number	Deliverable	Specification
0a.	License	Apply appropriate open-source licenses (e.g., Apache 2.0, GPLv3, MIT) to the project's codebase.
0b.	Documentation	Create comprehensive inline documentation for the codebase and a user-friendly tutorial explaining how to set up and use the Configuration Module.
0c.	Testing and Testing Guide	Develop unit tests covering core functions and provide a guide on how to run these tests.
0d.	Docker	Provide Dockerfile(s) for testing and deployment of the Configuration Module.
1.	Front-End Configuration Module	Develop a front-end module allowing users to select parameters such as Project Name, Logo, Names for Sale, Sales Price, Sale Strategy (single, collection, clubs), Name Services Options, and Currency to use (stable, chain token, native token). Additionally, provide design options including Colors, Fonts, Design, and Templates.
2.	API Development	Create API functionalities to read data from the Configuration Module.
3.	API Endpoint	Generate endpoints and variables for code generation and module options.
4.	DevNet Setup	Start using a Development Network (DevNet) to test and utilize the Configuration file.

Milestone 2: Main Dapp

• Estimated Duration: 4 weeks
• FTE: 3
• Costs: 15k

Number	Deliverable	Specification
0a.	License	Reiterate and confirm the open-source licenses applied to the project's codebase.
0b.	Documentation	Enhance inline documentation and the user tutorial to encompass new functionalities.
0c.	Testing and Testing Guide	Extend unit tests to cover new features, optimizations, and functionalities. Update the testing guide accordingly.
0d.	Docker	Optimize Dockerfile(s) for improved performance and efficiency in testing all functionalities.
1.	Dapp Front-End	Create the final application front end. The design and functionality will be applied from the Configuration Module, and the design and content will change based on the real data selected.
2.	Back-End Modular	Develop a modular backend that works seamlessly with the API and smart contract endpoint. This backend will be adaptable based on the selected data in the config file.
3.	Smart Contract Modular	Create modular smart contracts from existing Rust-based code, working with Pallets. The smart contracts will include core functionality such as Buy Domain, Sale Domain, Trade Domain, Domain Honor, Transfer Domain, Add Subdomain, Domain Primary Key, Create Profile, Edit Profile, and Read Real-Time Price.
4.	TestNet Set-Up	Begin using a testnet network to test Front-End, Back-End, and Smart Contract communication.

Milestone 3: Final Assembly and Mainnet

• Estimated Duration: 2 weeks
• FTE: 1
• Costs: 5k

Number	Deliverable	Specification
0a.	License	Validate and ensure compliance with selected open-source licenses for all components.
0b.	Documentation	Enhance documentation with optimization strategies, deployment guidelines, and strategies to engage the community effectively.
0c.	Testing and Testing Guide	Finalize and document testing processes, highlighting optimizations made, and ensuring the guide reflects the most up-to-date testing procedures.
0d.	Docker	Provide optimized Dockerfile(s) to streamline deployment processes and enhance efficiency.
1.	Finalize Main Dapp	Merge Dapp Front-End with Backend and Smart Contracts to finalize the full working Dapp for Decentralized Name Services.
2.	Testnet Test Coverage	Execute comprehensive test coverage on the TestNet environment, identifying and resolving issues to ensure a robust TestNet environment.
3.	SC Test Coverage	Develop a comprehensive smart contract test coverage suite, covering various scenarios and edge cases to rigorously test the smart contracts for reliability and security.
4.	Optimization and Performance Enhancement	Optimize the platform for enhanced performance, ensuring a smooth user experience and efficient resource utilization.

[semuelle]

Thank you for the application, @CodeXChainOfficial. I just requested access to the canva link. In the meantime, some general questions:

• Your whitepaper mentions EVM, Cosmos and Tron, but not Substrate, Polkadot or Kusama. Can you elaborate what has changed and how Polkadot fits into this picture?
• Your whitepaper also mentions trusted execution environments, but doesn't go into detail about how they are used at all. Could you elaborate?
• I see a bunch of repositories under your org that reference Substrate, but they are all frontends. Where are the smart contracts or pallets those refer to?
• One of your value propositions is a "zero code programming language", but other than a few React repos referring to this, I don't see any technical details or implementations. Can you elaborate?

[dsm-w3f]

Thank you for the grant application. We started this conversation in private by email, and as this application is now public we can continue the discussion here.

I saw that the application document improved but still needs some clarification regarding the prototypes. The Figma document has many prototypes and our application works like a contract when a grant is approved. In this way, we need the specification of at least the main screens that are in the scope of the project inside the application document. Furthermore, I saw in the figure that some squares were drawn to delimit the scope of the screens. Could you please clarify in the application document which ones are included in the grant proposal? Is it the blue square?

As far as I understood from the proposal, although the main purpose of Codex is to be a no-code platform, the scope of this grant proposal is a name service. In this way, could you please compare the proposal with these other grants that we approved and delivered other name services to our ecosystem?

Name Services
#1733
#1528

Would it be possible to continue your project using them as a name service or would you need to develop a new one from scratch?

Please also notice our open source stack page for more information about software available in the Polkadot ecosystem.

[CodeXChainOfficial]

"Thank you for the application, @CodeXChainOfficial. I just requested access to the canva link. In the meantime, some general questions:

Your whitepaper mentions EVM, Cosmos and Tron, but not Substrate, Polkadot or Kusama. Can you elaborate what has changed and how Polkadot fits into this picture?
Your whitepaper also mentions trusted execution environments, but doesn't go into detail about how they are used at all. Could you elaborate?
I see a bunch of repositories under your org that reference Substrate, but they are all frontends. Where are the smart contracts or pallets those refer to?
One of your value propositions is a "zero code programming language", but other than a few React repos referring to this, I don't see any technical details or implementations. Can you elaborate?"

Answer 1: Our vision for CodeX is to use Substrate as a layer 1 solution for our ecosystem. From this, we want to attract all the EVM, TVM and Cosmwasm users combining EVM and Cosmwasm technology, as it aligns with our goal to provide a versatile platform for developing applications across various blockchains. Our vision is to be MultiChain, so we are focusing to multiple technology like Rust, Solidity and more.

Answer 2:
Trusted Execution Environments (TEEs) in CodeX Blockchain:

1. Hardware-Based Security: TEEs, such as ARM TrustZone and Intel SGX, serve as a fundamental pillar of security within the CodeX blockchain. These hardware-based security features are integrated into the underlying infrastructure to provide a robust shield against various threats.

2. Isolation of Code and Data: TEEs create isolated execution environments known as "enclaves" within the processors. In the context of CodeX, these enclaves act as secure compartments where critical operations, including smart contract execution and sensitive data processing, take place. This isolation ensures that the code and data within the enclaves are shielded from any interference or unauthorized access, even by the host operating system or other applications running on the same device.

3. Tamper-Resistance: TEEs are designed to resist tampering and unauthorized modifications. Any attempts to tamper with the code or data inside the enclaves are detected, and the TEE can take appropriate actions to protect the integrity of the system.

4. Secure Data Handling: Within the TEE, sensitive data, such as private keys, cryptographic operations, and user credentials, can be handled with the utmost security. This ensures that data remains confidential and protected from theft or leakage, even if the hosting environment is compromised.

5. Remote Attestation: TEEs support remote attestation, a process that allows external parties to verify the authenticity and integrity of the enclave. In the context of CodeX, this means that other nodes in the blockchain network or external auditors can confirm that the smart contracts executing within TEEs are genuine, unaltered, and secure.

6. Enhanced Security for Smart Contracts: CodeX leverages TEEs to provide an added layer of security for its smart contracts. When smart contracts are deployed within TEEs, they benefit from the hardware-backed security, making them resistant to various attacks, including those aimed at exploiting vulnerabilities in the host environment.

7. Protection Against Insider Threats: TEEs are instrumental in protecting the blockchain network from insider threats, such as malicious actors with access to the hosting infrastructure. Even if an attacker gains control of the underlying system, the TEE ensures that critical blockchain operations remain secure.

Answer 3.
This is the Smart-Contracts deployed in Rust for Name Services, we want to adapt it to be used on Substrate and adding the modularity to be used as No-code platform.
https://github.com/CodeXChainOfficial/CodeXscs/tree/marko

Answer 4: I appreciate your inquiry. To clarify, our value proposition centers around a "no-code" application builder rather than a "zero-code programming language." Our approach allows users to create applications without writing code by providing an intuitive interface.
https://twitter.com/codexchain/status/1697546022300647857?t=SawcnelBKyhtm5rQHFAl2A&s=19

[CodeXChainOfficial]

"Thank you for the grant application. We started this conversation in private by email, and as this application is now public we can continue the discussion here.

I saw that the application document improved but still needs some clarification regarding the prototypes. The Figma document has many prototypes and our application works like a contract when a grant is approved. In this way, we need the specification of at least the main screens that are in the scope of the project inside the application document. Furthermore, I saw in the figure that some squares were drawn to delimit the scope of the screens. Could you please clarify in the application document which ones are included in the grant proposal? Is it the blue square?

As far as I understood from the proposal, although the main purpose of Codex is to be a no-code platform, the scope of this grant proposal is a name service. In this way, could you please compare the proposal with these other grants that we approved and delivered other name services to our ecosystem?

Name Services
#1733
#1528

Would it be possible to continue your project using them as a name service or would you need to develop a new one from scratch?

Please also notice our open source stack page for more information about software available in the Polkadot ecosystem."

Answer 1: The Figma link provided for the Name Services design refers to CodeX Name Services, which serves as a foundational template for our no-code application deployment platform. This means that each user can personalize their application, resulting in a unique and tailored outcome based on their selected settings and options.

Answer 2: The key distinction lies in our solution's ability to empower users to effortlessly create and customize their own Name Services without the need for any coding expertise. For instance, consider a project like PolkaVerse seeking to establish its Name Services. By leveraging CodeX, they can seamlessly configure their Name Services, such as offering .PolkaVerse domains, and swiftly launch their distinctive Name Services platform.

Link to Tweet

Answer 3:
Would it be possible to continue your project using them as a name service or would you need to develop a new one from scratch?

We can use one of them as a Template.

[dsm-w3f]

@CodeXChainOfficial thank you for the answers. I'll make the application ready for review of the committee. I'm personally won't approve it since the team seem to lack experience with our ecosystem to actually developing it. The other members of the committee could have a different opinion on that.

[semuelle]

Thanks for the replies, @CodeXChainOfficial. I'm afraid there are still too many technical details missing to properly evaluate the proposal. Also, your description of the use of TEEs doesn't actually answer the question. I also see in the video you linked that you are charging users per deployment, which makes little sense for an open source project. I am therefore not going to approve it.

[keeganquigley]

Hi @CodeXChainOfficial thanks again for your time and effort, and your interest in our grants program. Unfortunately, the application was unable to garner enough approvals from the committee to accept it, therefore I'm going to close it.

This is due to the above concerns and the fact that the requested technical details weren't added to the application. We hope this decision doesn't deter you from contributing to the ecosystem, and we wish you the best of luck in finding funding!