28. Building on Kortana (Solidity)

Developing smart contracts in Solidity on Kortana provides a seamless workflow for Ethereum engineers, combining 100% EVM Cancun opcode compatibility with the instant 1.5-second settlement of Kortana Consensus.

28.1 Using MetaMask

MetaMask connects to the Kortana network via standard JSON-RPC endpoints. Developers configure network settings by providing the RPC URL (https://poseidon-rpc.testnet.kortana.xyz/ for Testnet or https://zeus-rpc.mainnet.kortana.xyz/ for Mainnet), the decimal Chain ID (72511 or 9002), and the native currency symbol DNR.

Once connected, MetaMask interacts with Kortana identically to Ethereum. It queries account balances via eth_getBalance, estimates gas through eth_estimateGas, and constructs EIP-1559 typed transactions with dynamic base fee and priority tip calculations. When users sign transactions, MetaMask applies standard secp256k1 ECDSA algorithms, generating signature bytes that the Kortana node recovers and validates instantly.

28.2 Using Hardhat

Hardhat projects integrate with Kortana by defining network configurations in hardhat.config.js. Developers specify the Solidity compiler version (recommended 0.8.24 with Cancun EVM target) and declare network connection parameters:

module.exports = {
  solidity: {
    version: "0.8.24",
    settings: {
      evmVersion: "cancun",
      optimizer: { enabled: true, runs: 200 }
    }
  },
  networks: {
    kortana_testnet: {
      url: "https://poseidon-rpc.testnet.kortana.xyz/",
      chainId: 72511,
      accounts: [process.env.PRIVATE_KEY]
    }
  }
};

Hardhat deployment scripts, automated unit testing with Mocha/Chai, and contract verification plugins run against Kortana without requiring custom network adapters.

28.3 Using Foundry

Foundry provides ultra-fast contract compilation, testing, and deployment natively suited for Kortana's high-speed consensus. Because Kortana's KEVM supports the Cancun hard fork, Foundry features like transient storage tests (tstore/tload) and memory copying (mcopy) execute flawlessly.

Deploying a smart contract with Foundry's forge create requires only standard RPC and private key flags:

forge create src/MyToken.sol:MyToken \
  --rpc-url https://poseidon-rpc.testnet.kortana.xyz/ \
  --private-key $PRIVATE_KEY \
  --constructor-args "Kortana Token" "KTN" 1000000000000000000000000

Developers can also use cast call and cast send to interact with deployed contracts directly from the terminal.

28.4 Using ethers.js / viem

Client applications and automated backend services communicate with Kortana smart contracts using standard TypeScript libraries such as ethers.js (v5/v6) and viem.

To establish a connection, developers initialize a JsonRpcProvider (ethers) or a createPublicClient / createWalletClient pair (viem). When sending contract calls, these SDKs format JSON-RPC payloads, encode method calldata according to the contract's ABI, and parse emitted event logs from transaction receipts. If a transaction reverts, the SDKs transparently decode the standard Error(string) selector (0x08c379a0) or custom panic codes returned by the KEVM.

28.5 & 28.6 Deploying ERC-20 / ERC-721

Standard smart contract token implementations from OpenZeppelin—including ERC-20, ERC-721, ERC-1155, and modern extensions like EIP-2612 permit—compile and deploy to Kortana with 100% behavioral parity.

Storage slots for account balances, token allowances, ownership records, and metadata URIs map directly into the contract's sub-trie in the Merkle-Patricia State Trie. Gas consumption for storage updates (SSTORE) and log emissions (LOG0-LOG4) conforms strictly to Ethereum Cancun gas schedules, ensuring predictable execution economics across all asset contracts.

28.7 Contract Verification

Smart contract verification allows developers to publish their Solidity source code to the Kortana Block Explorer, enabling users and auditors to verify that deployed on-chain bytecode matches the compiled source code.

Verification is conducted via the Block Explorer API. The verification engine recompiles the submitted source code using the exact compiler version, optimization run settings, and EVM target, then compares the generated runtime bytecode against the bytecode stored in the state trie. Once matched, the explorer displays the verified source code, ABI interface, and interactive read/write contract tabs.

---