Technical transparency
before launch.

Overview

Current project status

The website is live. An experimental Kinacoin contract is deployed on Ethereum Sepolia (chain ID 11155111). Its verified code includes ownership controls, a mint function, a supply cap and permit functionality. Those features differ from the fixed-supply proposal described below.

View the experimental contract and deployment evidence. Source verification is not a security audit. Test tokens have no promised financial value and should not be treated as launch tokens. The final launch design must be decided, tested and reviewed before deployment.

Proposed launch design

Kinacoin (KIN) is intended as a fixed-supply fungible token implemented using the ERC-20 standard. The intended total supply is 1,000,000,000 KIN with 18 decimal places. Under this proposal, the entire supply would be created once during contract deployment and assigned to the deployment-selected initialRecipient.

Kinacoin’s education, community initiatives, ecosystem programs and possible future applications are separate from the immutable supply rules intended for the deployed token contract.

Proposed token information

Proposed fixed-supply design

The complete intended supply is minted in the constructor to initialRecipient. The contract does not expose a public or privileged mechanism to change supply after deployment.

No future governance vote, team decision or external application can change the KIN supply through this minimal token contract. Separate applications could have their own rules, which must be disclosed independently.

Proposed contract specification

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.34;

import {ERC20} from
  "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract Kinacoin is ERC20 {
  uint256 public constant INITIAL_SUPPLY =
    1_000_000_000 * 10 ** 18;

  constructor(address initialRecipient)
    ERC20("Kinacoin", "KIN")
  {
    _mint(initialRecipient, INITIAL_SUPPLY);
  }
}

The intended contract inherits standard ERC-20 behavior from OpenZeppelin. It does not inherit Ownable, AccessControl or an upgradeable framework. The standard Transfer and Approval events apply.

Token allocation

The contract assigns 100% of supply to the confirmed initial recipient at deployment. The final allocation between liquidity, treasury, ecosystem, contributors and community programs is not yet finalised. Percentages, recipient wallets and vesting terms must be published before or at launch.

Ecosystem and governance

Potential governance, if introduced, will be documented separately with its scope, voting method, eligibility, execution mechanisms and risks. It cannot add authority to a deployed token contract that does not contain that authority.

Security considerations

Minimal custom logic can reduce the token contract’s attack surface, but does not eliminate blockchain, wallet, dependency, deployment or user risks. Before deployment, the project should pin the OpenZeppelin release, test exact source and settings, independently verify recipient addresses, record source hashes and consider an independent security review.

User safety

• ERC-20 approvals can permit third parties to transfer approved amounts.
• Public blockchain transactions are generally irreversible.
• Phishing, counterfeit tokens and compromised keys can cause permanent loss.
• Third-party exchanges, bridges, pools and wallets carry separate risks.
• The intended contract has no freezing, reversal or recovery mechanism.

Launch checklist

Before launch deployment

• Decide the final token design and document how it differs from the Sepolia experiment.
• Finalise and review exact Solidity source.
• Pin dependencies, compiler, optimizer and EVM settings.
• Confirm network, chain ID and initial recipient independently.
• Test the exact intended deployment configuration.
• Finalise allocation and wallet disclosures.
• Prepare anti-impersonation guidance and official channels.

At and after deployment

• Record and publish the deployment transaction and contract address.
• Verify source code through the appropriate block explorer.
• Confirm name, symbol, decimals, supply and initial balance on-chain.
• Publish compiler settings, dependency version and source commit.
• Publish audits only when scope, date, report and reviewer are identified.

Contract verification

Public verification requires the network, chain ID, contract address, deployment transaction, deployer, initial recipient, compiler settings, OpenZeppelin version, constructor argument, source verification URL and repository commit. Independent users should confirm name(), symbol(), decimals() and totalSupply() directly.

Transparency commitments

Kinacoin intends to maintain canonical contract information, verified-source links, material wallet disclosures, security notices, project updates and corrections through official channels. A name, ticker, account or token contract is not official merely because it uses “Kinacoin” or “KIN.”

Risks

KIN may involve price volatility, limited or no liquidity, smart-contract and network risks, phishing and fraud, third-party platform failure, regulatory and tax changes, and lack of adoption, utility or demand. Fixed supply does not guarantee value, liquidity, listing, adoption or any economic outcome.

Disclaimer

This document is informational only. It is not financial, investment, legal, tax, regulatory or accounting advice, and is not an offer, solicitation, recommendation or promise. Only verified deployed code and relevant blockchain state determine on-chain behavior.