QENOVRA PUBLIC TESTNET / SOLIDITY PROJECTS

Bring your own Solidity project.

Develop with your preferred editor and toolchain, then either upload the Solidity sources to Contract Studio or deploy directly through the QENOVRA JSON-RPC with Hardhat, Foundry or another EVM-compatible tool.

Short answer: yes. Developers can write their own .sol contracts locally. For browser compilation/deployment, upload the required Solidity source files (or the whole Solidity project folder). For Hardhat/Foundry, no website upload is required: compile locally and deploy directly to the public RPC.

1. Choose your workflow

Workflow	What you provide	What QENOVRA does
Contract Studio	Your `.sol` source files or Solidity project folder.	Compiles in the QENOVRA developer service, lets you choose the compiled contract, connects your wallet and broadcasts the deployment transaction.
Hardhat / Foundry / other EVM tools	Your normal local project files and a local test wallet.	Your tool connects directly to `https://rpc-testnet.qenovra.com`. Nothing has to be uploaded to QENOVRA before deployment.
Explorer source verification	The exact source set and compiler settings used to produce the deployed bytecode.	The Explorer compares the supplied build input against the deployed contract bytecode and publishes verified source when it matches.

2. Browser upload: what files are needed?

If you use Contract Studio, upload every Solidity source file needed by the contract. Relative import paths are preserved when you choose a project folder.

my-project/
  contracts/
    ProjectGreeter.sol
    GreetingLib.sol
    interfaces/
      IExample.sol

You do not need to upload Hardhat's node_modules, build artifacts, cache folders or a private key. Contract Studio compiles the Solidity source itself.

Current browser compiler limits: up to 12 .sol files and 72 KB total source size. Remote URL imports are not fetched automatically; include imported Solidity sources in the upload. Contracts that depend on externally linked libraries or advanced build steps may be better deployed with Hardhat or Foundry.

3. Local toolchains: no upload required

Hardhat, Foundry, Remix-compatible tooling and other standard EVM development environments can connect directly to QENOVRA Public Testnet.

Network: QENOVRA Public Testnet
Chain ID: 7992501
RPC: https://rpc-testnet.qenovra.com
Explorer: https://explorer.qenovra.com
Native test asset: tQEN
Decimals: 18

Keep your signing key in your local keystore, environment secret, hardware wallet or another local secret mechanism. Do not put it in source code and do not send it to QENOVRA servers.

Open Hardhat / Foundry Quickstart Hardhat config Foundry config

4. Typical Hardhat project

my-hardhat-project/
  contracts/
    MyContract.sol
  ignition/
    modules/
      MyContractModule.ts
  hardhat.config.ts
  package.json
  package-lock.json

For QENOVRA deployment, the important parts are your Solidity sources, the network configuration, and your local deployment script/module. Build output such as artifacts/ is generated locally and is not uploaded to the blockchain.

5. Typical Foundry project

my-foundry-project/
  src/
    MyContract.sol
  script/
    Deploy.s.sol
  foundry.toml

Again, the contract sources and your deployment script stay under your control. Foundry sends only the signed deployment transaction and bytecode through the RPC.

6. Which Solidity version should I use?

Do not choose Solidity 0.8.26 just because it appears in the QENOVRA examples. Version 0.8.26 is the pinned Contract Studio/reference-tooling baseline. A local Hardhat or Foundry project may use another Solidity compiler version required by its source code and dependencies.

Use these rules:

Situation	Compiler rule
Using Contract Studio in the browser	Use source compatible with the browser's pinned Solidity `0.8.26` compiler.
Using Hardhat / Foundry locally	Use the compiler version your project requires. Do not change a working project's pragma only to match the sample.
Current QENOVRA Public Testnet EVM target	Explicitly compile for `shanghai` until QENOVRA publishes an EVM-target upgrade.
Explorer source verification	Select the exact compiler version used to deploy, including the commit/build version when the verifier asks for it. If you deployed with 0.8.32, verify with that exact 0.8.32 compiler build—not 0.8.26.

7. After deployment: verify the source

Deployment puts bytecode on-chain, but it does not automatically publish your source code. To make the contract readable in Explorer, verify it after deployment.

For multi-file projects, Solidity Standard JSON input is the most reliable verification format because it preserves file paths and compiler settings. Use the exact compiler version, EVM version, optimizer settings, source paths and source contents used during deployment.

QENOVRA Contract Studio reference settings
Solidity: 0.8.26   ← browser/reference baseline only
EVM version: shanghai
Optimizer: enabled
Optimizer runs: 200

Local Hardhat / Foundry projects:
Solidity: use the exact version required by your project
EVM version: shanghai (current QENOVRA Public Testnet target)
Verification: use the exact compiler version that created the deployed bytecode

8. What goes on-chain?

The blockchain receives the signed deployment transaction, constructor data and compiled bytecode. Your source tree, local build system, private key, Git repository and development machine do not get uploaded to the chain.

9. Recommended developer flow

Build locally → compile → test → obtain test tQEN → deploy to QENOVRA Public Testnet → confirm the transaction in Explorer → verify the exact source → interact with the contract → only then prepare production/mainnet work.

Open Contract Studio Get test tQEN Open Explorer