# What is Creditcoin The latest version of the Creditcoin network transforms the RWA protocol into an EVM-compatible layer 1 blockchain. Creditcoin was recently extended with a new ground breaking innovation: Universal Smart Contracts. Universal Smart Contracts on Creditcoin are able to coordinate, interact with, and update smart contracts across multiple blockchains, enabling the development of native multichain applications. With the release of Creditcoin’s EVM-compatibility, it is important to distinguish it from earlier versions of the protocol. The previous Substrate version of the Creditcoin network (2.0+ and earlier) is now referred to as CC Enterprise. The EVM-compatible version of Creditcoin is simply referred to as Creditcoin. Creditcoin was developed in two phases: * **EVM-Compatibility (Phase 1)**: The first goal was to transform Creditcoin into a fully EVM-compatible layer 1 blockchain. This enables anyone to program new smart contracts for Creditcoin using the same programming language and techniques used by Ethereum and other EVM-compatible blockchains. By leveraging these existing EVM network effects, Creditcoin benefits from lower dApp development costs and lead times. In summary, as an EVM-compatible protocol, Creditcoin will allow developers to build a wide range of related applications, protocols, and more, directly on the Creditcoin blockchain, in addition to all existing credit capabilities. * **Universal Smart Contracts (Phase 2 - Currently Released on Mainnet)**: Phase 2 involves the release of Universal Smart Contracts. With USC, Creditcoin developers can natively access information and events on other L1 blockchains, such as Bitcoin and Ethereum. By providing native access to multi-blockchain event data through a standardized interface, Creditcoin allows developers to coordinate smart contracts across multiple chains. In summary, USC makes it safer and simpler to deploy novel multi-chain applications. With this release Creditcoin can become the Universal Smart Contract Layer of Web3. Explore the visual overview of Creditcoin:
**Read more about Creditcoin’s main components:** * [Nominated Proof-of-Stake Consensus](/nominator-guides/nominating-without-staking-pools) * [Wallets](/wallets) * [Creditcoin CLI tool](/wallets/how-to-connect-your-wallet-to-creditcoin/command-line-interface/creditcoin-cli) * [Nominator Guides](/nominator-guides) * [Validator Guides](/validator-guides) * [EVM-compatibility](/evm-compatibility) * [Smart Contracts](/smart-contract-guides) # CTC Token 101 1. **Mainnet CTC (Native)** – Used on Creditcoin’s **Native chain** for staking, validator roles, and network participation. 2. **Mainnet CTC (EVM)** – Compatible with **EVM-based smart contracts** for DeFi apps on Creditcoin’s EVM environment. * **Smart Contracts**: Use **Mainnet** **CTC (EVM)** to interact with dApps on Creditcoin’s EVM chain. * **Gas Fees**: Pay with **Mainnet CTC (Native)** for Substrate transactions and **Mainnet CTC (EVM)** for EVM-based transactions. * **Staking**: Stake **Mainnet CTC (Native)** to secure the network and earn rewards. * **DeFi**: Access Ethereum-compatible DeFi applications directly with **Mainnet CTC (EVM)**. ### **CTC Token 101** #### **What is CTC?** CTC is the native token that powers the Creditcoin ecosystem. It uses a multichain token architecture that enables network security, smart contract interactions, cross-chain liquidity, and decentralized governance. This guide explains the different CTC token types and how they work across Creditcoin's Substrate and EVM layers, as well as Ethereum. #### **CTC on Creditcoin** Two primary forms of CTC exist within the Creditcoin network: [**CTC (Native)**](https://creditcoin.subscan.io/assets?tab=system): Used on the Creditcoin network for staking, governance, validator participation, and payment of Substrate-based transaction fees. [**CTC**](https://creditcoin.blockscout.com/): Powers Creditcoin's EVM layer. Used for smart contract interactions with dApps, trading on Penguinswap for ecosystem tokens, and paying gas fees on Creditcoin EVM. Learn how to bridge between CTC (Native) and CTC (EVM) using Credit Wallet [here](https://creditcoin.org/blog/how-to-convert-mainnet-ctc-native-to-mainnet-ctc-evm-a-step-by-step-guide/). #### **CTC on Ethereum** [**CTC (G-CRE)**](https://etherscan.io/token/0xa3ee21c306a700e682abcdfe9baa6a08f3820419): Creditcoin's ERC-20 token is available and listed as CTC on major centralized exchanges, and the same version is listed as G-CRE on decentralized exchanges. It's often the easiest way to get started, as you can bridge it to the Creditcoin network using the [Swap CTC](https://creditcoin.org/SwapCTC/) tool. [**WCTC (new)**](https://etherscan.io/token/0xeB32AD88b09fB94129a8B972876Ad02EaAc91E53?ref=creditcoin.org): Upgraded wrapped token version of Creditcoin’s native token on Ethereum, enabling seamless transfers between the Creditcoin, Ethereum, and BSC networks. Unlock cross-chain DeFi access! Available on [Uniswap](https://app.uniswap.org/explore/tokens/ethereum/0xeb32ad88b09fb94129a8b972876ad02eaac91e53?inputCurrency=0xdAC17F958D2ee523a2206206994597C13D831ec7). [**WCTC (old)**](https://etherscan.io/token/0xaafec8e08d524d534327fa13fb306f440b5f88eb?ref=creditcoin.org): Legacy wrapped token with limited Uniswap liquidity, gradually being deprecated. #### **Switch Assets Between Networks** Move CTC tokens between supported networks using: * [Swap CTC tool](https://creditcoin.org/SwapCTC/): One-way bridge from CTC (G-CRE) to CTC. * [Wormhole Portal Bridge](https://portalbridge.com/): Two-way bridge for WCTC supporting cross-chain transfers between Creditcoin, Ethereum, and BSC. ### Why Use CTC? CTC enables you to participate in and benefit from the Creditcoin ecosystem. Whether you're earning staking rewards, building on the EVM layer, voting on protocol upgrades, or accessing airdrops from emerging projects, it's how you access and engage with the network built for purpose-driven missions. 💡 **Ready to get started?** Learn how to acquire CTC assets [here.](https://docs.creditcoin.org/what-is-creditcoin/acquiring-creditcoin-assets) # Acquiring Creditcoin Assets The Creditcoin ecosystem uses multiple CTC assets across different networks, each serving a specific purpose, from powering transactions to enabling staking and cross-chain transfers. This guide shows you how to **acquire CTC assets on Ethereum and bridge them to the Creditcoin network** to participate in DeFi, dApps, staking, and trading ecosystem tokens on Penguinswap. > 💡 Learn more about CTC assets in our[ CTC token 101](https://docs.creditcoin.org/what-is-creditcoin/ctc-token-101) guide. ## **How to Get CTC: A Step-by-Step Guide** ### Step 1: Set Up Your Wallet Before acquiring or bridging assets, set up your **Credit Wallet,** your gateway to the Creditcoin network and its ecosystem tokens. 1. Download and install [**Credit Wallet**](https://creditcoin.org/Credit-Wallet/) 2. Create or import your EVM wallet. 3. If creating a new one, be sure to back up your private key or recovery phrase securely. ### Step 2: Acquire Creditcoin Assets on Ethereum We offer the **flexibility** to acquire CTC assets on Ethereum in **two ways**, depending on your preference: **centralized** or **decentralized**. #### **Option 1: Centralized – CTC via Exchanges** **Best for:** Simple access and liquidity Buy CTC on [supported exchanges](https://coinmarketcap.com/currencies/creditcoin/#Markets). #### **Option 2: Decentralized – CTC (ERC-20) via Uniswap** **Best for:** Multi-chain features and DeFi Two Ethereum-based tokens are available: 1. [WCTC](https://etherscan.io/token/0xeB32AD88b09fB94129a8B972876Ad02EaAc91E53?ref=creditcoin.org) (new). Acquire directly [here.](https://app.uniswap.org/explore/tokens/ethereum/0xeb32ad88b09fb94129a8b972876ad02eaac91e53?inputCurrency=0xdAC17F958D2ee523a2206206994597C13D831ec7) 2. For DEXs, CTC **(ERC-20)** is also known as G-CRE. Acquire [G-CRE](https://etherscan.io/token/0xa3ee21c306a700e682abcdfe9baa6a08f3820419) directly [here.](https://app.uniswap.org/explore/tokens/ethereum/0xa3ee21c306a700e682abcdfe9baa6a08f3820419) Note: You’ll need **ETH** for gas fees to complete the transaction. 💡 You can also use **USDT** on Ethereum to get started. See next section. ### Bonus: Bridge to the Creditcoin Network To participate in the Creditcoin ecosystem, bridge your CTC to the Creditcoin network to trade on [**Penguinswap**](https://penguinswap.org/), access dApps and ecosystem tokens, and pay for transaction fees. #### **What token are you bridging?** #### **I have CTC (G-CRE)** Use the [**SwapCTC Tool**](https://creditcoin.org/SwapCTC/) to request a **one-way bridge** for your CTC (G-CRE) tokens to the Creditcoin network. Please note that this is a manual process that takes up to 1 week to complete. For detailed instructions, check out our [**SwapCTC Bridge Tutorial**](https://docs.creditcoin.org/swapctc-quick-guide)**.** #### **I have WCTC on Ethereum or BNB (recommended path)** Use the [**Wormhole Portal Bridge**](https://portalbridge.com/?sourceChain=ethereum\&targetChain=creditcoin\&asset=USDT\&targetAsset=USDT) to move tokens across **Ethereum, BNB,** and **Creditcoin**. Connect your wallet to Portal Bridge and select **Creditcoin** as the destination network and **CTC** as the token asset. **After bridging, you will receive** [**CTC**](https://creditcoin.blockscout.com/) **on the Creditcoin Network.** This CTC can be used immediately as **bridge fees**.\ \ \*Bridge your assets back to Ethereum or BNB at any time. #### **I have USDT on Ethereum** Bridge **USDT** to **Creditcoin** using the [**Wormhole Portal Bridge**](https://portalbridge.com/?sourceChain=creditcoin\&targetChain=ethereum\&asset=0xb41015d1D3603aed12a5f6098A34BeE56808eF45\&targetAsset=0xdAC17F958D2ee523a2206206994597C13D831ec7\&ref=penguinswap.org), and receive **USDT.C at a 1:1 ratio.** #### **Important Notes** * **Bridge fees are charged on the source chain.** * **All token swaps on Creditcoin require CTC for gas fees.** ### Bonus #2: Stake CTC, and Earn Yield If you wish to earn yield on your CTC, [**convert to CTC (Native)**](https://creditcoin.org/blog/how-to-convert-mainnet-ctc-native-to-mainnet-ctc-evm-a-step-by-step-guide/) for staking on the Creditcoin Mainnet. *** ## **Join the Creditcoin Movement** Start your journey with Creditcoin today and unlock a seamless, interoperable experience via EVM-compatible smart contracts and digital assets. # Swap CTC Quick Guide This guide has been updated to reflect changes to Swap CTC. Please note that CTC users can now move assets between Creditcoin, BSC, and Ethereum using the Wormhole Portal Bridge. For more details, go to this [guide](https://docs.creditcoin.org/what-is-creditcoin/acquiring-creditcoin-assets). *** ## **How to Use SwapCTC** Swap CTC supports one-way bridging routes to the Creditcoin Mainnet: 1. [G-CRE](https://etherscan.io/token/0xa3ee21c306a700e682abcdfe9baa6a08f3820419) → [CTC](https://creditcoin.blockscout.com/) (Creditcoin) 2. [WCTC (old)](https://etherscan.io/token/0xaafec8e08d524d534327fa13fb306f440b5f88eb?ref=creditcoin.org) → [CTC](https://creditcoin.blockscout.com/) (Creditcoin) #### **Step 1: Open the SwapCTC Tool** Go to the [Swap CTC](https://creditcoin.org/SwapCTC/) webpage. #### **Step 2: Send Tokens to the Bridging Address** Send your G-CRE or WCTC (old) tokens to the official Creditcoin Foundation address: **0x6524653466b9E0E9d515103873e4005Dd99c560F** Make sure you have enough ETH to cover gas fees. #### **Step 3: Processing** The Creditcoin Foundation will process your swap within 1–2 weeks. You will receive CTC at a 1:1 ratio at the same EVM address used to send the tokens — no further action required. #### **Step 4: Track Your Tokens** Once processed, you can view your CTC balance using: * [Credit Wallet](https://creditcoin.org/Credit-Wallet/) * MetaMask (after adding the Creditcoin Network) * [Creditcoin Blockscout](https://creditcoin.blockscout.com/) ### **What You Can Do With CTC** After receiving your CTC on the Creditcoin Network, you can: * Use it in dApps and DeFi platforms built on Creditcoin. * Trade CTC for other ecosystem tokens on [Penguinswap.](https://penguinswap.org/) * Bridge assets via the Wormhole [Portal Bridge](https://portalbridge.com/) to Ethereum or BNB. * Convert [CTC to CTC (Native)](https://creditcoin.org/blog/how-to-convert-mainnet-ctc-native-to-mainnet-ctc-evm-a-step-by-step-guide/) using Credit Wallet to stake and earn rewards. ### **Security and Transparency** #### **Verify the Swap Address** Always confirm the official swap address through: * A verified Discord admin * Email: #### **Transparency Addresses** For transparency, you can verify the official Creditcoin Foundation storage addresses: * EVM: 0x29Cb375c0BA5Dc475F1a5BCec2d8b87C9DA7B883 * Native: 5DDYL8H9sVhVS3P17TBiPMZVKt4GEc24G37ov4xXykvdBDTs All received tokens (G-CRE and WCTC old) are regularly batch-burned after swaps are completed. ### **Adding Creditcoin to MetaMask** Network Name: Creditcoin RPC URL: Chain ID: 102030 Ticker: CTC Block explorer URL: Once added, your CTC balance will appear in MetaMask. For detailed setup, refer to the MetaMask Connection Guide. # Wallets A blockchain wallet is an essential tool for managing and securing your digital assets on a blockchain network. In the world of blockchain technology, an account consists of a public-private key pair, and the private key is the key to accessing and controlling the transactions associated with that account. It is critical to keep the private key in a safe place since anyone with access to it has full control over the associated assets. ### Types of wallets **Internet Access: Hot & Cold Wallets** Blockchain wallets come in different forms: hot wallets and cold wallets. Hot wallets, accessible through browser extensions or smartphone apps, are considered online and provide convenient access but are potentially more vulnerable to hacking. On the other hand, cold wallets, stored in air-gapped devices or hardware wallets, are offline and provide enhanced security by isolating the private keys from potential online threats. **Key Management: Custodial & Non-Custodial Wallets** The distinction between custodial and non-custodial wallets is also crucial. Custodial wallets, often provided by centralized exchanges, grant control of private keys to a third party. This arrangement means that users must trust the exchange to safeguard their keys and provide access when needed. In contrast, non-custodial wallets give users exclusive control over their account's private key, ensuring complete ownership and security of their digital assets. All wallets covered by the Creditcoin Documentation are non-custodial. > :warning:When selecting a wallet, it is crucial to conduct your own thorough research to ensure the wallet's security, reputation, and compatibility with your specific needs, as well as to verify its authenticity. ### Browser Wallets Browser wallets, also known as web-based wallets, provide convenient access to your blockchain assets through a browser extension, eliminating the need for additional hardware or software installations. Browser wallets often have user-friendly interfaces and can be accessed from multiple devices, allowing for seamless management of your digital assets. However, browser wallets may be more vulnerable to online security threats. Since they are connected to the internet, there is a higher risk of hacking or phishing attacks that could compromise private keys and lead to the loss of your funds. It is crucial to verify the wallet is installed in a safe environment; where both device and browser software are not compromised. Several available browser wallets are compatible with the Creditcoin blockchain. Some only allow interactions with the Substrate or EVM features, while others cover both use cases. Supported Browser Wallets: * Polkadot-JS Extension (Substrate) * [Metamask (EVM)](/wallets/how-to-connect-your-wallet-to-creditcoin/metamask) * Talisman (Substrate and EVM) * Subwallet (Substrate and EVM) # How to Connect Your Wallet to Creditcoin * [Polkadot-JS Extension](/wallets/how-to-connect-your-wallet-to-creditcoin/polkadot-js-extension) * [Metamask](/wallets/how-to-connect-your-wallet-to-creditcoin/metamask) * [Command-line Interface](/wallets/how-to-connect-your-wallet-to-creditcoin/command-line-interface) # Polkadot-JS Extension **Creating a new account** Install the Polkadot-JS [browser extension](https://polkadot.js.org/extension/) on Chrome or Firefox.
Once installed, click on the Polkadot-JS extension icon to open up the account menu. Create one by selecting the plus sign (+) and following the instructions. Be sure to write down your recovery seed; it is the only way to recover access to your account.
You should see your newly created accounts when opening the extension’s menu. #### Importing an Existing Account To import an existing Substrate account, click on the plus sign (+) in the upper right corner of the extension modal and select “Import account from pre-existing seed” instead. Enter your seed phrase, give a name to your account and enter the password that will be required when signing extrinsics. #### Connecting to Creditcoin Polkadot-JS APPS is a web UI for interacting with Substrate based nodes like Creditcoin. It allows users to interact with the Creditcoin blockchain. Open the [Polkadot-JS UI ](https://polkadot.js.org/)site using either the Polkadot hosted or IPFS version. In the upper-left corner, click on the network ID to open the menu and select “custom endpoint” at the bottom of the menu.
Enter the URL for the desired Creditcoin network. {% hint style="info" %} If you don’t know which environment you should be connecting to, refer to the Environments page to get a better understanding of the different networks and their available public endpoints. {% endhint %} Click on Switch to apply connect to your node. # Metamask **First Step : Install MetaMask Extension** If you haven't already, install the MetaMask extension in your browser. You can find it in the Chrome Web Store or other browser extension stores.\ \ **1. Connecting Via Chainlist** 1.1 Choose your network : * For Mainnet : * For Testnet : 1.2 Click on "Connect Wallet" (If you haven't connected Chainlist before) 1.3 Select Metamask and select your desired wallet address 1.4 Once your wallet has been connected, click on "Add to Metamask" 1.5 Approve to add the Creditcoin Test network 1.6 Click on "Switch Network" to switch to the desired network\ \ **2. Connecting manually via Metamask** **2.1 : Accessing the Network Selection** 1. Click on the MetaMask extension icon in your browser's toolbar. 2. If you're using the latest version of MetaMask, click on your the network dropdown in the top left corner. **2.2 : Adding a Custom Network** 1. In the dropdown menu, select "Add Network" **2.3 : Fill in Network Details** 1. Mainnet 1. **Network Name**: Creditcoin 2. **New RPC URL**: `https://mainnet3.creditcoin.network` 3. **Chain ID**: `102030` 4. **Currency Symbol**: CTC 5. **Block Explorer URL**: [`https://creditcoin.blockscout.com/`](https://creditcoin.blockscout.com/) 2. Testnet 1. **Network Name**: Creditcoin Testnet 2. **New RPC URL**: `https://rpc.cc3-testnet.creditcoin.network/` 3. **Chain ID**: `102031` 4. **Currency Symbol**: tCTC 5. **Block Explorer URL**: `https://creditcoin-testnet.blockscout.com/` 3. Local node (Advanced configuration - requires local node) 1. **Network Name**: Creditcoin Local 2. **New RPC URL**: `http://127.0.0.1:9944` 3. **Chain ID**: `42` 4. **Currency Symbol**: CTC **2.4 : Save and Connect** 1. Once you've filled in the details, click "Save" or "Add Network." 2. After adding the network, go back to the MetaMask dropdown menu. 3. Click on the network name displayed at the top of the menu (it might currently show "Ethereum Mainnet" or another network). 4. Select the network you just added from the dropdown list. # Command-line Interface A command-line interface (CLI) wallet is a type of digital wallet that operates through a command-line interface rather than a graphical user interface (GUI). Unlike GUI wallets, which provide a visual interface with buttons and menus for interacting with the wallet, CLI wallets are text-based and require users to input commands directly into a command-line terminal or console. This type of wallet is typically favored by advanced users or developers who prefer the flexibility and control offered by the command line. With a CLI wallet, users can perform tasks such as checking their account balance, sending or receiving cryptocurrency, generating new addresses, and managing other wallet-related functions. CLI wallets often provide a range of commands and options that allow users to customize their interactions with the wallet and automate certain tasks using scripts or programs. # Subkey You can use the following subcommands with the `subkey` command. For more detailed information about using Subkey, refer to their [official documentation](https://docs.substrate.io/reference/command-line-tools/subkey/). | **Command** | **Description** | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `generate` | Generates a random account key. | | `generate-node-key` | Generates a random node `libp2p` secret key. You can save the secret key to a file or display it as standard output (`stdout`). | | `help` | Displays usage information for `subkey` or for a specified subcommand. | | `inspect` | Displays the public key and SS58 address for the secret URI you specify. | | `inspect-node-key` | Displays the peer ID that corresponds with the secret node key in the file name you specify. | | `sign` | Signs a message with the secret key you specify. | | `vanity` | Generates a seed that provides a vanity address. | | `verify` | Verifies the signature for a message is valid for the public or secret key you specify. | # Creditcoin CLI `creditcoin` is a terminal-based general-purpose tool developed by the Creditcoin team and includes all the essential functionalities required to manage CTC balances, manage nominator and validator accounts, and initialize EVM accounts. The `creditcoin` terminal is available in the docker image specified in the [Using a Docker container](/validator-guides/using-a-docker-container) guide. {% hint style="warning" %} Creditcoin CLI is recommended for users with previous CLI and technical experience. If you have no systems administrator or CLI tools experience, consider using a GUI wallet. For detailed information about the Creditcoin CLI refer to the documentation on Github or use the `--help` command. {% endhint %} **Creating accounts** Create accounts using the `new` command and write down the newly generated mnemonic phrase and store it securely. ``` creditcoin new ``` **Sending & Receiving CTC** The CLI tool also allows sending and receiving CTC. To send funds use the `send` command as shown below. It will prompt you for the seed phrase of the account from which funds will be sent. ``` creditcoin send --amount --substrate-address
``` To receive CTC, you can provide the sender with the receiving account's address. **Showing an Account's Address** To get an account's address from its seed phrase, use the `show-address` command. The `show-address` command will prompt you for the seed phrase. ``` creditcoin show-address ``` **Checking your Balance** You can check the balance of an account using the command below. This is an unauthenticated command; it does not require the private key or seed phrase to the account. Verify that `creditcoin` is connected to a node you trust to provide you with accurate data. You can check the balance of any account without incurring transaction fees. ``` creditcoin balance --substrate-address
``` **Staking** You can stake CTC by using the `bond` command with an amount. You will be prompted for your stash account's seed phrase. You can use the `--reward-destination` flag to change how the staking rewards will be handled. The default is `Staked`, which will re-stake the rewards, but it can be changed to `Stash` to keep them unstaked and available to use. ``` creditcoin bond --amount --reward-destination ``` Once CTC was successfully bonded, the account can be used to set up a new validator node or nominate validators. {% hint style="success" %} If you want to set up a [Validator ](/validator-guides)or become a [Nominator](/nominator-guides), read the detailed guides and make sure you understand both the risks and the responsibilities. {% endhint %} **Interacting with EVM accounts** You can also use the CLI to fund EVM accounts and withdraw CTC received from an EVM transfer using the `evm` command. You can fund an EVM account using a Substrate account with the `fund` command: ``` creditcoin evm fund --amount --evm-address
``` To withdraw from the EVM side, you must send funds to the EVM account associated to your Substrate account. Get your associated EVM address with the `convert-address` command. {% hint style="warning" %} The conversion done by the `convert-address` command is not a two-way function. If you run it again using the resulting address you will get yet another different Substrate or EVM address. Make sure you have the private keys for the account you are converting before sending funds to its associated address. {% endhint %} ``` creditcoin convert-address
``` Then send funds to your associated EVM account from any EVM account and withdraw them by running the `withdraw` command. ``` creditcoin evm withdraw ``` This will transfer all CTC from your associated EVM account to your Substrate account. **For a full list of the EVM features of** `creditcoin` **check the** `evm --help` **command.** # Advanced [Substrate & EVM accounts](/wallets/advanced/substrate-and-evm-accounts) [Proxy Accounts](/wallets/advanced/proxy-accounts) # Substrate & EVM accounts Creditcoin is both a Substrate-based and a fully EVM compatible blockchain. To achieve this it uses a dual-account system to keep the native Substrate interactions untouched while providing the Ethereum-like experience many web3 users are familiar with. {% hint style="info" %} If you want to know more about Creditcoin new EVM and smart contracts check the [EVM Compatibility section](/evm-compatibility) . {% endhint %} Each type of account is meant to interact with different parts of Creditcoin. Substrate accounts are required to participate in the Nominated Proof-of-Stake consensus system, bond CTC and earn rewards by either contributing to block production or nominating validators. Meanwhile, only EVM accounts can interact with smart contracts and user defined tokens. ### Accounts Accounts represent entities that interact with the Creditcoin blockchain. They can be owned by a single user or shared by teams and organizations, and anyone can own multiple accounts. Accounts have several components: * **Mnemonic seed phrase:** these are human-readable phrases that must be kept secret and can be used to generate one or several private keys. The process of generating a private key from a seed phrase is called Derivation. For basic users, having one seed phrase per private key is recommended to make backup and safekeeping of the account easier. * **Address:** the public part of the account; anyone with an address can send funds to it or check its status (balance, staked funds, validator activity and more). Substrate and EVM accounts have different address formats. * **Associated accounts:** these are keyless accounts that cannot be directly controlled, but play a key role in allowing interactions between Creditcoin and its integrated EVM. Associated accounts can receive and store funds on the main account's behalf. Depending on the type of the main account (Substrate or EVM), associated accounts behave differently. ### Substrate Accounts On the Substrate side, accounts generate SS58 addresses. This is a simple address format designed for Substrate based chains. All Creditcoin SS58 addresses are prefixed with `5` and are 48 characters long. These accounts can be managed by Substrate wallets such as Subwallet, Polkadot-JS Extension, Subkey and the Creditcoin CLI. #### Associated account behavior All user controlled substrate accounts have an associated EVM account with the only purpose of receiving CTC from other EVM accounts and storing it. The Substrate account will not be able to use the funds stored by the associated account until it executes a `Withdraw` extrinsic. {% hint style="warning" %} The secrets below are publicly known. Do not use them to store mainnet CTC as it might result in getting your funds stolen. {% endhint %} | **Substrate Account Example** | | | ----------------------------- | --------------------------------------------------------------------------- | | Mnemonic seed phrase | `cave illegal cost badge memory weird beauty hire insect soda surface deal` | | Private key | `0xaa7e880dff1594181301631b6fdb8c0078a6e2f5b8e95596bf87c05a524f364c` | | Address | `5G1qRyfXBeroVHGQx37gh6xGbMWXWFPESAFmUhLKxmU6J9nW` | | Associated EVM account | `0xAeC0b1E7DccaC53a866aB55253aCb156b787878F` | ### EVM Accounts EVM accounts are different, they use H160 addresses, which are commonly used by all Ethereum-like blockchains. These start with `0x` and are 42 characters long. EVM accounts can only be managed by EVM compatible wallets such as Subwallet, Metamask and, with limited functionality, Creditcoin CLI. #### Associated account behavior All EVM accounts have an associated Substrate account. These work differently than their Substrate counterparts: all funds sent to the associated account will be available for use inside the EVM instantly; there is no need to withdraw. | **EVM Account Example** | | | ---------------------------- | ----------------------------------------------------------------------------- | | Mnemonic seed phrase | `mesh brother dry nothing flame switch cost emotion tone unveil route moment` | | Private key | `0xc7a32f037d34114c1028aa8661ef7302d3b2acd83fcbc3654da08a50b1271497` | | Address | `0x350532caba9478983e37f2f83744293bb1a3c9d1` | | Associated Substrate account | `5CJx1pHZEuTBMiRw2n5t3N2gAYrt3aKh976K3upN4qtcAQmh` | ### Transferring from Substrate to EVM Funding an EVM account means funding its associated Substrate account. 1. Get the Substrate address associated with the EVM main account using `creditcoin` CLI. 2. Send CTC from a Substrate account to the Substrate address generated from the EVM account (Substrate → Substrate transfer). 3. Funds should automatically be reflected on EVM wallets such as Metamask. As an alternative, you can use [Polkadot-JS](https://polkadot.js.org/apps/) UI to call `balances.transferKeepAlive` (recommended) or `balances.transferAllowDeath` directly to the EVM address by selecting `Account20` (enter the address in lowercase as Polkadot.js UI does *not* allow uppercase characters in EVM address input fields).

Funding an EVM account using Polkadot-JS UI

### Transferring from EVM to Substrate - Using Polkadot-JS UI 1. Get the EVM address for the owned Substrate account using `creditcoin` CLI or [Subscan address conversion tool](https://creditcoin3-testnet.subscan.io/tools/format_transform). 2. Use any EVM wallet to send funds from the EVM account to the EVM address associated to the Substrate account we want to send CTC to (EVM → EVM transfer). 3. The funds will be available in the associated EVM account, but not usable by the Substrate side. To make them available once again we must unlock them by calling the `evm.withdraw` extrinsic with the correct associated EVM address and the amount that we want to withdraw. `creditcoin` CLI and Polkadot-JS UI can be used to perform the withdraw. 1. Using `creditcoin`CLI you can type the following command : `creditcoin evm withdraw` 2. Using Polkadot-JS UI to call `evm.withdraw`
4. After calling `withdraw` funds should be available once again on the Substrate
### **Transferring from EVM to Substrate - Using a Precompile (Smart Contract)** The following commands require Node.js to be installed. {% hint style="info" %} Note: The script is configured to call testnet RPC. To test with mainnet instead of testnet, replace the rpc url with ``` wss://mainnet3.creditcoin.network ``` {% endhint %} 1. Create 'package.json' file with default values: \ `npm init -y` 2. Open the folder with any text editor(e.g., VM/Nano) or any IDE and add the following line to package.json `"type": "module"` 3. Install dependencies `npm i ethers@5.7.2` 4. Create a new file named 'index.js' and paste the following content {% code lineNumbers="true" %} ``` import * as ethers from 'ethers' async function go() { // Initialize variables const pk = "private key goes here, including the starting 0x"; const abi = [ { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "from", "type": "address" }, { "indexed": true, "internalType": "bytes32", "name": "destination", "type": "bytes32" }, { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "Transfer", "type": "event" }, { "inputs": [ { "internalType": "bytes32", "name": "destination", "type": "bytes32" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "transfer_substrate", "outputs": [], "stateMutability": "nonpayable", "type": "function" } ]; const provider = new ethers.providers.JsonRpcProvider("https://rpc.cc3-testnet.creditcoin.network"); // Create a wallet instance const wallet = new ethers.Wallet(pk, provider); // Set the contract address const contractAddress = "0x0000000000000000000000000000000000000fd1"; const contract = new ethers.Contract(contractAddress, abi, wallet); // Define the function to call const functionName = "transfer_substrate"; // Convert the public key of the destination address from hex string to bytes const hexToBytes = ethers.utils.arrayify("public key goes here, starting with 0x"); // Transfer amount in wei const transferAmount = ethers.utils.parseEther('10'); // Create the transaction data const txnInput = contract.interface.encodeFunctionData(functionName, [hexToBytes, transferAmount]); // Define gas fees const gasPrice = ethers.utils.parseUnits('6', 'gwei'); const maxPriorityFeePerGas = ethers.utils.parseUnits('2', 'gwei'); const gasLimit = 80000; // Create the transaction object const txObject = { to: contractAddress, data: txnInput, gasLimit: gasLimit, maxPriorityFeePerGas: maxPriorityFeePerGas, maxFeePerGas: gasPrice }; // Sign and send the transaction const response = await wallet.sendTransaction(txObject); console.log("Transaction Response:", response); // Wait for the transaction to be mined const receipt = await response.wait(); console.log("Transaction Receipt:", receipt); } go().catch(console.error); ``` {% endcode %} 4.1 Enter the EVM private key of the wallet from which you want the funds to be sent from at line 5 5. Obtain the hex format of the Substrate public address destination: \ 5.1 Go to \ 5.2 Paste your substrate address in the “Input Account” field\ 5.3 Set Output Type to Public Key\ 5.4 Enter the Public Key in line 20 in 'index.js' file 6. Run the Script \ `node index.js` #### After running the scripts, to check the transaction details * Go to Blockscout * For Testnet, use: [https://creditcoin-testnet.blockscout.com](https://creditcoin-testnet.blockscout.com/) * For Mainnet, use: [https://creditcoin.blockscout.com](https://creditcoin.blockscout.com/) * Copy the TransactionHash from the output and paste it in the Blockscout * Click "View details" on the Transaction details page to check the destination and amount
or
* Go to Logs tab * Convert the Hex value to Address in the dropdown to verify the source and destination addresses
#### To check the updated balance, you need to verify the substrate address on Subscan or polkadot ### **Transferring from EVM to Substrate - Using Credit Wallet** Please refer to the Credit Wallet Guide Page: Section 4: Token Transactions - **Token Transfer Between Creditcoin Native (Substrate) and Creditcoin (EVM)** # Proxy Accounts An account can authorize another account to sign **extrinsic calls** made to specific **pallets** on its behalf. We call these authorized accounts Proxy Accounts. These can be created to interact with the different pallets involved in staking such as `staking`, `session` and `utility` pallets. Proxies serve as efficient delegates and enhance security by allowing tasks to be completed through smaller, specialized accounts rather than a main account. This minimizes the need for frequent transactions in the main account, adding a layer of security. Proxies can be more active while the main account remains less active ("cold"), utilizing the cold account's token weight. **Proxy types** Proxy accounts can be set up to have a defined set of permissions. For example, staking proxies have permission to do only staking-related transactions. When you set a proxy, you must choose a type: * **Any**: allow any transaction, including balance transfers. In most cases, this should be avoided as the proxy account is used more frequently than the cold account and is therefore less secure. * **Non-transfer**: allow any type of transaction except balance transfers. Hence, this proxy does not have permission to access calls in the Balances and XCM pallet. * **Staking**: allow all staking-related transactions. The stash account is meant to stay in cold storage, while the staking proxy account makes day-to-day transactions like setting session keys or deciding which validators to nominate. **Proxy account tools** * [Creditcoin CLI](/wallets/how-to-connect-your-wallet-to-creditcoin/command-line-interface/creditcoin-cli): the CLI bundled in the Creditcoin Docker image allows setting staking proxies for managing Nominators and Validators. # Setting up a Staking Proxy Account ### Creditcoin CLI `creditcoin` comes bundled with the Creditcoin Docker image and provides the required tools to add, remove and manage Proxy Accounts through its `proxy` subcommand. ``` Usage: cli proxy [options] [command] Commands for managing the proxy system Options: -h, --help display help for command Commands: add [options] Add a new proxy list [options] View a list of proxies and their types remove [options] Remove all instances of a proxy help [command] display help for command ``` **Adding proxies** To add a proxy account that can sign extrinsics on behalf of the main account, run the `proxy add` command with the `--proxy` option with the address of the account you wish to add and specify the permissions this account will have with the `--type flag`. Type can be either `All`, `Staking` or `NonTransfer`. ``` $ creditcoin proxy add --proxy "" --type Staking ``` **Listing proxies** After adding an account as a proxy, running the `proxy list` command should return the recently added proxy and any others that have been added in the past. ``` $ creditcoin proxy list ``` **Removing proxies** Proxies can be removed in a similar way using the `proxy remove` command. ``` $ creditcoin proxy remove --proxy "" ``` # Setting up a Validator Once a Proxy Account has been set up, it can be used to set up a validator by following the same steps as with a Stash Account. ### CLI Instructions To run a validator node, use the Creditcoin Docker image provided at `gluwa/creditcoin3` and follow the instructions in the [Validator Setup Guide](/wallets/advanced/proxy-accounts/setting-up-a-validator). The minimum amount to stake for a validator is 20 000 CTC. #### Using the Validator Wizard Run the Validator Wizard with the desired CTC amount to bond and the stash address as the proxied account: ``` $ docker exec -it creditcoin-validator creditcoin wizard --proxy-for "" --amount ``` It will show the current staking settings, make sure to check them before continuing. ``` 🧙 Running staking wizard... Using the following parameters: 💰 Stash account: 5CUnLxUCFqtGkre7MZwyX66E3kPMKDXra4FYtiYp5SoDUwKM 🪙 Amount to bond: 20000 CTC 🎁 Reward destination: Staked 📡 Node URL: ws://127.0.0.1:9944 💸 Commission: 0 🔐 Blocked: No Continue? (y/n): y ``` If your account is already bonded, skip the bonding step by running `wizard` without the amount flag. After continuing, the Wizard will create all required extrinsics (i.e. transactions) and communicate with the node to pair it with the stash account. Once the transactions are sent, the new validator should be in the waiting queue. Use the status command to get information about the status of a particular validator by entering its Stash address. #### Manual Setup Setting a validator can also be done by sending each required command manually. First bond CTC using your Stash account and enter the CTC amount to stake. ``` $ docker exec -it creditcoin-validator creditcoin bond --amount --proxy-for ``` Set the validator node keys. The `--rotate` flag specifies that the node will generate new keys. Existing keys can be used with the `--keys ` option. ``` $ docker exec -it creditcoin-validator creditcoin set-keys --rotate --proxy-for ``` Once keys are set up, the last step is signaling the network the intention to validate. Use the `--commission ` option to set up a portion of the block reward that will not be shared with nominators or the `--blocked` flag to block nominations. ``` $ docker exec -it creditcoin-validator creditcoin validate --commission --proxy-for ``` #### Stopping a Validator Stop a running validator with the `chill` command. This will remove the validator from the active/waiting set in the next session. ``` $ docker exec -it creditcoin-validator creditcoin chill --proxy-for ``` #### Unbonding & withdrawing CTC To unbond locked CTC, validators must first mark their tokens for unbonding, then wait for the unlocking period to end and finally withdraw the unbonded funds. ``` $ docker exec -it creditcoin-validator creditcoin unbond --amount --proxy-for ``` The status command shows when the next unlocking chunk will be available to withdraw. ``` $ docker exec -it creditcoin-validator creditcoin status --substrate-address ``` ``` Validator 5CGBosx2Fw34u9jJtSgEQkoNTtHkPLKgsfjJiE3mDSWb44MW: ┌────────────────┬─────────────────────────────────┐ │ Status │ │ ├────────────────┼─────────────────────────────────┤ │ Bonded │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Validating │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Waiting │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Active │ No │ ├────────────────┼─────────────────────────────────┤ │ Can withdraw │ No │ ├────────────────┼─────────────────────────────────┤ │ Next unlocking │1000 CTC in 6 minutes, 5 seconds │ └────────────────┴─────────────────────────────────┘ ``` After the unbonding period has passed, withdraw the funds. ``` $ docker exec -it creditcoin-validator creditcoin withdraw-unbonded --proxy-for ``` # Precompiled Smart Contracts Precompiles are built-in Ethereum functions designed to handle heavy cryptographic tasks more efficiently than standard smart contracts. By residing at predefined addresses, these native implementations reduce gas costs and execution time for operations that are normally too computationally intensive for the runtime environment to process. Below is the list of precompiled smart contracts supported by Creditcoin3:
PrecompileAddressDescriptionSupported on
ECRecover0x0000000000000000000000000000000000000001Recovers the public key associated with a signatureMainnet + Testnet
Sha2560x0000000000000000000000000000000000000002Implements the SHA-256 hash functionMainnet + Testnet
Ripemd1600x0000000000000000000000000000000000000003Implements the RIPEMD-160 hash functionMainnet + Testnet
Identity0x0000000000000000000000000000000000000004Data copy function (returns input as output)Mainnet + Testnet
Modexp0x0000000000000000000000000000000000000005Modular exponentiationMainnet + Testnet
Bn128Add0x0000000000000000000000000000000000000006Addition on the alt_bn128 curveMainnet + Testnet
Bn128Mul0x0000000000000000000000000000000000000007Multiplication on the alt_bn128 curveMainnet + Testnet
Bn128Pairing0x0000000000000000000000000000000000000008Pairing check on the alt_bn128 curveMainnet + Testnet
Sha3FIPS2560x0000000000000000000000000000000000000400Implements the SHA3-256 standard as specified in FIPS202Mainnet + Testnet

ECRecoverPublicKey

0x0000000000000000000000000000000000000401Similar to ECRecover, but returns the pubkey (not the corresponding Ethereum address)Mainnet + Testnet
SubstrateTransfer0x0000000000000000000000000000000000000Fd1Precompile exposing a pallet_balance as an ERC20.Mainnet + Testnet
Sr25519Verifier0x00000000000000000000000000000000000013B9Precompile for verifying Substrate sr25519 signatures.Mainnet + Testnet
Ed25519Verifier0x00000000000000000000000000000000000013BAPrecompile for verifying ed25519 signatures.Mainnet + Testnet
# Using Testnet Faucet Creditcoin provides a faucet tool to allow users to conveniently obtain CTC Substrate or CTC EVM tokens so they can participate in testing and development on the **Creditcoin testnet**. #### How to obtain CTC Substrate tokens 1. Make sure you are a member of [Creditcoin Discord server](https://discord.gg/creditcoin). 2. Navigate to the designated channel labeled: 'token-faucet' 3. Initiate the faucet request by using the specified command and providing a valid Substrate address. ``` /faucet address:yourValidSubstrateAddressGoesHere ``` 4. Upon submission, the bot will promptly acknowledge the request with a confirmation message stating "CTC faucet submitted”.
5. Continue waiting until the bot confirms again in the same thread that "CTC Faucet successful".
At this point, you should be able to see the CTC tokens in your account's balance. Additionally, you can view the block and the Extrinsic corresponding to your faucet request in the thread created by the bot. #### How to obtain CTC EVM tokens 1. Make sure you are a member of [Creditcoin Discord server](https://discord.gg/creditcoin). 2. Navigate to the designated channel (same as the Substrate Token Channel) labeled: 'token-faucet' 3. Initiate the faucet request by using the specified command and providing a valid EVM address. ``` /faucet address:yourValidEVMAddressGoesHere ``` 4. Upon submission, the bot will promptly acknowledge the request with a confirmation message stating "CTC faucet submitted”.
5. Continue waiting until the bot confirms again in the same thread that "CTC Faucet successful".
At this point, you should be able to see the CTC tokens in your account's balance. Additionally, you can view the block and the Extrinsic corresponding to your faucet request in the thread created by the bot. # Ledger - Hardware Wallet With the release of `3.52.0-mainnet` Creditcoin now officially supports **Ledger devices**. This guide provides step-by-step instructions for setting up your Ledger and using it across multiple wallets. Please note that the **prerequisites are common across all supported wallets**, so it is recommended to review them first before proceeding to the wallet specific setup. Please note that this is in addition to Ledger support for EVM based wallets (Metamask, Talisman, Subwallet). Specifically with this release, we are extending support to the Substrate ecosystem on the following wallets : * [Polkadot.js.org Substrate Portal](/wallets/ledger-hardware-wallet/polkadot.js.org-substrate-portal) * [Talisman Wallet](/wallets/ledger-hardware-wallet/talisman-wallet) * [SubWallet](/wallets/ledger-hardware-wallet/subwallet) ### Prerequisites * **Install the latest version of** [**Ledger Live (Desktop)**](https://www.ledger.com/ledger-live) **or update it**. * **Firmware** and **apps** updated in Ledger Live → *My Ledger*: * Install the **Polkadot** app for Substrate chains.
* Install the **Ethereum** app for EVM. * Use the **factory Ledger USB** or a **USB-C↔USB-C data cable**. * Use **Chrome/Edge** (newest stable). * Close **all other dapps/tabs** that might talk to Ledger. #### Configure Polkadot.js Apps (Substrate Portal 1. Go to **⚙️ Settings** (top bar) 2. **Metadata -> extensions -> Select all of your upgradeable extensions and update the metadata**
3. **Manage Hardware Connections -> Choose: Attach Ledger via** **WebHID** (try WebUSB only if WebHID fails).
4. **Manage Ledger app:** * Use Ledger Polkadot Generic App
5. **Click on Save** > The portal will show a banner if you’re using the Generic app:\ > “You are using the Ledger GENERIC App. If you would like to switch it, please go to the ‘manage ledger app’ in the settings.” # Polkadot.js.org Substrate Portal After successfully completing the prerequisite setup phase, you can start using Polkadot.js.org Substrate Portal through Ledger ### Connect & Import 1. **Quit Ledger Live**. 2. **Plug Ledger** → **Unlock** → **Open the Polkadot app** 3. Navigate to the Polkadot.js In **Accounts** → click **From Ledger** (or **Import via Ledger**).
4. Upon clicking the **From Ledger** button, you will see the following screen In the modal, set: * **Account type** (top-level derivation; usually **0**) * **Address index** (child index; usually **0**) * **Name** your account → **Save**.
5. Upon clicking the **Save** button, the Device Selector will appear. Select your Ledger device and press **the Connect button.**
6. Allow the connection on your Ledger Device. > **Notes on derivation:** > > * Ledger on Substrate = **ed25519** keys. > * **Account type** groups (0..N). **The address index** enumerates addresses within that group. > * The **address string changes by network** (SS58 format), but the underlying public key is the same. ### How to Transfer on Creditcoin network 1. **Unlock Ledger** → open the **Polkadot** app 2. In the portal, go to **Accounts → My accounts** → click the **paper-plane “Send”** icon next to your Ledger account
3. **From:** your Ledger account → **To:** paste/choose recipient. 4. **Amount:** enter value.
5. Click **Make Transfer** → **Sign and Submit** → review on the Ledger → **Approve**. 6. Track status in the UI or your block explorer.
The transfer has now been successfully completed. # Talisman Wallet ### Prerequisite to use Ledger on Substrate with Talisman on Creditcoin 1. Complete prerequisites step in our guide [here](/wallets/ledger-hardware-wallet) 2. Check the box "This Network Support CheckMetadataHash sign extension" on Talisman 1. Go to Settings → Network & Tokens 2. Check the box to indicate that Creditcoin support checking medatata hash sign extension
### How to Connect Ledger 1. Open **Talisman** → **Add account**
2. Navigate to the **Connect** tab 3. Select **Connect Ledger**
4. Select Network **-> Polkadot**
5. Choose Ledger app → **Polkadot App**
6. Ensure the Ledger device is unlocked 7. Choose accounts and continue
8. Account connected → navigate to **Settings** → **General** tab -L Click on **Check** button and select **HID** or **USB**
### How to send funds via Talisman wallet chrome extension 1. **Unlock Ledger** → open the **Polkadot app** 2. Open **Talisman** → select your Ledger account → **Send**. 3. Pick **Network / Asset** (CTC native token).
4. Enter **Recipient** and **Amount** → (optional) **Keep-alive** toggle.
5. **Next** → **Sign with Ledger** → confirm on device → **Approve**. 6. Monitor in **Activity** or Explorer.
### How to Connect Talisman Wallet to PolkadotJS App Console 1. Open the extension and select **Not connected**
2. Select accounts to connect
3. Verify account connected
> If you have already connected Account index 0 directly in the polkadotJs app using the **From Ledger** button, and if you connect the same account from Talisman to the polkadotJs App console, it will override your hardware connection. You can have only 1 account at a particular index connected at a time using wallets or a direct hardware connection ### How to Transfer via PolkadotJS App Console 1. Open PolkadotJS App → click on the **Send button** next to the account (Ensure that the Polkadot app is opened in the Ledger device) 2. Enter the amount → Select the recipient → Click on Make Transfer
3\. Click on Sign and Submit
4. Sign via extension → Approve on the Ledger Device
5. Track the progress on your UI and block explorer
The transfer has now been successfully completed. # SubWallet After successfully completing the prerequisite setup phase, you can start using the SubWallet through Ledger ### How to connect Subwallet to Ledger **Open SubWallet → Add account** 1. Click **All accounts** on top
2. Click **Attach Account** and then **Connect a Ledger device**
3. In a new tab, select **Connect Ledger device**
4. **On Ledger:** ensure the device is **unlocked** and open the **Polkadot app.** * Choose the **account(s)** (Account type / Address index) → **Continue** → **Name** → **Add**. * You should see: Account connected. > If the Chrome device chooser doesn’t appear: ensure pop-ups allowed, click the tiny USB icon in the address bar to grant access, or reset site permissions for the page. 5. SubWallet – Add Creditcoin (Substrate) to wallet * Click on the sliders button in the **Subwallet** extension in the top left **→ Manage networks** * Search for **Creditcoin Native** and toggle it
### How to send funds via 1. **Unlock Ledger** → open the **Polkadot app** 2. In **SubWallet**, select your **Ledger account** → **Click on your desired Creditcoin account**
3. Pick **Network/Asset** (e.g., **CTC** native token on Creditcoin). 4. **Recipient**: paste/select → **Amount**: enter value, and **Transfer**.
5. **Next** → **Sign with Ledger** → confirm on device → **Approve**
6. Monitor in **Activity** or your explorer and verify the new balance
### How to Connect SubWallet to Polkadot.js 1. Open the **SubWallet** extension → the site badge should show **Not connected**.
2. Click the badge → **Connect** → select which **accounts** to expose to the site → **Allow**. > Keep in mind that we need to **disconnect Talisman** in order to work with **Subwallet, the same wallets** or you can **use an account at another index** from Subwallet 3. Verify the account appears under **Accounts → My accounts** in the Polkadot.js Apps UI.
### How to transfer funds via Polkadot.js Apps Console 1. Open **Polkadot.js Apps** → **Accounts** → click **Send** next to the SubWallet-exposed Ledger account. 2. Ensure the **correct app** is open on your Ledger (**Polkadot** or **Generic**). 3. Enter **Amount** and **Recipient** → **Make Transfer**
4. **Sign and Submit**.
5. **Approve** the transaction in your wallet → **Approve on Ledger**.
6. Verify inclusion/finality in the portal or explorer and confirm the balance change.
# Staking #### Proof-of-Stake (PoS) Distributed ledger technologies use consensus mechanisms to agree on the validity of transactions and maintain a consistent and immutable record of the chain. In decentralized blockchains, this typically involves using various consensus algorithms, such as proof-of-work or proof-of-stake, to ensure agreement and prevent double-spending or malicious activity. Consensus consists of two stages: Block production: how new blocks are created; Block finality: how one of the many block candidates is selected and added to the canonical chain. Proof of Stake (PoS) is a consensus algorithm used in blockchain networks where validators are chosen to create new blocks based on their ownership or "stake" in the cryptocurrency. Validators are incentivized to behave honestly as they risk losing their stake if they attempt to validate fraudulent transactions, ensuring the security and integrity of the network. #### **Differences with Proof-of-Work (PoW)** While PoW requires computational work and miners to compete against each other, which consumes significant computational resources and wasted energy, PoS relies on validators' ownership or stake in the cryptocurrency to create new blocks and secure the network. Whilst PoW requires significant upfront investment in specialized hardware and energy costs, disincentivizing potential attackers, PoS mechanisms similarly require validators to “have skin in the game” in the form of staked cryptocurrency. All validators are required to lock up a certain amount of their own cryptocurrency as collateral to participate in the consensus process. This collateral, known as a “stake”, serves as a form of guarantee, as validators risk losing their stake if they act dishonestly or validate fraudulent transactions. This economic incentive encourages validators to behave honestly and maintain the security and integrity of the network, as they have something tangible to lose. #### Nominated Proof-of-Stake Creditcoin's Nominated Proof of Stake (NPoS) is a variation of the Proof of Stake (PoS) consensus algorithm. NPoS introduces a nominator-validator model where nominators can select and back validators. Nominators delegate their stake to validators, and in return, they can receive a portion of the validator's rewards. This system allows token holders, who may not have enough stake or technical expertise to become a validator, to nonetheless participate in the network and earn rewards by supporting trusted validators instead. Thereby, it promotes a more inclusive and secure network, as the nomination process enables a broader set of token holders to participate in consensus and governance than under a traditional PoS model. #### Validators Validators participate in consensus by creating new blocks and finalizing previous ones. To be part of the active set, validator candidates must have sufficient stake behind them to make it into the top 100 backed validators. Additionally, validators must have at least 1000 CTC backing them. This stake can be provided by a validator themselves, or from third-parties who support them, which we call nominators. All elected validators have equal block production rights, regardless of the amount of stake supporting them. This helps to ensure decentralization and security by preventing the concentration of staking power into a small group of validators. #### Nominators Nominators can participate in NPoS consensus, without running their own nodes, by backing validators with their own stake, sharing both rewards and slashing (burning of stake for dishonest behavior) with any elected validators they have backed. # Bonded Tokens When staking, CTC must be bonded in a Stash account. This is a process by which tokens are "frozen" in exchange for some other benefit. In the Creditcoin network, users can bond their tokens in exchange for the right to participate in consensus and receive rewards. To transfer bonded CTC, tokens must go through an unbonding period, during which they cannot be used to nominate validators and do not contribute to earning any rewards. Creditcoin’s unbonding period is 7 days. This is a security measure designed to align security and economic incentives for both validators and nominators, ensuring that those who participate in consensus have “skin in the game” as they cannot exit their positions right away. # Validator Elections The validator election process that Creditcoin implements involves three distinct steps: nomination, winner selection, and stake distribution. ### **Nomination** In the first step, validators mark themselves as candidates, after which nominators can decide to support them with their stake. ### **Winner selection** Winning validators are selected by aggregating the total staked CTC that is supporting them (a nominator voting for 2 validators with 10 CTC gives 10 votes to each). The top 100 validators with the highest number of CTC backing them are elected and become part of the active set for the upcoming era. ### **Stake Distribution** While the staked CTC is counted multiple times to decide winners, it is then distributed between elected validators once the era begins. While there is no “right” way to distribute these tokens, Creditcoin uses a process called Phragmén to optimize for three things: * Maximize total amount at stake * Maximize stake behind the minimally staked validator * Minimize the variance of stake among validators By optimizing for these three things, Creditcoin’s NPoS system aims to ensure that validator rewards are as fairly distributed, based on staked CTC, as possible, given the non-linear stake to reward ratio. ### Block Production Slot Distribution Once the network decides on the active validator set, it decides who can produce blocks and when. Two different mechanisms are used to distribute block production slots: BABE and Aura. **BABE** BABE (Blind Assignment for Blockchain Extension) is the block production mechanism that runs between the validator nodes and determines the authors of new blocks. BABE assigns block production slots to validators according to stake and using a Verifiable Random Function. Slots are discrete units of time, approximately 15 seconds in length in Creditcoin. Validators participate in a lottery for every slot, which will inform whether or not they are the block producer candidate for that slot. Due to the specifics of the lottery, multiple or no validators can be selected for a slot, resulting in either a race condition or an empty slot (inconsistent block time). **Aura** Aura is a deterministic and much simpler process to distribute slots. Aura’s election mechanism is not private so it is not secure against an adaptive adversary. It can be targeted by DDOS attacks because validators for specific slots are known. Creditcoin uses Aura to fill empty slots generated by BABE. # Elections Example The validator election process is an iterative process. This examples covers a full election where 5 validators compete for 3 slots in the active set while 5 nominators vote for them. Consider the following initial setup: | **Nominator** | **Stake** | **Nominations** | | ------------- | --------- | ------------------- | | One | 100 CTC | Alice & Bob | | Two | 200 CTC | Alice & Bob | | Three | 300 CTC | Alice | | Four | 400 CTC | Bob, Charlie & Dave | | Five | 500 CTC | Alice & Dave | | **Validator** | **Nominations (count)** | | ------------- | ----------------------- | | Alice | 4 | | Bob | 3 | | Charlie | 1 | | Dave | 2 | | Eve | 0 | 1. First, we must calculate the approval stake of each validator; this is the total support for them by all nominators. | **Validator** | **Total** | **Detail** | | ------------- | --------- | --------------------- | | Alice | 1100 CTC | 100 + 200 + 300 + 500 | | Bob | 700 CTC | 100 + 200 + 400 | | Charlie | 400 CTC | 400 | | Dave | 900 CTC | 400 + 500 | | Eve | 0 CTC | 0 | 2. We remove any validators which do not have any support from nominators. Eve will never be elected, so we remove it from the set. 3. After this, we can calculate the initial scores for each candidate. In each round, the validator with the lowest score gets assigned a slot. This is calculated by the formula `1 / stake` | **Validator** | **Stake** | **Score** | | ------------- | --------- | ------------------ | | Alice | 1100 CTC | 1 / 1100 = 0.00091 | | Bob | 700 CTC | 1 / 700 = 0.00143 | | Charlie | 400 CTC | 1 / 400 = 0.0025 | | Dave | 900 CTC | 1 / 900 = 0.0011 | 4. The candidate with the lowest score is Alice. It has its slot reserved. After the first round, the weights of each nominator votes get updated to Alice being already elected. This makes the votes of those who picked Alice stronger. The formula is the following: ``` candidate_score = candidate_score + ((voter_budget * voter_load) / candidate_approval_stake) ``` 5. After updating the weights, we recalculate the scores for each validator: | **Validator** | **Score** | | ------------- | --------- | | Bob | 0.00182 | | Charlie | 0.0025 | | Dave | 0.00162 | 6. Validator Dave gets the next available slot and we update the nominator weights and validator scores again. | **Validator** | **Score** | | ------------- | --------- | | Bob | 0.00143 | | Charlie | 0.0025 | 7. We end up with Bob taking the last slot. All 3 slots are filled and we have the election result # Eras and Sessions In Creditcoin's Nominated Proof-of-Stake blockchain, time is organized using three distinct units: blocks, epochs, and eras. Validator elections are run at the end of each **era**. An era is a period of **24 hours** during which an **active set** of validators is producing blocks and performing other actions on the chain. Not all validators are in the active set and such set changes between eras. Each era is divided into two **12 hour epochs**, during which validators are assigned as block producers to specific time frames or **slots**. This means that validators know the slots when they will be required to produce a block within a specific epoch, but they do not know all the slots within a specific era. Having epochs adds a layer of security because it decreases the chance of having multiple validators assigned to a slot colluding to harm the network. Ideally, each slot should produce one **block** every **15 seconds**. A block is the smallest time unit in the Creditcoin blockchain. | **Unit** | **Time** | **Reward** | | -------- | ---------------------- | ---------- | | Block | 15 seconds | 2 CTC | | Epoch | 12 hours (2880 blocks) | 5760 CTC | | Era | 24 hours (2 epochs) | 11520 CTC | # Staking Rewards Validators who produce a block are rewarded with CTC tokens. Validators may then share these rewards with nominators backing them. Both validators and nominators can stake their tokens on chain and receive staking rewards at the end of each era. The staking system pays out rewards equally to all validators regardless of the total stake backing them. Thus, having more total stake backing a validator does not influence the amount of block rewards that validator receives. This helps to mitigate the risks of validator centralization. There is a probabilistic component in the distribution of rewards, so they may not be exactly equal for all validators. Additionally, each validator can earn more era points by completing various tasks on-chain. The more era points a validator accumulates, the higher their rewards will be for that era. This helps to incentivize positive validator behaviour on-chain. ### Validator Payouts Validators and nominators are rewarded at the end of each era according to their earned era points. Points are obtained by validators who produce blocks during their designated time. Blocks which end up being finalized and added to the canonical chain score 20 era points. The Creditcoin network also distributes minor rewards to validators who produce uncle blocks, which end up not being included in the canonical chain, and authors that reference previously unreferenced uncle blocks. {% hint style="info" %} An uncle block is a block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks. {% endhint %} | **Task** | **Reward** | | ------------------------- | ------------- | | Produce non-uncle block | 20 era points | | Reference new uncle block | 2 era points | | Produce uncle block | 1 era points | The Creditcoin blockchain rewards non-uncle block producers with 2 CTC per block. With block time set at 15 seconds, each Era generates and distributes 11520 CTC. #### **Splitting Rewards among Validators** Assuming all validators are honest and always online when required, block production slots for an era are distributed evenly among them, no matter their total stake. Creditcoin's implementation uses BABE block authoring to blindly assign these slots in a secure way. Ideally, they should all earn a similar amount of era points and thus a similar amount of tokens. Total stake behind each validator does not affect reward distribution. Assuming there are only 4 active validators in an era, if every validator is online when required, when the era ends each of them should get 2880 CTC (1/4 of the total era reward). * Validator #1 with 1M CTC stake: 2880 CTC reward * Validator #2 with 500.000 CTC stake: 2880 CTC reward * Validator #3 with 25.000 CTC stake: 2880 CTC reward * Validator #4 with 100 CTC stake: 2880 CTC reward #### **Splitting Rewards among Nominators** Once a validator is rewarded CTC, the newly minted tokens are distributed among all of its backers (both the nominators who voted for them, and the validator themselves). Validators can and are encouraged to stake themselves. Rewards are distributed to nominators and validators based on their relative stake amount. Validators are also able to retain a pre-defined percentage of nominator rewards as a commission fee. Example: A Validator is rewarded 4000 CTC for its contributions to block production. This validator is backed by 1000 CTC staked by four different users: * Validator's self-stake: 200 CTC * Nominator #1: 400 CTC * Nominator #2: 300 CTC * Nominator #3: 100 CTC The validator has set up a 1% commission that is calculated before distributing rewards. After the validator fee, there are 3960 CTC to be distributed among the four accounts. * Validator payout: 40 CTC (commission) + 200/1000 \* 3960 = 40 + 792 = 832 CTC * Nominator #1 payout: 400/1000 \* 3960 = 1584 CTC * Nominator #2 payout: 300/1000 \* 3960 = 1188 CTC * Nominator #3 payout: 100/1000 \* 3960 = 396 CTC ### Paying out the Rewards To support scalability in nominator rewards under Nominated Proof-of-Stake (NPoS), the reward payout system has been updated to handle rewards across multiple blocks using a paging mechanism. This allows validators to reward all their nominators in a structured and efficient way. A new extrinsic, `payout_stakers_by_page`, has been introduced to enable this behavior. The existing `payout_stakers` extrinsic continues to function as before, but it now pays out only the unpaid pages in ascending order. **Key Detail:** If a validator has more nominators than the configured `staking.maxExposurePageSize` (currently set to 512), it will be necessary to call `payout_stakers` multiple times to reward all nominators. Alternatively, `payout_stakers_by_page` can be used to target specific pages. To check the current value of `staking.maxExposurePageSize`: 1. Visit the Polkadot/Substrate Portal. 2. Navigate to **Developer > Chain State > Constants**. 3. Select `staking > maxExposurePageSize`. Each call to `staking.payoutStakers` will distribute rewards to the first `maxExposurePageSize` nominators for that validator. # Slashing In Creditcoin, slashing serves as a means to discourage malicious behavior by imposing penalties on validators who act against the network's interests. Validators who partake in harmful activities may face a reduction in their staked tokens through slashing. This mechanism plays a vital role in upholding the network's security and integrity by incentivizing validators to prioritize the network's well-being. In the event of a slash, any nominators who were backing the slashed validator will also have their stake slashed. This creates a reputational incentive for validators to maintain good behaviour, which is required to attract nominator stake, and simultaneously, incentives nominators to thoroughly evaluate any validators before backing them, resulting in increased overall network security. Regardless of whether you nominate validators directly or through a nomination pool, your stake is susceptible to slashing. **Types of Offences** There are three types of offences in the Creditcoin network which can lead to a validator getting slashed: * Inactivity: being offline during a designated time slot * Block production: producing more than one block in a designated time slot * Block finalization: finalizing blocks on two different versions of the chain (forks) in the same time slot Each offence has its own penalty calculation. Inactivity goes from a minor warning that chills the validator (removes it from the active set) up to up to slashing 7% of a validator’s total backing stake if several validators go offline during a single era.
Validators who commit production or finalization offences get between 0% and 100% of their stake slashed depending on how many offences of the same type where recorded in that particular era.
**Slashing calculations** | **Offence** | **Formula** | **Range** | | -------------------------- | ---------------------------------------------------------------------------------------------- | --------------- | | Inactivity | `min((3 * (offending_validators - (total_validators / 10 + 1))) / total_validators, 1) * 0.07` | 0% (chill) - 7% | | Block production offence | `(3 * offender_count) / total_validator_count) ^ 2` | 0% - 100% | | Block finalization offence | `(3 * offender_count) / total_validator_count) ^ 2` | 0% - 100% | # Nominator Guides Nominators are individuals who participate in the staking process by staking CTC (the native utility token of Creditcoin) and selecting validators to support. By participating in the staking process, nominators contribute to the security and operation of the network. Nominators also earn a share of CTC staking rewards, based on the validator(s) they choose nominate. Nominators can select validators based on various factors such as recent payout history, total stake, commission rates, and the validator's own stake. To incentivise good behaviour, nominators are at risk of losing staked CTC through ‘slashing’ if their nominated validators misbehave. To avoid the risk of losing staked funds through slashing, it is important for nominators to carefully choose validators that adhere to network rules and behave honestly. {% hint style="info" %} Refer to the [Staking Rewards](/staking/staking-rewards) and [Slashing](/staking/slashing) sections to know more about how nominators are compensated for staking and the associated risks. {% endhint %} Depending on the amount of CTC available for staking, investors can choose between two staking methods: * **Nominating Without Staking Pools:** for investors with at least 19,500 CTC willing to actively participate in [selecting validators](/nominator-guides/nominating-without-staking-pools). * **Joining a Staking Pool:** with no minimum stake requirement, investors can delegate their voting power to a pool operator and earn rewards in return. ### Guides * [Nominate Without Staking Pools](/nominator-guides/nominating-without-staking-pools) * [Nominate With Staking Pools](/nominator-guides/nominating-with-staking-pools) * [Claiming rewards](/nominator-guides/claiming-rewards) # Nominating with Staking Pools Creditcoin provides users the option to create and join nomination pools. Nomination pools are a good alternative for smaller users who do not meet the minimum staking requirements for solo nominating. By joining nomination pools, users can pool their CTC stake together and act as a single nominator to meet the minimum staking requirements to earn rewards. #### Staking pool benefits: * No minimum stake requirement; start earning rewards with just 1 CTC * Pool members do not need to actively manage nominations, which is the responsibility of the pool operator. {% hint style="warning" %} Staking pools share the same risks as Nominators when nominating validators. If any of the pool’s nominated validators misbehave, users may lose their funds due to slashing. Even if offences do not trigger slashing, they might still cause the validator to be chilled, meaning that any backing nominators will stop earning rewards, or have their rewards reduced due to validator chilling. See the [Validator Selection](/nominator-guides/nominating-without-staking-pools) section for more information. {% endhint %} ### Pool members By joining a nomination pool, members delegate control (but not custody) of their stake and nominations to the pool operator. While more convenient, it is still important for members to carefully choose which pools they join. For more information on how you should choose a nomination pool, go to the [Choosing a Pool guide](/nominator-guides/nominating-with-staking-pools/choosing-a-pool). In exchange they get a portion of the [staking rewards](/staking/staking-rewards) that correspond to their locked CTC minus any fee the pool operator decides to charge. ### Pool operators Pool operators are the accounts that created and manage a nomination pool. They are in charge of nominating honest validators and are able to change the pool’s settings; including commissions, nominations, and opening or closing the pool to new members. For more information on how to create or manage a nomination pool, go to the[ Creating a Pool](/nominator-guides/nominating-with-staking-pools/creating-a-pool) guide. #### Start using Nomination Pools * [Choosing a Pool](/nominator-guides/nominating-with-staking-pools/choosing-a-pool) * [Joining a Pool](/nominator-guides/nominating-with-staking-pools/joining-a-pool) * [Creating a Pool](/nominator-guides/nominating-with-staking-pools/creating-a-pool) * [Exiting a Pool](/nominator-guides/nominating-with-staking-pools/exiting-a-pool) * [Managing a Pool](/nominator-guides/nominating-with-staking-pools/managing-a-pool) # Choosing a Pool Pool operators are responsible for managing staking pool nominations. If they make mistakes or mismanage the pool, then pool members may lose their staked funds or receive reduced CTC rewards. This is because staking penalties still apply, regardless of whether users stake through nomination pools or not. Therefore, similar to how nominators must carefully select the validators they vote for, pool users should carefully decide which pools they want join. {% hint style="success" %} While nomination pools control how members' bonded funds are staked, these funds still remain under the control of their original owners. Members can decide to withdraw and start the unbonding process at any time. {% endhint %} ### Useful information The easiest and most trustful information about a pool can be obtained on-chain. When picking a pool, make sure to check its settings and current state: * **Pool commission:** Pools may charge a commission that is applied before distributing its rewards to members. * **Current nominations:** Look into the validators that the pool is currently nominating. You can use the [Selecting Validators guide](/validator-guides) to help you evaluate their current selection. * **Total stake:** Pools act as a single nominator. This means they must meet a minimum CTC staking amount to actually earn rewards. It’s a good idea to check if the pool meets this minimum amount before joining. You can check the minimum required amount in the [Nominate page](https://staking.creditcoin.org/#/nominate) of the staking dashboard. * **Pool administrators:** It a good idea to do some research on a [pool’s administrator accounts](/nominator-guides/nominating-with-staking-pools/managing-a-pool). You can look into the Depositor, Nominator, Bouncer and Root roles in the pool and look up their accounts using a block explorer. While this type of research can extend indefinitely, good questions to investigate include: * Are these different accounts or is a single one used for every role? While using a single one may be convenient, it creates a single point of failure. * Are they identified accounts with published contact information? This can increase the public accountability of the pool administrators. Plus, you may be able to ask them questions about the pool directly. # Joining a Pool CTC holders can become pool members by adding their CTC tokens to the pool’s bonded account. A pool will use all of its bonded funds when acting as a nominator. To add additional funds to a pool, users can choose to automatically re-stake their staking rewards, or manually bond additional CTC. {% hint style="info" %} **A Creditcoin account can only be member of a single pool at a time.** To exit a pool, any account can begin the unbonding process. 7 days after unbonding has started, a member can withdraw their funds, exit the pool and join a different one if desired. {% endhint %} 1. Connect to the Creditcoin Staking Dashboard with the funded account. You can only participate with transferable balance. 2. In the Pools tab, click on the Join button.
3. Pick a pool to join and click on its corresponding Join button. If unsure how to choose one, check the [Choosing a Pool](/nominator-guides/nominating-with-staking-pools/choosing-a-pool) guide.
4. You will be prompted to enter your staking preferences. 1. Enter the amount of CTC to bond. 2. Enable or disable permissionless claiming. 3. Click on submit once you are done.
5. Once the extrinsic gets included in the blockchain, you will see the Pools page again with information about the nomination pool you recently joined.
# Creating a Pool Users who want to actively contribute to Creditcoin’s security, but do not have the means to run a validator node themselves, can instead opt to set up their own nomination pool. Nomination pools act as a single nominator, and as such, do not require any dedicated hardware. By setting up a nomination pool, pool operators can actively contribute to the network’s security by organising and managing members' nomination activities. In addition, pool operators can earn a % commission fee of the pool’s total staking rewards in return for their nomination activities. As pool operators are responsible for managing members' funds, it is important that they are active in the nomination process and have a deep understanding of Creditcoin’s consensus mechanisms. For more information on how these work, please read the staking documentation [here](/staking). \ \ Please note that the current settings of minimum required amount to create a pool are * Mainnet: 10000 CTC * Testnet: 19500 tCTC ### How to create a pool 1. In the Staking Dashboard’s Pool tab, click on the Create button.
2. Name your pool.
3. Manually pick the validators you wish to nominate or use one of the provided nomination selection tools.
4. Assign the [pool roles ](/nominator-guides/nominating-with-staking-pools/managing-a-pool)to your chosen accounts. Click on Edit to set the Root, Nominator and Bouncer roles. We recommend setting multiple different accounts for maximum security. Click on Save before continuing.
5. Enter the amount of CTC you wish to bond yourself.
6. Review your settings and preferences.
7. Click on Create Pool and sign the transaction. # Exiting a Pool To withdraw funds from a nomination pool, members must unbond their funds from the pool. The unbonding process takes 7 days to complete. During this process, any funds being unbonded cannot be transferred, used to earn rewards, or join other nomination pools. Users may choose to unbond some or all of their funds at any time.To exit a nomination pool, members must start an unbonding process which takes 7 days in Creditcoin. During this period, they will not be able earn rewards form their pool or join other nomination pools. #### Unbonding some funds 1. In the Pools tab of the Staking Dashboard, click the minus sign `(-)`to remove a portion of your funds from the pool.
2. The Remove Bond page will be shown. Enter the amount of CTC to unbond or select Max to unbond all CTC from the pool.
3. Finally, click on Submit to sign the transaction. This will start the unbonding period (7 days). #### Unbonding all funds 1. Members that wish to unbond all their funds can use the Leave pool option shown in the Manage menu.
2. This option will always unbond the full amount. After submitting the transaction, the unbonding period (7 days) will begin.
#### Withdrawing funds After waiting for the unbonding period to end, users may withdraw their funds from the pool permanently. These funds will then be available to transfer, or to join a different pool if desired. 1. In the Pools tab, click the unlock sign to withdraw your funds.
2. The Withdraw page will show. Click the Withdraw button to sign the transaction. 3. After signing, funds should be available once again. # Managing a Pool ### Managing a pool Once your pool is created, you will see a new button named Manage in the Pools tab.
This menu provides tools to change most of the pools settings:
Commission can be configured using three different values: * **Commission:** the current commission for a pool; the owner will receive a % of the staking rewards before distributing it with the members. * **Max Commission:** the maximum commission the pool can have; once set it cannot be changed. It is meant to be a contract between the pool operators and the members. * **Change Rate:** the maximum amount the commission can change for the set period of time. Pool operators cannot perform changes to commissions that exceed the change rate. {% hint style="warning" %} When managing a pool’s commission, once Max Commission and Change Rate are set, they cannot be changed to a higher value. This is meant to prevent pool administrators from abusing their members by changing the commission without notice. {% endhint %} ## Pool Administration ### Roles * Depositor: The pool creator; it bonds the initial deposit in order to make the pool a valid nominator. * Nominator: It has permissions to select which validators the pool nominates. * Bouncer: It has permissions to switch between the different pool states and kick (force unbond) members. * Root: The pool administrator, it can change the other roles (even itself) and can do any of the actions the others can. ### States * Open: new members can join the pool. * Blocked: the pool is closed and it will not allow new members. * Destroying: the pool is in the process of being destroyed; it acts as being blocked, but existing members can also be forced to unbond by anyone, allowing the pool to be dismantled even if it has inactive members. ## Destroying a pool Pool destruction is done by the Bouncer role. Connect with the Bouncer account and go to the pool’s Manage panel. {% hint style="warning" %} The initial depositor must remain in the pool until all other members have left; only then it will be able to withdraw. {% endhint %} Select Destroy Pool and submit the transaction to set the pool’s status to destroying. When set to Destroying a pool will be closed to new members and all members can be permissionlessly unbonded in order to ease the dismantling of the pool. The initial depositor must wait for everyone to withdraw before unlocking its own bonded tokens.
# Nominating without Staking Pools ### Account Setup Solo Nominators are recommended to set up separate stash account, an account solely used for staking CTC. Users generate your stash account via any of the recommended methods, which are detailed in the [wallets](/wallets) section. If you'd like to redirect payments to a wallet that is not your stash, set up another account beforehand. We strongly recommend against using an exchange address as the recipient for any staking rewards. #### Stash Security Staking on Creditcoin requires active monitoring, as users must regularly sign transactions such as nominations. This involves exposing the private key, posing a security risk, especially for hot stashes. Even if using a hardware wallet, signing transactions creates a history revealing user habits and potentially location information. As a best practice, accounts with high economic power should remain isolated. This can be achieved by the proper use of [Proxy accounts](/wallets/advanced/proxy-accounts). ### Selecting validators {% hint style="warning" %} Nominating validators on Creditcoin is an active role. If users' nominated validators misbehave, users may lose some or all of their funds due to [slashing](/staking/slashing). Even if offences do not trigger slashing, they might still cause the validator to be chilled, meaning that any nominators backing them will also stop earning rewards in that era. For more information about how to select good validator refer to the [Selecting Validators](#selecting-validators) section. Users who do not wish to actively participate in the nomination process, but who nevertheless want to earn staking rewards, can instead join a Nomination Pool. By doing so, users effectively delegate their votes to the Nomination Pool operator, who will assign them to validator candidates. {% endhint %} #### Nominating Best Practices **Choose multiple validators** Since stake is allocated after the validator election, nominators do not need to manage the allocation of their staking quantities themselves. As long as one or more of a nominator's chosen validators are elected to the active set, all of that nominators stake will be actively used to back those chosen validators. Nominators who only choose to back a small number of validators risk getting no rewards if none of them are elected to be part of the active set. Inversely, the distribution of a nominator’s stake is more likely to result in higher rewards if they choose more validators to support. Therefore, it is always advisable for a nominator to choose as many trustworthy validators as possible. {% hint style="info" %} For more information about the validator election and stake allocation process refer to the[ Validator Elections](/staking/validator-elections) section. {% endhint %} **Check validator identity** If a validator has set its identity, you'll see their details on the Community tab of the Staking Dashboard. Besides a displayed name, a validator can also indicate their email, website, X account, or something else. You can use this information to perform further due diligence and/or ask the validator questions directly. **Check the commission** A validator’s block rewards are shared with all of its backing nominators according to their relative total stake. However, validators can also set a pre-defined % commission commission they receive, after which any remaining rewards are then distributed between nominators and validators. This rate can vary greatly. Validators that set up a 100% commission do not share any rewards with their nominators, while validators that choose a 0% commission will share all rewards with their nominators. You can use the Staking Dashboard to sort validators based on their commission fee. **Make sure the validator is not oversubscribed** Only the top 512 nominators (calculated by total stake) for a specific validator get paid. Validators over this limit are marked with a red warning sign on the Staking Dashboard. If you nominate these validators, and they are elected into the active set, your stake may still be used to support them even if you aren’t in the top 512 validators, and as a result, don’t earn any rewards for doing so. This means you will be taking on potential risk for potentially no reward. Therefore, it’s a good idea to avoid over-subscribed validators, unless you’re confident you have enough CTC staked to be in the top 512 nominators every era. It can also be a good idea to avoid validators with a high number of current nominators, because they may become oversubscribed soon. **Add good validators to your Favorites** When you have decided on your validators, add them to your Favorites: click on the heart icon on the Staking Dashboard. This will allow you to quickly select them as one of your nominations later. ### Nominate using the Staking Dashboard 1. Connect your wallet to the [Creditcoin Staking Dashboard](https://staking.creditcoin.org/) by clicking the "Connect" button in the top-right corner. Select your account. 2. Navigate to the Nominate section and click on "Start Nominating". Please note that the current settings of minimum required amount to solo nominate are * Mainnet: 1000 CTC * Testnet: 0
3. Select the payout destination.
4. Select your nominations using one of the provided filters or manually.
5. Enter the amount of CTC to bond.
6. Review your preferences and click on Start Nominating to sign the transaction.
Once your transaction has been confirmed and the next era begins, you’ll officially be participating as an active nominator on the Creditcoin network. Once your chosen validators are elected, you’ll start earning CTC rewards too! # Claiming Rewards Rewards for staking CTC are not automatically credited to validators and nominators, they must be distributed first. Anyone can trigger the payout for any validator by submitting the corresponding transaction. Validators are recommended to distribute payouts for their nominators at the end of each era. ### Validator Payouts Validators can trigger payouts for themselves and other validators by using the `creditcoin`'s `distribute` command and specifying both their stash address and the era they are distributing payouts for. For more information about operating a Validator, refer to the [Validator Guide](/validator-guides). ### Pool Payouts Pools store all of their rewards as pending till users decide to compound or withdraw their rewards. Pool members can also opt to allow other to trigger compound or withdrawal of their funds. As a nominator within a pool, you can withdraw or compound your rewards in the staking dashboard pool page once the payout has been triggered.
The same options are also available in the nominate page if you are nominating outside of a pool. For more information about using Staking Pools, go to the [Nominating with Staking Pools section](/nominator-guides/nominating-with-staking-pools). # Validator Guides ### Tasks and Responsiblities Validators are critical to maintaining the network. They maintain the Creditcoin network by producing and finalizing blocks through the Nominated Proof-of-Stake system. When performing validation tasks, validators are accountable not only for their own stake but also the stake of the nominators that back them. Node operators have two main responsibilities: * Keeping their validator nodes highly available. * Protecting their signing keys to prevent attackers from taking control and performing malicious actions using the validators identity. Currently, operators run validator nodes and manage session keys, produce new block candidates in BABE, vote and come to consensus in GRANDPA, and, possibly, hold certain other responsibilities regarding data availability and XCM. ### Rewards and Slashing Validators get rewarded at the end of each era according to how many era points they have collected. These points are earned by producing blocks. When an era ends, rewards are distributed between validators and their nominators according to their relative stake and the validator's commission parameters. Validators have the ability to configure and receive a commission, allowing them to earn a percentage of nominator block rewards based on their chosen parameters. Validators can only set a percentage-based commission, rather than a figure-based commission. 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, and 100% commission means that the validator operator gets all rewards and gives none to its nominators. {% hint style="info" %} The Creditcoin Staking system is based on Polkadot’s NPoS. For more details about the implementation, refer to the [Polkadot Staking documentation](https://wiki.polkadot.network/docs/maintain-guides-validator-payout). {% endhint %} # Minimum requirements The most common way for a beginner to run a validator using the Creditcoin Docker image is on a cloud server running Linux. We strongly recommend using a recent Debian Linux OS. For this guide we will be using **Ubuntu 22.04**, but the instructions should be similar for other platforms. {% hint style="warning" %} Creditcoin does not currently support Macs using Apple silicon, such as the M1, M2 and M3. The provided Docker image is Linux x86\_64 (amd64) only. {% endhint %} * **CPU** * Intel Core i5-8400 or better * 6 Cores @ 2.8Ghz * 9M Cache * **Storage** * Needs to be sufficient for targeted chain * 512G+ recommended for CC3 mainnet as of 2026-02-03 * **Memory** * 8GB * **System** * Ubuntu 22.04 (Linux Kernel 5.16 or newer) * **Tokens** * The minimum stake required to run a validator is documented per environment [here](/environments). ### Running hardware benchmarks {% hint style="warning" %} It is strongly recommended that validators either meet or exceed these hardware specifications in order to ensure that they can process all blocks in time. If you use suboptimal hardware you will possibly run into performance issues, get less era points, and potentially even get slashed. {% endhint %} \ The transaction weights in Creditcoin are benchmarked on reference hardware. We ran the benchmark on a memory optimized `Standard_E4as_v4` VM instance of Azure.\ \ To make sure your validator meets these specifications, you can [build the ](https://github.com/gluwa/creditcoin3)Creditcoin3 node with `cargo build --release --features runtime-benchmarks` and execute `creditcoin-node benchmark machine --chain dev` to get a hardware report: ``` 2024-01-16 15:58:46 Running machine benchmarks... 2024-01-16 15:59:12 +----------+----------------+-------------+-------------+-------------------+ | Category | Function | Score | Minimum | Result | +===========================================================================+ | CPU | BLAKE2-256 | 941.53 MiBs | 783.27 MiBs | ✅ Pass (120.2 %) | |----------+----------------+-------------+-------------+-------------------| | CPU | SR25519-Verify | 427.06 KiBs | 560.67 KiBs | ❌ Fail ( 76.2 %) | |----------+----------------+-------------+-------------+-------------------| | Memory | Copy | 14.56 GiBs | 11.49 GiBs | ✅ Pass (126.7 %) | |----------+----------------+-------------+-------------+-------------------| | Disk | Seq Write | 1.00 GiBs | 950.00 MiBs | ✅ Pass (108.2 %) | |----------+----------------+-------------+-------------+-------------------| | Disk | Rnd Write | 437.80 MiBs | 420.00 MiBs | ✅ Pass (104.2 %) | +----------+----------------+-------------+-------------+-------------------+ From 5 benchmarks in total, 4 passed and 1 failed (10% fault tolerance). 2024-01-16 15:59:12 The hardware fails to meet the requirements ``` # Using a Docker container #### Sync Chain Data Ensure Docker is installed (or [install it in your OS of choice](https://docs.docker.com/engine/install/)) and run the `gluwa/creditcoin3` Docker image. ### Using Docker to run a Mainnet node #### Generating a network p2p key (Necessary for new Mainnet nodes starting 3.52.0) Starting v3.52.0, **new nodes that intend to be validators will no longer generate a network key automatically on start-up**. Validator nodes in existence prior to v3.52.0 do not need to make changes to how they handle the network key. When setting up a new node, run the following command to generate and store on disk the network key that will be referenced in the start-up command: ``` docker run --name creditcoin-validator -p 30333:30333 -v :/creditcoin-node/data gluwa/creditcoin3:3.66.0-mainnet key generate-node-key --chain mainnet --base-path --bin ``` The command will output a node peer ID. It will also generate a secret for the node key and insert it into the correct path (`/creditcoin-node/data/chains/creditcoin3/network/secret_ed25519`). You can also take a look at other ways to generate the node key file inside the [Starting a Node](/validator-guides/notes-for-starting-a-node) section **CAUTION**: This step can be bypassed using the --unsafe-force-node-key-generation argument in the start-up command. This parameter forces the generation of a new network key even if one already exists under the network folder or if the system would normally prevent its generation under certain conditions. Attempting to run a validator without its network key configured will result in the following error: ``` Error: NetworkKeyNotFound("/data/chains/creditcoin3/network/secret_ed25519") ``` {% hint style="info" %} Docker should automatically pull the specified `gluwa/creditcoin3` image. If not, you can try pulling it yourself from DockerHub by running `docker pull gluwa/creditcoin3:3.131.0-mainnet` and then re-running the command below. {% endhint %} {% hint style="warning" %} PowerShell does not support comments on multiline commands, please use the uncommented version. {% endhint %} {% tabs %} {% tab title="Bash" %} ``` docker run \ --name creditcoin-validator \ -p 30333:30333 \ -v :/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-mainnet `# Enter latest mainnet image` \ --name "validator name" `# name the validator` \ --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" `# (optional) opt in to telemetry` \ --public-addr "/dns4//tcp/30333" `# REPLACE with the public IP address or host name at which your node can be reached` \ --chain /mainnetSpecRaw.json `# we want to connect to mainnet` \ --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" \ --validator `# if we want to run a validator node` \ --base-path /creditcoin-node/data `# the base path to store the node's data` \ --port 30333 # the port to use for node-to-node communications ``` {% endtab %} {% tab title="Uncommented Bash" %} ``` docker run \ --name creditcoin-validator \ -p 30333:30333 \ -v :/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-mainnet \ --name "validator name" \ --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" \ --public-addr "/dns4//tcp/30333" \ --chain /mainnetSpecRaw.json \ --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" \ --validator \ --base-path /creditcoin-node/data \ --port 30333 ``` {% endtab %} {% tab title="PowerShell" %} ``` docker run ` --name creditcoin-validator ` -p 30333:30333 ` -v :/creditcoin-node/data ` # Enter mainnet image gluwa/creditcoin3:3.131.0-mainnet ` # name the validator --name "validator name" ` # (optional) opt in to telemetry --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" ` # REPLACE with the public IP address or host name that your node can be reached at --public-addr "/dns4//tcp/30333" ` # we want to connect to mainnet --chain /mainnetSpecRaw.json ` # we want to run a validator node --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" ` --validator ` # the base path to store the node's data --base-path /creditcoin-node/data ` # the port to use for node-to-node communication --port 30333 ``` {% endtab %} {% tab title="Uncommented PowerShell" %} ``` docker run ` --name creditcoin-validator ` -p 30333:30333 ` -v :/creditcoin-node/data ` gluwa/creditcoin3:3.131.0-mainnet ` --name "validator name" ` --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" ` --public-addr "/dns4//tcp/30333" ` --chain /mainnetSpecRaw.json ` --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" ` --validator ` --base-path /creditcoin-node/data ` --port 30333 ``` {% endtab %} {% endtabs %} In the command above, notice the `-v` flag that takes a local directory as the first part of the parameter. It's important that Docker has the ability to write to this directory, otherwise, you will see errors such as `Error: Service(Client(Backend("IO Error: Permission denied (os error 13)")))`. Your command will likely use a path similar to `-v /home/validator/data:/creditcoin-node/data`. Here is an example command to run a validator that connects to the Creditcoin **Mainnet**: ``` docker run \ -p 30333:30333 \ -v ~/chain_data:/data \ gluwa/creditcoin3:3.131.0-mainnet \ --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" \ --chain /mainnetSpecRaw.json \ --validator \ --base-path /data \ --port 30333 ``` ### Using Docker to run a Testnet node #### Generating a network p2p key (Necessary for new Testnet nodes starting 3.47.0) Starting v3.47.0, **new nodes that intend to be validators will no longer generate a network key automatically on start-up**. Validator nodes in existence prior to v3.47.0 do not need to make changes to how they handle the network key. When setting up a new node, run the following command to generate and store on disk the network key that will be referenced in the start-up command: ``` docker run --name creditcoin-validator -p 30333:30333 -v :/creditcoin-node/data gluwa/creditcoin3:3.131.0-testnet key generate-node-key --chain testnet --base-path --bin ``` The command will output a node peer ID. It will also generate a secret for the node key and insert it into the correct path (`/creditcoin-node/data/chains/creditcoin3-testnet/network/secret_ed25519`). You can also take a look at other ways to generate the node key file inside the [Starting a Node](/validator-guides/notes-for-starting-a-node) section **CAUTION**: This step can be bypassed using the --unsafe-force-node-key-generation argument in the start-up command. This parameter forces the generation of a new network key even if one already exists under the network folder or if the system would normally prevent its generation under certain conditions. Attempting to run a validator without its network key configured will result in the following error: ``` Error: NetworkKeyNotFound("/data/chains/creditcoin3_testnet/network/secret_ed25519") ``` {% hint style="info" %} Docker should automatically pull the specified `gluwa/creditcoin3` image. If not, you can try pulling it yourself from DockerHub by running `docker pull gluwa/creditcoin3:3.131.0-testnet` and then re-running the command below. {% endhint %} {% hint style="warning" %} PowerShell does not support comments on multiline commands, please use the uncommented version. {% endhint %} {% tabs %} {% tab title="Bash" %} ``` docker run \ --name creditcoin-validator \ -p 30333:30333 \ -v :/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-testnet `# Enter latest testnet image` \ --name "validator name" `# name the validator` \ --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" `# (optional) opt in to telemetry` \ --public-addr "/dns4//tcp/30333" `# REPLACE with the public IP address or host name at which your node can be reached` \ --chain testnet `# we want to connect to the testnet` \ --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" \ --validator `# we want to run a validator node` \ --base-path /creditcoin-node/data `# the base path to store the node's data` \ --port 30333 # the port to use for node-to-node communications ``` {% endtab %} {% tab title="Uncommented Bash" %} ``` docker run \ --name creditcoin-validator \ -p 30333:30333 \ -v :/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-testnet \ --name "validator name" \ --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" \ --public-addr "/dns4//tcp/30333" \ --chain testnet \ --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" \ --validator \ --base-path /creditcoin-node/data \ --port 30333 ``` {% endtab %} {% tab title="PowerShell" %} ``` docker run ` --name creditcoin-validator ` -p 30333:30333 ` -v :/creditcoin-node/data ` # Enter testnet image gluwa/creditcoin3:3.131.0-testnet ` # name the validator --name "validator name" ` # (optional) opt in to telemetry --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" ` # REPLACE with the public IP address or host name that your node can be reached at --public-addr "/dns4//tcp/30333" ` # we want to connect to the testnet --chain testnet ` # we want to run a validator node --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" ` --validator ` # the base path to store the node's data --base-path /creditcoin-node/data ` # the port to use for node-to-node communication --port 30333 ``` {% endtab %} {% tab title="Uncommented PowerShell" %} ``` docker run ` --name creditcoin-validator ` -p 30333:30333 ` -v :/creditcoin-node/data ` gluwa/creditcoin3:3.131.0-testnet ` --name "validator name" ` --telemetry-url "wss://telemetry.creditcoin.network/submit/ 0" ` --public-addr "/dns4//tcp/30333" ` --chain testnet ` --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" ` --validator ` --base-path /creditcoin-node/data ` --port 30333 ``` {% endtab %} {% endtabs %} In the command above, notice the `-v` flag that takes a local directory as the first part of the parameter. It's important that Docker has the ability to write to this directory, otherwise, you will see errors such as `Error: Service(Client(Backend("IO Error: Permission denied (os error 13)")))`. Your command will likely use a path similar to `-v /home/validator/data:/creditcoin-node/data`. Here is an example command to run a validator that connects to the Creditcoin **Testnet**: ``` docker run \ -p 30333:30333 \ -v ~/chain_data:/data \ gluwa/creditcoin3:3.131.0-testnet \ --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" \ --chain testnet \ --validator \ --base-path /data \ --port 30333 ``` # Stake using Creditcoin CLI #### Running from the Docker image Make sure your Creditcoin Node container is running and use Creditcoin CLI via the `docker exec` command. ``` docker exec -it creditcoin-validator creditcoin --help ``` {% hint style="danger" %} Security notes:\ \ When using docker, employ `docker exec` as specified in these docs to keep sensitive values out of the container's logs on your system. Only use the Creditcoin CLI to administer a validator from its own machine or container. Do not use the Creditcoin CLI to remotely administer a validator even on the same LAN or virtual network. Connections to the node, from the Creditcoin CLI, are made over unencrypted and unauthenticated websockets and are only safe for use on the loopback interface. (i.e `localhost`, `127.0.0.1`) Remember that, when using any terminal or command line tool, commands entered in your terminal window are visible to other users and services on your system. Only enter secrets like seed phrases when prompted by the Creditcoin CLI. {% endhint %} #### Creating Accounts Create an account using the `new` command and write down the seed phrase. ``` docker exec creditcoin-validator creditcoin new ``` The output should look like the following: ``` Creating new seed phrase... Seed phrase: owner amateur hungry hockey clerk size parrot jump rural mad pretty gauge ``` Use `show-address` to get the address for the account by entering the seed phrase, so you can fund it with a transfer. This will be the Stash account that will hold all tokens meant for staking. ``` docker exec -it creditcoin-validator creditcoin show-address ``` Output: ``` ✔ Specify a seed phrase for the caller account … ************************************************************************* Account Substrate address: 5CUnLxUCFqtGkre7MZwyX66E3kPMKDXra4FYtiYp5SoDUwKM Associated EVM address: 0x125cff2b5d2e00c0a0b632a7c1979c19bf70ac22 ``` #### Funding Your Account Once your account is created, make sure it has enough CTC to cover the desired staking amount *plus* transaction fees. To fund an account, you can transfer from another wallet using a number of tools such as [Subwallet](https://www.subwallet.app/), [Talisman](https://www.talisman.xyz/), the [PolkadotJS extension](/wallets/how-to-connect-your-wallet-to-creditcoin/polkadot-js-extension) or [Creditcoin CLI](/wallets/how-to-connect-your-wallet-to-creditcoin/command-line-interface/creditcoin-cli). The minimum amount of CTC required to become a validator * Mainnet: 0 * Testnet: 20000 CTC You can confirm the balance of your account by following the directions mentioned in the [Checking your Balance section of the Creditcoin CLI 3 page](/wallets/how-to-connect-your-wallet-to-creditcoin/command-line-interface/creditcoin-cli). #### Validator Wizard Creditcoin CLI provides a simple Wizard to set up validators. `wizard` will prompt you for the previously generated seed phrase. After launching the wizard and providing it with the seed phrase, it will show us the complete validator setup options and prompt us to continue. {% hint style="danger" %} Security note: Account’s private keys are derived from these seed phrases. Every account must have a unique seed phrase. Remember to use separate accounts (i.e. new seed phrases) for testnet and mainnet validators. {% endhint %} ``` docker exec -it creditcoin-validator creditcoin wizard --amount ``` It will show the current staking settings, make sure to check them before continuing. ``` 🧙 Running staking wizard... Using the following parameters: 💰 Stash account: 5CUnLxUCFqtGkre7MZwyX66E3kPMKDXra4FYtiYp5SoDUwKM 🪙 Amount to bond: 20000 CTC 🎁 Reward destination: Staked 📡 Node URL: ws://127.0.0.1:9944 💸 Commission: 0 🔐 Blocked: No Continue? (y/n): y ``` After continuing, the Wizard will create all required extrinsics (i.e. transactions) and communicate with the node to pair it with the stash account. Once the transactions are sent, the new validator should be in the waiting queue. Use the status command to get information about the status of a particular validator by entering its Stash address. ``` docker exec -it creditcoin-validator creditcoin status --substrate-address 5CGBosx2Fw34u9jJtSgEQkoNTtHkPLKgsfjJiE3mDSWb44MW ``` The validator status will be shown: ``` Validator 5CGBosx2Fw34u9jJtSgEQkoNTtHkPLKgsfjJiE3mDSWb44MW: ┌────────────────┬──────┐ │ Status │ │ ├────────────────┼──────┤ │ Bonded │ Yes │ ├────────────────┼──────┤ │ Validating │ Yes │ ├────────────────┼──────┤ │ Waiting │ Yes │ ├────────────────┼──────┤ │ Active │ No │ ├────────────────┼──────┤ │ Can withdraw │ No │ ├────────────────┼──────┤ │ Next unlocking │ None │ └────────────────┴──────┘ ``` If the validator shows up as Waiting the setup has been successful and it will become active if it gets enough backing. #### Manual Setup Setting a validator can also be done by sending each required command manually. First bond CTC using your Stash account and enter the CTC amount to stake. ``` docker exec -it creditcoin-validator creditcoin bond --amount ``` Set the validator node keys. The `--rotate` flag specifies that the node will generate new keys. Existing keys can be used with the `--keys ` option. ``` docker exec -it creditcoin-validator creditcoin set-keys --rotate ``` Once keys are set up, the last step is signaling the network the intention to validate. Use the `--commission ` option to set up a portion of the block reward that will not be shared with nominators or the `--blocked` flag to block nominations. ``` docker exec -it creditcoin-validator creditcoin validate --commission ``` #### Distributing Rewards It is conventionally the validator operator's responsibility to trigger the reward distribution at the end of every era. The address of the stash account doubles as the validator's ID when distributing rewards. Remember, you can compute the stash account's address by running the following and providing the stash account's seed phrase when prompted: ``` docker exec -it creditcoin-validator creditcoin show-address ``` With the stash address in hand, run the `distribute-rewards` command. ``` docker exec -it creditcoin-validator creditcoin distribute-rewards --era --substrate-address ``` #### Stopping a Validator Stop a running validator with the `chill` command. This will remove the validator from the active/waiting set in the next session. ``` docker exec -it creditcoin-validator creditcoin chill ``` #### Unbonding CTC To unbond locked CTC, validators must first mark their tokens for unbonding, then wait for the unlocking period to end and finally withdraw the unbonded funds. ``` docker exec -it creditcoin-validator creditcoin unbond --amount ``` The status command shows when the next unlocking chunk will be available to withdraw. ``` docker exec -it creditcoin-validator creditcoin status --substrate-address ``` ``` Validator 5CGBosx2Fw34u9jJtSgEQkoNTtHkPLKgsfjJiE3mDSWb44MW: ┌────────────────┬─────────────────────────────────┐ │ Status │ │ ├────────────────┼─────────────────────────────────┤ │ Bonded │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Validating │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Waiting │ Yes │ ├────────────────┼─────────────────────────────────┤ │ Active │ No │ ├────────────────┼─────────────────────────────────┤ │ Can withdraw │ No │ ├────────────────┼─────────────────────────────────┤ │ Next unlocking │1000 CTC in 6 minutes, 5 seconds │ └────────────────┴─────────────────────────────────┘ ``` After the unbonding period has passed, withdraw the funds. ``` docker exec -it creditcoin-validator creditcoin withdraw-unbonded ``` # Notes for Starting a Node Starting a node without the `network/secret_ed25519` P2P key is now prohibited. This is especially important for first-time node-runners. If you try to run the node without `network/secret_ed25519` file present, you will encounter an error:\ `NetworkKeyNotFound("./data/chains/creditcoin3/network/secret_ed25519")` * If you are already a running authority, you will not need to do anything, since the secret file is already present in your `base-path`, after the initial setup. If you want to become an authority (or run a node of any kind, for that matter), there are a couple of ways to fix this issue: * \[Preferred] Separately generate the key with:\ ` key generate-node-key --bin --base-path --chain mainnet`\ This will generate the secret file for you and insert it inside the correct base-path directory. This command will also output your node’s public identity after it's executed. * \[Preferred] Separately generate the key file with:\ ` key generate-node-key --file ./secret_ed25519 --bin`\ and then manually put the resulting file into \ `/chains/creditcoin3/network/` * \[Unsafe] Pass --unsafe-force-node-key-generation to the node startup command to force Creditcoin to generate the key and insert it in the correct directory. Make sure you remove the flag `--unsafe-force-node-key-generation` for subsequent node restarts. It is recommended to use the unsafe option only for local testing, and if you know what you are doing If your node is used as an RPC, you can now add RPC server rate limiting * The CLI flag can utilize it at node startup `--rpc-rate-limit `
* Added option to whitelist IPs in rate limiting * `--rpc-rate-limit 10 --rpc-rate-limit-whitelisted-ips 127.0.0.1/8 --rpc-rate-limit-trust-proxy-headers` * Can be added as a node startup command, same as above # RPC Guide #### Prerequisites Ensure Docker is installed (or [install it in your OS of choice](https://docs.docker.com/engine/install/)) and run the `gluwa/creditcoin3` Docker image. ### Using Docker to run a Mainnet RPC {% hint style="info" %} Docker should automatically pull the specified `gluwa/creditcoin3` image. If not, you can try pulling it yourself from DockerHub by running `docker pull gluwa/creditcoin3:3.131.0-mainnet` and then re-running the command below. {% endhint %} {% tabs %} {% tab title="Bash" %} ```bash docker run \ --name creditcoin-rpc \ -p 30333:30333 \ -p 9944:9944 \ -p 9615:9615 \ -v /path/to/your/data:/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-mainnet \ --name "rpc name" \ --prometheus-external \ --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" \ --public-addr "/dns4//tcp/30333" \ --chain /mainnetSpecRaw.json \ --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" \ --pruning archive \ --base-path /creditcoin-node/data \ --port 30333 \ --rpc-external \ --rpc-cors all \ --rpc-max-connections 1024 ``` {% endtab %} {% tab title="PowerShell" %} ```powershell docker run ` --name creditcoin-rpc ` -p 30333:30333 ` -p 9944:9944 ` -p 9615:9615 ` -v /path/to/your/data:/creditcoin-node/data ` gluwa/creditcoin3:3.131.0-mainnet ` --name "rpc name" ` --prometheus-external ` --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" ` --public-addr "/dns4//tcp/30333" ` --chain /mainnetSpecRaw.json ` --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" ` --pruning archive ` --base-path /creditcoin-node/data ` --port 30333 ` --rpc-external ` --rpc-cors all ` --rpc-max-connections 1024 ``` {% endtab %} {% endtabs %} #### **Configuration Notes** * **Port 30333**: Node-to-node P2P communications port * **Port 9944**: JSON-RPC/WebSocket endpoint for blockchain interaction. * **Port 9615**: Prometheus metrics endpoint (optional) * **-v (volume mount)**: Maps host directory to container path. Replace `/path/to/your/data` with your actual data directory path. It's important that docker has the ability to write to this directory, otherwise you will see errors such as `Error: Service(Client(Backend("IO Error: Permission denied (os error 13)")))`. * **--name**: Custom name for your RPC node * **--prometheus-external**: Enable Prometheus metrics (optional) * **--telemetry-url**: Opt in to telemetry reporting (optional) * **--public-addr**: Replace `` with your actual public IP or hostname * **--chain**: Connect to mainnet using the spec file (use `testnet` for testnet) * **--pruning archive**: Keep full chain history * **--base-path**: Directory inside container to store node data * **--rpc-external**: Allow RPC connections from external sources * **--rpc-cors all**: Allow all CORS origins * **--rpc-max-connections**: Maximum concurrent RPC connections #### Additional Flags * **--rpc-max-request-size:** Maximum RPC request payload size in MB for HTTP and WS (default: 15) * **--rpc-max-response-size**: Maximum RPC response payload size in MB for HTTP and WS (default: 15) * **--rpc-max-batch-request-len:** Maximum number of requests per RPC batch * **--rpc-disable-batch-requests**: Disable RPC batch requests (recommended for private nodes) * **--max-past-logs:** Maximum number of logs in a query (default: 10000, effectively limited by 10s query timeout) ### Using Docker to run a Testnet RPC {% hint style="info" %} Docker should automatically pull the specified `gluwa/creditcoin3` image. If not, you can try pulling it yourself from DockerHub by running `docker pull gluwa/creditcoin3:3.131.0-testnet` and then re-running the command below. {% endhint %} {% tabs %} {% tab title="Bash" %} ```bash docker run \ --name creditcoin-rpc \ -p 30333:30333 \ -p 9944:9944 \ -p 9615:9615 \ -v /path/to/your/data:/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-testnet \ --name "rpc name" \ --prometheus-external \ --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" \ --public-addr "/dns4//tcp/30333" \ --chain testnet \ --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" \ --pruning archive \ --base-path /creditcoin-node/data \ --port 30333 \ --rpc-external \ --rpc-cors all \ --rpc-max-connections 1024 ``` {% endtab %} {% tab title="PowerShell" %} ```powershell docker run ` --name creditcoin-rpc ` -p 30333:30333 ` -p 9944:9944 ` -p 9615:9615 ` -v path/to/your/data:/creditcoin-node/data ` gluwa/creditcoin3:3.131.0-testnet ` --name "rpc name" ` --prometheus-external ` --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" ` --public-addr "/dns4//tcp/30333" ` --chain testnet ` --bootnodes "/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K" ` --pruning archive ` --base-path /creditcoin-node/data ` --port 30333 ` --rpc-external ` --rpc-cors all ` --rpc-max-connections 1024 ``` {% endtab %} {% endtabs %} **Configuration Notes** * **Port 30333**: Node-to-node P2P communications port * **Port 9944**: JSON-RPC/WebSocket endpoint for blockchain interaction. * **Port 9615**: Prometheus metrics endpoint (optional) * **-v (volume mount)**: Maps host directory to container path. Replace `/path/to/your/data` with your actual data directory path. It's important that docker has the ability to write to this directory, otherwise you will see errors such as `Error: Service(Client(Backend("IO Error: Permission denied (os error 13)")))`. * **--name**: Custom name for your RPC node * **--prometheus-external**: Enable Prometheus metrics (optional) * **--telemetry-url**: Opt in to telemetry reporting (optional) * **--public-addr**: Replace `` with your actual public IP or hostname * **--chain**: Connect to mainnet using the spec file (use `testnet` for testnet) * **--pruning archive**: Keep full chain history * **--base-path**: Directory inside container to store node data * **--rpc-external**: Allow RPC connections from external sources * **--rpc-cors all**: Allow all CORS origins * **--rpc-max-connections**: Maximum concurrent RPC connections ### EVM Tracing EVM tracing allows you to replay transactions and inspect internal calls, opcode execution, memory/stack/storage changes, and gas usage. On Frontier-based Substrate nodes, enabling tracing adds significant CPU and I/O overhead because the node re-executes transactions to produce the trace. **Do not enable tracing on validators or high-throughput public RPCs.** Prefer a dedicated tracing node. #### **How to enable EVM tracing** Add the `debug` , `trace` and `txpool` RPC namespaces to the `ethapi` flag on a node running in archive mode: ``` --ethapi=debug,trace,txpool ``` #### **What you get with tracing enabled** | Parameter | Description | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--ethapi=debug` | Exposes Geth debug RPCs like `debug_traceTransaction`, `debug_traceBlockByNumber`, `debug_traceBlockByHash`, and `debug_traceCall`. Use these to replay/inspect execution, internal calls, and gas usage | | `--ethapi=trace` | Exposes OpenEthereum trace RPCs, such as `trace_filter` for historical execution traces across blocks and transactions. Helpful for indexers and deep forensics | | `--ethapi=txpool` | Exposes transaction pool RPCs: `txpool_content`, `txpool_inspect`, `txpool_status` to view pending/queued transactions seen by your node | #### **Performance considerations & best practices** It is important to note that enabling tracing for EVM transactions significantly increases resource usage. Below are some details and best practices if you decide to enable EVM tracing on your nodes * **Use a dedicated node:** Run tracing on a separate full/archive node and point your tooling at that endpoint. Avoid enabling tracing on validators or busy public RPCs. * **Archive pruning:** Keep `--pruning archive` so that historical traces can be retrieved reliably. * **Expect higher resource usage:** Tracing replays execution and is CPU/IO intensive. Whole-block traces are particularly heavy. * **Scope your traces:** When calling `debug_traceTransaction`/`debug_traceCall`, consider disabling unneeded data (`disableStorage`, `disableMemory`, `disableStack`) to reduce payload size and processing time. * **Access control:** If exposing publicly, consider IP filtering, auth proxying, or rate limiting in front of your tracing RPC to protect node resources. *** If you only need a standard RPC endpoint, use the **basic** guide above. Enable the tracing parameters **only** when you specifically need low-level EVM execution details.
{% tabs %} {% tab title="Bash" %} ```bash docker run \ --name creditcoin-tracing \ -p 30333:30333 \ -p 9944:9944 \ -p 9615:9615 \ -v /path/to/your/data:/creditcoin-node/data \ gluwa/creditcoin3:3.131.0-mainnet \ --name "tracing rpc" \ --public-addr "/dns4//tcp/30333" \ --chain /mainnetSpecRaw.json \ --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" \ --pruning archive \ --base-path /creditcoin-node/data \ --port 30333 \ --rpc-external \ --rpc-cors all \ --rpc-max-connections 1024 \ --prometheus-external \ --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" \ --ethapi=debug,trace,txpool ``` {% endtab %} {% tab title="Powershell" %} ```powershell docker run ` --name creditcoin-tracing ` -p 30333:30333 ` -p 9944:9944 ` -p 9615:9615 ` -v /path/to/your/data:/creditcoin-node/data ` gluwa/creditcoin3:3.131.0-mainnet ` --name "tracing rpc" ` --public-addr "/dns4//tcp/30333" ` --chain /mainnetSpecRaw.json ` --bootnodes "/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy" ` --pruning archive ` --base-path /creditcoin-node/data ` --port 30333 ` --rpc-external ` --rpc-cors all ` --rpc-max-connections 1024 ` --prometheus-external ` --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" ` --ethapi=debug,trace,txpool ``` {% endtab %} {% endtabs %} # EVM-compatibility Creditcoin includes its own Ethereum Virtual Machine (EVM), which allows developers to use existing Ethereum tools to deploy their own smart contracts on-chain. The EVM compatibility layer is made of several main components: * **Execution environment:** the actual EVM that allows deploying and running contracts compiled using Solidity, Vyper, or other smart contract programming languages. * **Block and Transaction data:** EVM blocks and transactions are stored by Creditcoin alongside the Substrate blockchain, allowing Ethereum explorers to index the EVM side of Creditcoin just as they would with other Ethereum-based chains. * **Compatible RPC:** Creditcoin provides an EVM compatible RPC endpoint in addition to its Substrate endpoint. Developers can leverage this to quickly integrate existing dApp tools and protocols with the Creditcoin mainnet. ### Key differences #### Transaction fees & gas Creditcoin and Ethereum have different transaction fee models. While on Ethereum, fees are paid according to how much computational and storage resources are used, Creditcoin uses the Substrate concept of “weight” to calculate transaction costs. {% hint style="info" %} Weight is used to describe the time it takes to validate a block by controlling the execution time that a block can consume. Each extrinsic has its own way of calculating weight and it can be constant or dynamic. {% endhint %} Each EVM operation has its own associated weight which is then used to calculate the gas fee EVM users need to pay. Even if different, Creditcoin’s implementation is designed to produce effectively identical results to Ethereum’s mainnet. Note: although Creditcoin employs a distinct approach to transaction fees and gas mechanisms, it remains compatible with the same range of transaction types as Ethereum, including those defined by EIP-1559 and potentially any new types introduced in the future (unless explicitly indicated otherwise). #### Consensus Creditcoin’s EVM implementation does not have its own consensus mechanism; it relies Creditcoin’s Nominated Proof-of-Stake system for block production and finalization. Currently, EVM accounts cannot participate in staking as it requires interacting directly with the Substrate side of the blockchain. # Smart Contract Guides ### Smart Contracts Creditcoin is a Substrate-based chain like its sibling CC Enterprise, but it includes an EVM-compatible layer called Frontier. This allows users to run EVM smart contracts natively on Creditcoin and also provides the same RPC endpoints an EVM chain would to support tools and wallets such as MetaMask, Remix, Hardhat & Foundry. Smart contracts are self-executing contracts with the terms of the agreement directly written into code. On the Creditcoin blockchain, these contracts are commonly written in a programming language called Solidity and are executed on the Ethereum Virtual Machine (EVM) included in the Creditcoin runtime. The EVM provides a secure and deterministic execution environment for smart contracts. Every node on the Creditcoin network runs a copy of the EVM, ensuring that smart contracts behave consistently across all nodes. ### Start developing on Creditcoin * [Connecting local node to Metamask](/wallets/how-to-connect-your-wallet-to-creditcoin/metamask) * [EVM accounts & wallets](/wallets/advanced/substrate-and-evm-accounts) * [Creditcoin endpoints](/smart-contract-guides/creditcoin-endpoints) * [Deploying contracts with Remix](/smart-contract-guides/deploying-contracts-with-remix) * [Hardhat Smart Contract Development](/smart-contract-guides/hardhat-smart-contract-development) # Creditcoin Endpoints ### Mainnet 1. **Network Name**: Creditcoin 2. **RPC URL**: * **Via Websocket (for Polkadot.js)**: `wss://mainnet3.creditcoin.network` * **Via Https**: `https://mainnet3.creditcoin.network` 3. **Chain ID**: `102030` 4. **Currency Symbol**: CTC 5. **Block Explorer URL**: [`https://creditcoin.blockscout.com/`](https://creditcoin.blockscout.com/) ### Testnet 1. **Network Name**: Creditcoin Testnet 2. **RPC URL**: * **Via Websocket (for Polkadot.js)**: `wss://rpc.cc3-testnet.creditcoin.network` * **Via Https**: `https://rpc.cc3-testnet.creditcoin.network` 3. **Chain ID**: `102031` 4. **Currency Symbol**: CTC 5. **Block Explorer URL**: [`https://creditcoin-testnet.blockscout.com/`](https://creditcoin-testnet.blockscout.com/) ### Local {% hint style="info" %} Run a local Creditcoin development node by pulling and running the Docker image from the Gluwa repo: `docker run -p 9944:9944 gluwa/creditcoin3:3.130.0-testnet --dev --rpc-external` {% endhint %} 1. **Network Name**: Creditcoin Local 2. **RPC URL**: * **Via Websocket (for Polkadot.js)**: `wss://127.0.0.1:9944` * **Via Https**: `https://127.0.0.1:9944` 3. **Chain ID**: 42 4. **Currency Symbol**: CTC 5. **Block Explorer URL**: None # Deploying contracts with Remix **Prerequisites:** * **MetaMask**: Ensure you have MetaMask installed in your browser and have a Creditcoin EVM account set up with some CTC for gas fees. * **Remix**: Access the [Remix IDE](https://remix.ethereum.org/) #### Before starting * Ensure your MetaMask account is unlocked and has sufficient CTC to cover gas fees for the deployment. * Always review the gas fees and transaction details before confirming transactions in MetaMask. * Make sure you're deploying the correct contract and verify its functionalities before using it in a production environment. **Step 1: Write or Import Your Smart Contract** 1. Open Remix in your browser. 2. Create a new file or import an existing smart contract code (Solidity). You may use the following `Counter.sol` contract: ``` // SPDX-License-Identifier: MIT pragma solidity ^0.8.4; contract TestCounter { int private count = 0; function incrementCounter() public { count += 1; } function decrementCounter() public { count -= 1; } function getCount() public view returns (int) { return count; } } ``` **Step 2: Selecting the Compiler** 1. In Remix, navigate to the "Solidity Compiler" tab on the left-hand side.
2. Ensure the correct version of the Solidity compiler is selected for your smart contract by checking the compiler version is equal to or newer than the version stated in the `pragma` line. 3. Compile your smart contract code by clicking on the "Compile" button. **Step 3: Deploying the Smart Contract** 1. Go to the "Deploy & Run Transactions" tab in Remix.
2. From the Environment dropdown, select "Injected Web3" to connect Remix to MetaMask. **Step 4: Connect MetaMask** 1. MetaMask will prompt you to connect your account when you select "Injected Web3." Click "Connect" to establish the connection. 2. Confirm the connection by selecting the Ethereum account you want to use for deploying the smart contract. **Step 5: Deploy Your Smart Contract** 1. Under the "Deploy & Run Transactions" tab, you'll see your compiled contract displayed. 2. Find the contract you want to deploy and click on the blue "Deploy" button. 3. MetaMask will open and prompt you to confirm the transaction. Review the gas fees and click "Confirm" to deploy the contract. 4. Wait for the transaction to be confirmed on the Ethereum network. Once confirmed, your contract will be deployed, and Remix will display the contract's address. **Step 6: Interact with Your Deployed Contract** 1. Remix will provide you with the deployed contract's address. You can use this address to interact with your smart contract. 2. Utilize Remix's interface to interact with the contract, executing its functions, and observing state changes. # Hardhat Smart Contract Development #### Prerequisites * MetaMask installed & connected to a local Creditcoin node or public testnet * A funded account * Node.js & NPM installed #### Setting up Hardhat To create a Hardhat project you must initialize a node project using `npm`. Navigate to the folder where you want to build your project and run: ``` npx hardhat init ``` If you don’t have Hardhat installed globally, you’ll be prompted to do so. Follow the prompts to set up your project. You can choose options like creating a sample project or starting an empty project. For this tutorial, we will crate a TypeScript project. #### Writing your first contract For this tutorial we will use a simple Counter contract. Copy the contents of into `contracts/Counter.sol` inside the directory of your Hardhat project. #### Compiling Before you can deploy or test your contract you need to compile it. Run the command: ``` npx hardhat compile ``` #### Testing Before you deploy the contract, you want to make sure it works as expected. You can use Hardhat to write and run some tests for the Counter contract. Copy the contents of into `test/Counter.ts` inside the directory of your Hardhat project. Test the contract by running the command ``` npx hardhat test ``` You should see output similar to: ``` $ npx hardhat test Counter contract ✔ Should be deployed with the initial value 0 ✔ Should increment count by 1 Lock Deployment ✔ Should set the right unlockTime ✔ Should set the right owner ✔ Should receive and store the funds to lock ✔ Should fail if the unlockTime is not in the future Withdrawals Validations ✔ Should revert with the right error if called too soon ✔ Should revert with the right error if called from another account ✔ Shouldn't fail if the unlockTime has arrived and the owner calls it Events ✔ Should emit an event on withdrawals Transfers ✔ Should transfer the funds to the owner 11 passing (492ms) ``` where *Counter contract* is the contract that you had just added and *Lock* is another contract which was automatically generated by the `hardhat init` command. To add more tests to the contract, add more `it` statements to its test file! #### Deploying a smart contract To deploy your contract, you will need to write an ignition module for Hardhat. Copy the contents of into `ignition/modules/Counter.ts` inside the directory of your Hardhat project! You can deploy the contract by running the command: ``` npx hardhat ignition deploy ignition/modules/Counter.ts --network ``` Without the `--network` flag, the deployment will run against the local Hardhat Network, which means it gets lost after the command finishes running. But it is useful for testing that your ignition module works. ``` $ npx hardhat ignition deploy ignition/modules/Counter.ts You are running Hardhat Ignition against an in-process instance of Hardhat Network. This will execute the deployment, but the results will be lost. You can use --network to deploy to a different network. Hardhat Ignition 🚀 Deploying [ CounterModule ] Batch #1 Executed CounterModule#Counter [ CounterModule ] successfully deployed 🚀 Deployed Addresses CounterModule#Counter - 0x5FbDB2315678afecb367f032d93F642f64180aa3 ``` To deploy the contract to a remote network, you will need to define that network inside the `hardhat.config.ts` file. See for example and In this example we will use Creditcoin Testnet. {% hint style="warning" %} Avoid at all costs hard-coding credentials into source code. Use the `vars.get` method in combination with the `vars set` Hardhat command to set them up in a safe way. You can also use environment variables prefixed with `HARDHAT_VAR_` to override the values of configuration variables. For example: `HARDHAT_VAR_CC3TEST_PRIVATE_KEY=123...` {% endhint %} Once you have updated `hardhat.config.ts` you will then need to set the private key of your EVM account by running the Hardhat `vars set` command: ``` $ npx hardhat vars set CC3TEST_PRIVATE_KEY ✔ Enter value: ******************************** ``` After setting up the new config, run the command: ``` npx hardhat ignition deploy ignition/modules/Counter.ts --network creditcoin_testnet ``` #### More information Please refer to the official documentation of Hardhat at for more information. # Creating Dapps with ethers.js We will now create a front-end web application for the Counter contract we deployed in the previous sections using `ethers`, a JavaScript library for interacting with the EVM. #### Setting up an Ethers project {% hint style="warning" %} It is generally better practice (for security reasons) to copy the [ethers library](https://cdnjs.cloudflare.com/ajax/libs/ethers/6.7.0/ethers.min.js) to your own webserver and serve it yourself. More over, third party libraries should be monitored and updated regularly to avoid attacks involving supply chain vulnerabilities. Fixing the library’s version and using tools like [Github’s Dependabot](https://github.com/dependabot) and its [security updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates) can help developers keep their dependencies updated and their dApps safe. {% endhint %} Our web application will have a single HTML file, however it needs to be served via an HTTP server to avoid Cross-Origin Resource Sharing restrictions in modern browsers. **Loading the application via the `file://` protocol will not work!** The easiest way to start is to copy the entire project from and then execute the command: ``` $ npm install ``` After all dependencies have been installed you can serve the HTML application via the command ``` $ npm run dev > creditcoin-etherjs-project@0.0.0 dev > vite Re-optimizing dependencies because lockfile has changed VITE v5.2.12 ready in 95 ms ➜ Local: http://localhost:5173/ ➜ Network: use --host to expose ➜ press h + enter to show help ``` #### Connecting to the EVM **Adding the Contract details to the project** To create a contract instance, `ethers` requires the contract address and its Application Binary Interface (ABI). You can get both from either Remix or the Hardhat project. If you are using Remix, the ABI will be avaiblable to copy and paste after compiling the contract. And the address can be copied from the Deployed Contracts section in the Deploy & Run tab.

Contract ABI

Contract Address

If you are using Hardhat, you can use the address logged by the deploy command and the ABI code that should be stored in the `artifacts` folder as `Counter.json`. Include both the address and the ABI in the `script.js` file. {% hint style="warning" %} Important: when using **ethers.js** to interact with **Metamask**, different version of ethers.js requires different ways to initialize providers. The included example uses the latest **ethers.js v6!** {% endhint %} #### Items to be aware of When using the example project as the start of your own application you should be aware of several lines in the example source code and adjust them accordingly. They are annotated below: ``` // WARNING: this only works if you are compiling the Counter contract with Hardhat // adjust the artifact/ABI json if necessary! import CounterContractArtifact from "../with-hardhat/artifacts/contracts/Counter.sol/Counter.json"; // WARNING: this address depends on which chain the contract was deployed to const CounterContractAddress = "CHANGE_TO_REAL_DEPLOYMENT_ADDRESS"; ... skip ... const result = await window.ethereum.request({ method: "wallet_addEthereumChain", // WARNING: make sure this is the same blockchain the contract was deployed to params: [blockchainTarget.creditcoin_testnet] }); ``` # Attestcoin Protocol Description of the Attestcoin Protocol, which acts a cross-chain interoperability hub hosted on Creditcoin In today’s interconnected world, institutions and applications are no longer confined to a single blockchain. Value, data, and users are distributed across many networks, but connecting them securely has remained challenging. The most common solution has been to rely on centralized oracles and bridges, but doing so undermines the very principles that make blockchains trustworthy in the first place. By placing trust in a single oracle operator, institutions expose themselves and their clients to a single point of failure. In such a system, funds can be stolen and data can be falsified. The diagram below illustrates how a centralized oracle concentrates power and risk in one place.
The Attestcoin Protocol acts as a cross-chain interoperability hub with its own **decentralized oracle infrastructure**. With Attestcoin, smart contracts on `Creditcoin` gain the ability to read from, and write to, any supported chain. Attestcoin Protocol solves the problem of cross-chain communication by eliminating the single point of failure: instead of relying on one trusted party that could corrupt or falsify data, trust is distributed across multiple independent parties, none of which can unilaterally manipulate the results. The result is institutional-grade security for third-party cross-chain apps and services.
On the Creditcoin network, apps and services use **Attestcoin Smart Contracts (ASC)**, contracts that interact with the **Attestcoin Protocol**, to execute business logic spanning any number of chains. Operating across many chains simultaneously integrates their isolated pools of information and capital, opening up new powerful business use cases.\ \ This video provides a comprehensive first look into the Attestcoin Protocol (formerly called USC): {% file src="/files/QyqsMzGI5MYGTG1K4BVW" %} * **Cross-chain DeFi:** * Automating lending, borrowing, trading, and yield farming *without intermediaries*. * Creating and managing cryptocurrencies, `NFT`s, and fractional ownership of real-world assets. * Facilitating *trustless*, automated payments and conditional fund transfers. * **Gaming and Metaverse:** * Powering in-game economies, item ownership, and where appropriate, the gamification of real world interactions. * This is a powerful tool to influence community conscious decision making via incentivisation and fun! * **Voting and Governance:** * Allowing communities to easily establish and interact with novel democratic systems. * Contracts can leverage digital identity and the public, immutable ledgers of blockchains to make these systems more secure and truthful than ever before. All of these uses for blockchain become more powerful when data and liquidity across many chains are usable in one place ## **Current Attestcoin Protocol Oracle Capacity** * Verification completes in one block (\~15 seconds): Once a source chain (EX: Ethereum) block is finalized and attested on Creditcoin, the Attestcoin Protocol's block prover precompile can validate transactions from that block synchronously. Within the span of a single Creditcoin block, a foreign transaction can be validated, decoded, and used in dApp contract execution. * Batch query verification supports up to 10 queries which share a continuity proof. # Architecture Highest level description of the inner workings of the Attestcoin Protocol A *decentralized oracle* is a provider of information external to a blockchain that does not rely on a centralized trusted entity for its security. Instead, each step in the oracle’s data provisioning process is executed by a group of independent actors, none of which have the power to unilaterally interfere with data provisioning outcomes. The Attestcoin Protocol adds native decentralized oracle capacity to Creditcoin, which enables smart contracts that can access the state of *any* blockchain. These smart contracts, known as **Attestcoin Smart Contracts** (ASCs), enable novel cross-chain applications that can react to verified events from other chains. ## **Attestcoin Protocol Key Terms** * **Readability:** The process by which the Attestcoin Protocol reads data from another blockchain and exposes it for use in smart contracts on Creditcoin. Events, prices, whatever a contract needs to see. * **Writability:** The process by which the Attestcoin Protocol sends messages to other blockchains. With writability, a contract on Creditcoin can send messages containing critical data to a destination chain and trigger actions based on that data. * **Attestcoin Smart Contract (ASC):** A smart contract on Creditcoin that uses Attestcoin Protocol's readability or writability process. * **Source chain:** A chain from which data is read using Attestcoin readability. We begin by first supporting `EVM` chains such as `Ethereum`, with the eventual goal to enable data provisioning from any chain. * **Destination chain:** A chain to which messages are sent using Attestcoin Protocol's writability * **Creditcoin chain:** Creditcoin mainnet, testnet, or devnet. All these chains have Attestcoin Protocol infrastructure and Attestcoin Smart Contract support. * **Attestation:** A cryptographic commitment to data from source chain blocks, validated through consensus. * **Query:** A request to verify a transaction from a source chain on Creditcoin using readability. Each query specifies which source *chain*, *block number*, and *transaction* it wants to be verified. Once a transaction is verified, the dApp's attestcoin smart contract can extract the data it needs from the verified transaction bytes. * **Proof:** A cryptographic proof certifying that a given transaction occurred on a source chain. > Proofs consist of Merkle proofs (for transaction inclusion) and continuity proofs (for block chain integrity). These are verified at native speeds on Creditcoin. After verification, dApp contracts can extract relevant transaction data directly from verified transaction bytes. * **Block Prover Precompile:** A native precompile on Creditcoin (address `0x0FD2`) that verifies queries at native speed. It verifies transaction inclusion and block inclusion using Merkle proofs and continuity proofs. See below for details. The block prover precompile ***does not*** validate if a transaction was successful or not. It only validates if a transaction is included in a block and that block is really a part of the confirmed source chain. Therefore, a dApp's attestcoin smart contract **MUST** check the "status" field of the transaction to ensure security `0x1` → ✅ **Success** ## Architecture The Attestcoin Protocol relies primarily on the following actors: ### Attestors **Role in Readability** These make assertions about their view of the latest state of a source chain, such as Ethereum. Creditcoin doesn't trust any single attestor's report about changes to a source chain's state. Instead, a decentralized network of attestors must reach consensus on what state changes, if any, have occurred. This consensus is provided as an aggregated signature of individual attestor votes that can be verified by Creditcoin validators. **Role in Writability** In writability, attestors play the mirror-image role: instead of verifying facts coming *from* other chains, they validate messages going *to* them. When a contract on Creditcoin publishes a cross-chain message through an Outbox contract, attestors observe the message and then vote to validate it. Once a consensus threshold of signatures is met, the message is considered validated and can be carried to the destination chain. > For more information on attestors, check out the [Step 1: Attestation](/attestcoin-protocol/attestcoin-readability/step-1-attestation) section of the docs. ### Validators These form the authority set of the Creditcoin blockchain. Validators receive attestation transactions, perform basic structural checks, and include them in blocks through consensus. The runtime (executed by validators) verifies attestor BLS signatures and checks that sufficient quorum has been reached before committing attestations to on-chain storage. ### Block Prover Precompile The block prover precompile is a runtime component at address `0x0FD2` that supports Attestcoin Protocol's readability by verifying cross-chain data within Creditcoin transactions. It validates two proofs: a Merkle proof for transaction inclusion in a block, and a continuity proof linking that block to an on-chain attestation or checkpoint via a chain of block digests. The precompile runs as compiled Rust code, avoiding EVM interpretation overhead. Verification is synchronous: given transaction data, a Merkle proof, and a continuity proof, it checks that the Merkle root matches the block in the continuity chain, that the chain ends at a valid attestation/checkpoint, and that block digests are correctly linked via cryptographic hashing. Two functions are available: `verify()` (only view, no events) and `verifyAndEmit()` (state-changing, emits `TransactionVerified` events). ASC contracts use this to verify cross-chain events and transactions in a single transaction, replacing external proof systems and off-chain services. ### Message Relayers **Role in Writability** These carry validated messages from Creditcoin to their destination chains. A relayer listens to the attestor P2P network for messages that have reached the consensus signature threshold. Then the relayer delivers each message, along with its collected attestor votes, to an Inbox contract on the destination chain. Relayers are not part of consensus and never vote. Because any tampering would break the attestor signatures checked at the Inbox, a relayer cannot forge, alter, or misroute a message, only deliver it. The role is permissionless: anyone can operate a relayer, no bond is required, and relayers earn a delivery fee for each message they carry. **Role in Readability** Relayers can also serve the readability path, generating and submitting transaction proofs on behalf of dApps that prefer not to run their own infrastructure. ## Outcome for Builders **Readability** The net effect of readability is that third-party builders can create contracts on Creditcoin which have secure, trustless access to verified data from other chains. Attestcoin smart contracts can verify that specific transactions occurred on external blockchains (like Ethereum) and then react to those verified events by executing business logic on Creditcoin. For example, a bridge contract could: * Verify that a user burned or locked up ETH on Ethereum (by verifying the burn transaction using the precompile) * Based on that verified proof, mint equivalent wrapped tokens on Creditcoin Builders can leverage these properties to create attestcoin smart contracts which support their own custom cross-chain DApp business logic, enabling trustless cross-chain applications without relying on centralized oracles or intermediaries. **Writability** The net effect of writability is that Attestcoin Smart Contracts can act beyond Creditcoin: a contract can publish a message that, once validated by attestors, is delivered to a contract on a destination chain and triggers execution there. Builders get verified outbound reach without deploying bridge infrastructure of their own. Continuing our bridge contract example, with writability the bridge contract could: * Send a writability message declaring that wrapped ETH tokens were burned by a user * Receive the signed and verified message on Ethereum, releasing the original locked ETH to the user Combined with readability, this closes the information loop: builders can prove inbound events, act on them, send verified instructions back out, and even receive delivery confirmation. > For more information on how to set up your dApp's logic to leverage the Attestcoin protocol, check out the [dApp Builder Infrastructure](/attestcoin-protocol/dapp-builder-infrastructure) section of the docs. #### Conclusion With readability and writability, the Attestcoin Protocol connects Attestcoin Smart Contracts (ASC) to a growing network of blockchains. With full bi-directional data flows, these contracts seamlessly integrate functionality and liquidity from many chains in one place. This makes the Attestcoin Protocol a cross-chain communication hub with network effects that grow with each connected chain. # Attestcoin Readability Attestcoin Protocol's readability allows Creditcoin users and contracts to read the state of any source chain. Readability relies on two key steps: 1. **Attestation** - Proactively tracking and reaching consensus on the state changes of source blockchains. 2. **Transaction Proving** - Once a user/builder has decided they want to read a piece of source chain data, the transaction containing that data must be proven. To save on-chain compute, we generate proofs off-chain then verify them on-chain. Then data from the proven transaction can be used to by smart contracts on Creditcoin. With these two steps, Creditcoin contracts can connect to many previously isolated pools of data and liquidity. ## **Attestcoin Protocol's Readability Breakdown** The diagram below depicts how the Attestcoin Protocol provides data from source *chains* to Attestcoin Smart Contracts on Creditcoin. {% hint style="info" %} This diagram uses some old terminology and is pending replacement. The term Creditcoin Decentralized Oracle below would now be called "Attestation chain & Block Prover Precompile" {% endhint %}
The diagram above illustrates the cross-chain movement of data using Attestcoin Protocol's readability. ### **Provisioning Steps** * 1-2. Attestors listen for new source chain blocks, vote on attestations, and store those attestations on-chain. These are used later by the Block Prover Precompile to prove source chain transactions. * 3a. Meanwhile, dApp builders listen for the emission of events on the source chain which are relevant to their dApp. * 3b. When an event is detected, dApp builders send a request to the proof generation server asking for proofs of the transaction containing the target event. * 3c. The transaction and proofs are submitted to a dApp's Attestcoin Smart Contract, which forwards them to the Block Prover Precompile. * 4\. The Block Prover Precompile verifies merkle and continuity proofs, signaling whether or not the source chain transaction is valid * 5\. The dApp's Attestcoin Smart Contract decodes the verified transaction, extracting the relevant event. It then uses the event to trigger dApp logic and emit events. ## **Attestcoin Protocol's Readability Example Use Case** The following diagram demonstrates use of the Attestcoin Protocol (formerly called USC) to power cross-chain loans:
Red arrows represent the attestation process. Blue arrows represent the proving process which generates proofs for queries that are then verified synchronously by the Block Prover Precompile. # Step 1: Attestation Attestcoin Protocol Readability Step 1: The attestation subsystem of readability achieves consensus about the confirmed state of a foreign chain and records that consensus on Creditcoin. ## **Introduction** Attestation is the process by which the Attestcoin Protocol keeps track of the confirmed state of source chains. This is the first of two critical steps for Attestcoin Protocol's readability process. State transitions of each source chain are monitored by a decentralized network of attestors. Each eligible attestor creates an attestation, a cryptographic commitment showing its view of new blocks on the source chain and signs it with a BLS signature. Since no single attestor can be fully trusted, we require consensus among independent attestors, achieved through a P2P gossip network that aggregates votes and signatures offline before submitting them on Creditcoin. ## **Attestation Process** The attestation process is outlined below:
1. Attestors constantly monitor the source chain for new finalized blocks. 2. Periodically, Attestors summarize the new blocks they've seen in an attestation. The new blocks are organized as a chain segment, so that block hashes link from finalized attestation `n` to the new attestation `n + 1`. Eligible Attestors sign their respective attestation votes with BLS signatures and submit them to the P2P gossip network. 3. The off-chain P2P gossip network coordinates the attestation votes, validates them, and aggregates the BLS signatures. 4. Once a quorum of votes for an attestation is reached, any attestor in the active set is free to submit the consensus attestation along with attestor votes on-chain 5. The Creditcoin Validators then verify the aggregated votes (including Attestor eligibility and the aggregated BLS signature), verify the attestation's continuity chain of hashes, and store the attestation on-chain if valid. This approach reduces on-chain traffic by consolidating multiple attestor votes into a single transaction with a single aggregated signature, enabling efficient scaling to larger Attestor networks. The following diagram provides a visualization of this process:
# Continuity Proving for Attestation Continuity proofs make it possible to efficiently verify data from any block on a source chain. Without continuity proofs we would need to run 10-100x more consensus votes and store 100x more data. A continuity proof is one of two key proofs needed by Attestcoin Protocol Readability to securely move data from one chain to another. It organizes source chain blocks into a segment so that each block hash links to the next. Together these hashes/digests ensure that attestation `n + 1` is always a valid descendant of attestation `n` Why do we need continuity proofs? Why can't attestors simply record consensus about every block? The answer has two parts: 1. **On-chain Storage:** Storing attestations for every source chain block on our Creditcoin chain would be too expensive, especially for chains like `Solana` that produce blocks frequently. 2. **Attestor Network Load:** The Attestor network must perform expensive signing, hashing, p2p gossip, and tx submission for every attestation it produces. We make the Attestor networks more resilient and efficient by not attesting to every block. To solve both problems, we produce attestations at larger intervals (e.g., every 10 or 100 source chain blocks). Each attestation links to the previous one via digests. When there's a gap between attestations, a continuity proof fills it. This proof is a chain of digests of intermediate source chain blocks that: * Starts from the block immediately after the last finalized attestation * Ends at the block immediately before the new attestation * Proves each intermediate block links to the previous one via digests This lets the oracle handle queries for any source chain block—even if it wasn't explicitly stored—by proving continuity through the intermediate blocks. The continuity proof ensures that even though we only store attestations at intervals, we can still verify the integrity of the entire source chain. ## **Key Terms** * **Hash:** A cryptographic hash is a deterministic mathematical function that takes an input of arbitrary size and produces a fixed-size output, called a hash value. * **Merkle Tree**: A Merkle tree is a balanced binary tree of cryptographic hashes that enables efficient and secure verification of integrity of large data sets. \ \ With the tree’s Merkle root and a small subset of hashes (a Merkle proof), one can efficiently verify whether a given piece of data is included in the set without revealing or re-hashing all the data. This property allows us to efficiently determine whether a part of a transaction is contained in the Merkle tree for a given block. * **Root (Merkle Root)**: A Merkle root is the single cryptographic hash at the top of a Merkle tree. It uniquely summarizes all the data beneath it, allowing us to rapidly verify the integrity of all the data stored in that tree. Root in code: ```rust let root = eth::starknet_pedersen_mmr(&block_data); ``` * **Digest:** Another term for any output from a hash function. In the context of the Attestcoin Protocol, a digest usually describes the hash output uniquely identifying a block or attestation. The digest of a block is derived by hashing its block number, Merkle root, and previous digest. Digest in code: ```rust let digest = Self::hash_payload(&block_number.into(), &root, &prev_digest); ``` * **Previous Digest:** The previous digest of a block is just the digest of the block before it. We generate each new block digest using the previous digest. ## **How Hashing "Chains" Blocks Together** Continuity proving relies on one of the key properties of blockchains. Namely, that the digest of each block is generated using both the contents of that block and the digest of the previous block. Since each block uses part of the previous block, the blocks are said to form a *chain*. This gives us a very important property: > If the contents of block `x` are changed, then the digests of blocks `x, x+1, ... x+n` are *all changed* as a result. This allows us to cheaply verify whether any part of the chain was changed using only the most recent block. ## **Generating Attestations** An attestation is generated using the following process: ### 1. Determine which source chain blocks to attest to This is calculated as: ```rust let next_attestation_block = latest_attestation_block + attestation_interval; ``` The attestation interval determines how frequently attestations are created on Creditcoin relative to source chain blocks. For example, if the attestation interval for Ethereum is 10, a new attestation is produced on Creditcoin for every 10 blocks on Ethereum. More specifically, if the `attestation_interval` is `10` and the last attestation was at block `100`, attestors will fetch blocks `101-110` and generate new attestation at height `110`. ### 2. Fetch source chain blocks from source chain RPC nodes. Attestors either monitor the source chain directly or query an external trusted endpoint of their choice. As long as the attestor population represents a sufficiently diverse and distributed set of endpoints, rather than relying on just a few sources, it doesn't matter if individual attestors use external RPC endpoints. ### 3. Construct an attestation fragment Attestors fetch source chain blocks to build a continuity proof, a sequence of digests that bridges from one attestation to the next. As digests are added, each new digest is calculated as: ```rust let digest = Self::hash_payload(&block_number.into(), &root, &prev_digest); ``` Each block's digest integrates the previous block's digest, forming a verifiable chain. At the end, the new attestation's `prev_digest` is set to the digest of the continuity proof's head block. The attestation itself has its own digest, calculated from the attestation's `root` and `prev_digest`. This allows the attestation to be verified against the entire chain of intermediate digests, proving continuity even when blocks weren't explicitly stored. The following visual shows how digests bridge one attestation to the next.
### 4. Sign and submit to gossip network Each eligible attestor signs their attestation with both a *SR25519* signature (for attestor identity) and a *BLS* signature (for aggregation). The signed attestation (including the continuity proof) is then submitted to the P2P gossip network, where it is validated, coordinated with other Attestors' votes, and aggregated by other Attestors on that same network before on-chain submission. ## **Proving Continuity for Attestations** {% hint style="info" %} **Note:** Continuity proof generation for attestations differs from continuity proofs generated for queries (see [Continuity Proving for Queries](/attestcoin-protocol/attestcoin-readability/step-2-transaction-proving/continuity-proving-for-queries)). This section focuses specifically on attestation continuity proofs. {% endhint %} When generating attestations, Attestors construct a continuity proof chain linking blocks from the last finalized attestation (or checkpoint) to the current attestation height. The process: * Determines the interval endpoints by finding the last finalized attestation/checkpoint on-chain and identifying the current attestation height * Fetches source chain blocks between these endpoints and constructs the continuity proof. For attestations, the continuity proof starts from the block after the last finalized attestation and extends to the current attestation height * Computes block digests using the formula: `digest = hash(block_number, merkle_root, prev_digest)`, creating an unbroken cryptographic chain * Returns the continuity proof verifying that hashing was done correctly on the input blocks The attestation includes this continuity proof and a `prev_digest` field. For a continuity proof to be valid, the `prev_digest` of the prospective attestation must match the digest of the last continuity block. When the attestation is submitted to Creditcoin, the runtime verifies the validity of the continuity proof by reconstructing the digest chain and checking if the final digest matches the attestation's `prev_digest`. If verification succeeds, the attestation is stored on-chain. ### **Security** If a malicious attestor creates an internally consistent attestation with bogus blocks; the primary defense is consensus - since honest Attestors will not be using the bogus block, their final digest will be different, thus preventing the malicious attestation from reaching quorum. The following visual shows how a faulty attestation is rejected:
# Step 2: Transaction Proving Attestcoin Protocol Readability Step 2: The proving subsystem of Readability uses attestations and source chain blocks to prove that a particular transaction took place on a source chain. The query-prove-verify process enables Attestcoin Smart Contracts (ASC) to trustlessly verify and use data from source chains. The process consists of four main phases: 1. **Query Phase**: Identifying the target transaction for verification 2. **Proof Generation Phase**: Creating Merkle and continuity proofs 3. **Verification Phase**: Cryptographic verification of the proofs 4. **Data Extraction Phase**: Extracting transaction data from verified bytes ## **Proof Types** To prove that a transaction occurred on a source chain, the system uses two complementary cryptographic proofs: * **Merkle Proofs**: Prove that a specific transaction `x` is part of block `y` * **Continuity Proofs**: Prove that block `y` is part of the finalized source chain Together, these proofs provide cryptographic certainty that a transaction actually occurred on the source chain, enabling trustless cross-chain applications. Where are proofs generated, and where are they used? * **Prover Server** (off-chain): Generates Merkle and continuity proofs on-demand * [**Block Prover Precompile**](/attestcoin-protocol/architecture#native-query-verifier-precompile) (on-chain): Verifies proofs synchronously and extracts data ## Full Process Summary 1. A dApp team or end user identifies a target transaction they want to verify. This is usually done via a **Oracle Query Worker** that listens for source chain events and submits proving requests. Alternatively, for teams that don't want to stand up their own worker, paid 3rd party relayer submission of readability queries will be available in the near future. 2. The **Oracle Query Worker** requests proofs from the **Prover Server** via an endpoint like `proof-by-tx/{chain_key}/{tx_hash}` . 3. The **Prover Server** retrieves attestation data from Creditcoin and fetches source chain blocks. 4. The **Prover Server** then uses attestation and block data to construct a continuity proof and a merkle proof for the target tx. These proofs are returned to the **Oracle Query Worker.** 5. The **Oracle Query Worker** submits the target tx and its proofs to Creditcoin via a **Attestcoin Smart Contract** call. There, the tx and proofs are passed to the **Block Prover Precompile** 6. The **Block Prover Precompile** verifies both proofs synchronously, flagging whether the target tx is valid or invalid. 7. Once verified, the transaction data can be decoded and used for dApp business logic # Steps of Transaction Proving The transaction proving process enables Attestcoin Smart Contracts to trustlessly verify and use data from source chains. The process consists of four main phases: 1. **Query Phase**: Identifying the target transaction for verification 2. **Proof Generation Phase**: Creating Merkle and continuity proofs 3. **Verification Phase**: Cryptographic verification of the proofs 4. **Data Extraction Phase**: Extracting transaction data from verified bytes ## Transaction Proving Visualized {% @mermaid/diagram content=" sequenceDiagram participant User as Builder/User participant SourceChain as Source Chain participant ProofBuilder as Proof Builder Service box "Creditcoin (Runtime)" participant AttestationPallet as Attestation Pallet (Storage) participant USC as ASC Contract participant Precompile as Block Prover Precompile end Note over User,Precompile: Query Preparation Phase User->>SourceChain: 1. Fetch Block Data SourceChain-->>User: Block + Transaction Data User->>ProofGen: 2. Request Proofs Note over User,Precompile: Proof Generation ProofGen->>AttestationPallet: 3. Fetch Attestations/Checkpoints AttestationPallet-->>ProofGen: Attestation Data ProofGen->>SourceChain: 4. Fetch Source
Chain Blocks SourceChain-->>ProofGen: Block Headers ProofGen->>ProofGen: 5. Generate Merkle Proof ProofGen->>ProofGen: 6. Build Continuity Proof ProofGen-->>User: Merkle + Continuity Proofs User->>USC: 7. Submit cross-chain USC call Note over User,Precompile: Verification Phase USC->>Precompile: 8. Call Precompile Precompile->>AttestationPallet: 9. Read Attestations/Checkpoints AttestationPallet-->>Precompile: Attestation Data Precompile->>Precompile: 10. Verify Continuity Chain,
Merkle Proof, Query Block Digest Precompile-->>USC: Return Result (bool + data) Note over User,Precompile: Data Extraction Phase USC->>USC: 11. Parse data and trigger business logic USC-->>User: Return result and emit events" %} ### **Phase 1: Query Phase** A query specifies what needs to be proven: * Source Chain: Which blockchain the transaction occurred on (identified by `chainKey`) * Block Height: Which block contains the transaction * Transaction: The specific transaction to verify (identified by transaction index or hash) Example: "Prove that transaction at index 5 in block 18,000,000 on Ethereum mainnet actually occurred." This query information is used to: * Retrieve transaction data from the source chain * Determine which source chain blocks need to be fetched * Identify which attestations are needed for continuity proof ### **Phase 2: Proof Building Phase** The Proof Builder service creates two complementary proofs that together prove the transaction is legitimate. #### **2.1 Generating Merkle Proofs** The service then requests the block at the specified height from a source chain RPC node. All transactions in the block are hashed to form a Merkle tree, with the Merkle root stored in the block header. The Merkle proof consists of: * The Merkle root (from block header) * Array of sibling hashes with position information * The transaction bytes themselves By providing the sibling hashes and the transaction bytes, anyone can reconstruct the path to the Merkle root. If the computed root matches the block header's root, the transaction is proven to be in that block. #### **2.2 Generating Continuity Proofs** Finally the service then takes our query block height and determines that query's attestation bounds. Attestation bounds consist of the closest attestations above and below the query block height. Next, the server fetches all the source chain blocks between our lower and upper attestation bounds. These blocks are used to form a continuity proof as detailed in our next section, [Continuity Proving for Queries](/attestcoin-protocol/attestcoin-readability/step-2-transaction-proving/continuity-proving-for-queries) Now that both proofs have been generated, our Proof Builder returns the following: * Merkle Proof: Proves transaction inclusion in a block * Continuity Proof: Proves the block is part of the finalized source chain * Encoded Transaction: The full transaction bytes (transaction + receipt data) These three components together provide complete cryptographic proof that the transaction occurred on the source chain. ### **Phase 3: Verification Phase** The off-chain worker (or user) calls the ASC contract function with the proofs and encoded transaction bytes. The ASC contract then calls the native query verifier precompile to verify the proofs. #### **3.1 Merkle Proof Verification process:** * Start with: `leafHash = hash(transaction_bytes)` * For each sibling: combine with sibling hash (left or right based on position) * Final step: Check `computedRoot == merkleRoot` (from continuity proof roots array) #### **3.2 Continuity Proof Verification process:** * Starting from the back of the continuity chain, compute the following for each block: `computedDigest = hash(block_number, merkleRoot, previousDigest)` * Final step: Verify that `finalDigest == onChainAttestationDigest` The verification happens synchronously in the same transaction execution. * No Waiting: Results are available within seconds * Atomic: Either all verification steps succeed (transaction continues) or all fail (transaction reverts) * No Intermediate State: No query storage, no async processing, no waiting for finalization ASC contracts can use verified data immediately in the same transaction, enabling complex cross-chain logic without multi-step async flows. ### **Phase 4: Data Extraction Phase** After verification succeeds, the ASC contract extracts the data it needs from the verified transaction bytes. The `encodedTransaction` bytes contain the full transaction data. It can be used to decode the transaction type, common fields, type-specific fields and the receipt fields. Once data is extracted, the ASC contract: * Validates the extracted data (e.g., receipt status = success, expected event found) * Executes business logic based on the verified cross-chain data * Updates contract state or triggers additional actions **Example**: A bridge contract might: 1. Verify a `Transfer` event showing tokens were burned on Ethereum 2. Extract the `from`, `to`, and `value` from the event 3. Mint equivalent tokens on Creditcoin to the `to` address # Continuity Proving for Queries Attestcoin Protocol Readability uses Continuity proving to efficiently determine whether a given block is part of a source chain. It is the first of two key proofs that certify readability data. Continuity proofs for queries are cryptographic proofs that link the queried source chain block to an on-chain attestation or checkpoint, establishing that the block is part of the finalized source chain. This is one of the two essential proving steps used by the Attestcoin Protocol to achieve trustless cross-chain data readability. {% hint style="info" %} **Note:** Continuity proof generation for queries differs from continuity proofs used in attestation generation (see [Continuity Proving for Attestation](/attestcoin-protocol/attestcoin-readability/step-1-attestation/continuity-proving-for-attestation)). This section focuses specifically on query continuity proofs. {% endhint %} ## **Continuity Proof** A continuity proof for a query cryptographically links the queried block to an attestation or checkpoint stored on Creditcoin. The proof structure contains: * **`lowerEndpointDigest`**: The digest of the block before the query (`queryHeight - 1`), retrieved from indexed attestation data on Creditcoin * **`roots[]`**: An array of Merkle roots for blocks from `queryHeight` to the attestation/checkpoint block Digests are computed on-chain from these roots using this formula, which creates an unbroken cryptographic chain: `digest[i] = hash(blockNumber[i], merkleRoot[i], digest[i-1])` ## **Why Query Continuity Proofs Are Needed** If queries didn't contain continuity proofs, there would be no way to link them to on-chain attestations. We therefore couldn't verify which queries correspond to legitimate source chain data. Malicious queries could: * Present fake Merkle roots for non-existent blocks * Claim transactions exist in blocks that were never finalized * Use outdated or reorganized blocks ## Attestations vs Checkpoints Two goals of Attestcoin Protocol Readability are as follows: 1. Allow contracts on Creditcoin to read data from new blocks on source chains as quickly as possible. 2. Minimize the long term storage footprint of the attestation protocol which enables readability In order to accomplish these two goals, attestation record storage on Creditcoin is broken into two pieces. 1. **Attestations**: Records of recent confirmed source chain blocks. New attestations corresponding to the latest source chain blocks are produced frequently (every two minutes for Ethereum) 2. **Checkpoints**: More sparse records covering historical source chain blocks. Checkpoints are produced less frequently (every 20 minutes for Ethereum) and take up much less storage space than attestations. When a checkpoint is produced, it replaces a large number of attestations, removing them from storage. The Proof Builder service can generate continuity proofs using either attestations or checkpoints. It queries indexed data stored on Creditcoin (attestations and checkpoints) and constructs the continuity proof using the computed roots and digests from this indexed data. ## **Continuity Proof Construction** When an off-chain worker needs to query a transaction at a specific block height, the service constructs a continuity proof through the following steps: ### **1. Determine Interval Endpoints** The service first identifies the attestation/checkpoint boundaries around the query: 1. **Find the Highest Attestation/Checkpoint Before the Query** * Queries indexed attestation/checkpoint data stored on Creditcoin * Identifies the most recent attestation or checkpoint with a block number less than `queryHeight` * Retrieves the computed digest from the indexed data to use as `lowerEndpointDigest` 2. **Find the Lowest Attestation/Checkpoint After the Query** * Queries indexed attestation/checkpoint data on Creditcoin for the earliest attestation or checkpoint with a block number greater than or equal to `queryHeight` * The proof must link to this attestation/checkpoint's digest * This serves as the upper endpoint of the continuity proof * For queries between checkpoints, this will be a checkpoint (ending in a checkpoint) **Example:** * Query height: 145 * Last attestation before query: Block 140 (digest: `0xabc...`) * Next attestation after query: Block 150 (digest: `0xdef...`) * Continuity proof must link blocks 145-150 to attestation at block 150 ### **2.** Query Indexed Data and **Fetch Source Chain Blocks** The service queries indexed attestation data on Creditcoin and fetches source chain blocks: 1. **Query Indexed Attestation Data:** * For queries between attestations: Retrieves the specific attestations from indexed data * For queries between checkpoints: Queries all attestations in the checkpoint interval range from indexed data * Uses the computed roots and digests from the indexed attestation data 2. **Fetch Block Headers** * Requests block headers from the source chain RPC node * Needs blocks from `queryHeight` to the next attestation/checkpoint block * Each block header contains: block number, Merkle root, previous block hash 3. **Verify Block Integrity** * Validates that blocks form a continuous chain * Ensures each block's `previousBlockHash` matches the previous block's hash * This ensures blocks haven't been tampered with or reorganized **Example (continuing from above):** * Queries indexed attestation data on Creditcoin for blocks 140-150 * Fetches blocks: 144, 145, 146, 147, 148, 149, 150 * Blocks 145-150 form the chain to the attestation ### **3. Construct Digest Chain** The service constructs the digest chain using the computed roots and digests from the indexed attestation data on Creditcoin: **Digest Calculation Formula:** ``` digest[i] = hash(blockNumber[i], merkleRoot[i], digest[i-1]) ``` Where: * `blockNumber[i]` is the block number (e.g., 145) * `merkleRoot[i]` is the Merkle root from the block header * `digest[i-1]` is the digest of the previous block **Process:** 1. Start with the digest of the block before the query (`queryHeight - 1`) * This digest should match the `prev_digest` from the attestation/checkpoint before the query * If no previous attestation exists, use genesis digest 2. For each block from `queryHeight` to the attestation/checkpoint block, compute using roots from indexed data: ``` digest[144] = hash(144, root[144], prev_digest_from_attestation) digest[145] = hash(145, root[145], digest[144]) digest[146] = hash(146, root[146], digest[145]) ... digest[150] = hash(150, root[150], digest[149]) ``` 3. The final digest (`digest[150]`) must match the digest stored in the indexed attestation/checkpoint data on Creditcoin at block 150. ### **4. Build Continuity Proof Structure** The continuity proof structure is simplified and only stores Merkle roots (digests are computed on-chain): **Continuity Proof Structure:** ```rust struct ContinuityProof { lowerEndpointDigest: bytes32, // Digest of block (queryHeight - 1) roots: bytes32[] // Array of Merkle roots } ``` * `lowerEndpointDigest`: The digest of the block before the query (`queryHeight - 1`) * This is the `prev_digest` that the first block in the continuity chain references * Must match the digest from the attestation/checkpoint before the query * `roots[]`: Array of Merkle roots for blocks from `queryHeight` to the attestation/checkpoint block * Block numbers are derived: `blockNumber = queryHeight + index` * Digests are computed on-chain from these roots (not submitted in proof) ## **Security** The fundamental security property of continuity proofs is the cascading effect of digest changes: If any block in the continuity proof is modified: 1. The digest of that block changes (because it includes the block's Merkle root) 2. All subsequent block digests change (because each digest includes the previous digest) 3. The final digest will not match the on-chain attestation/checkpoint digest 4. This mismatch can be detected during verification, causing the proof to be rejected **Example Attack Scenario:** ``` Attacker tries to modify block 147 in the continuity proof: - Original block 147: root = 0x111, digest = 0xAAA - Modified block 147: root = 0x222, digest = 0xBBB (changed!) This causes cascading changes: - Block 148: digest changes (uses 0xBBB instead of 0xAAA) - Block 149: digest changes (uses changed digest from 148) - Block 150: digest changes (uses changed digest from 149) Final digest ≠ On-chain attestation digest → Tampering detected ``` # Merkle Proving and Transaction Inclusion Attestcoin Protocol Readability uses Merkle proving to determine whether a transaction is included in a given block. It is the second of two key proofs that certify oracle results. > In case you aren't already familiar with Merkle proofs, :newspaper: [this article](https://medium.com/@swastika0015/merkle-proofs-explained-208a72971a50) should give you a basic understanding of their use in the context of blockchain. ## **Motivation** When checking whether a transaction is part of a given block, we can either look through all the transactions in that block or use a *Merkle proof*. Blocks can contain a very large number of transactions, so checking them one by one until we find the transaction we are looking for is *wildly* inefficient! When verifying a Merkle proof we only need to access `log₂(n)` hashes in a block with `n` transactions. This would be about 20 hashes for 1,000,000 transactions! A big difference. ## **Key Terms** * **Merkle Tree**: A balanced tree data structure of hashes used to efficiently verify the integrity of large sets of data. \ \ With the root of a Merkle tree and a small number of hashes from that tree, we can efficiently determine whether any given piece of data belongs to the set it describes. This property allows us to *efficiently* determine whether any transaction `T` is contained in a block `B` , where `B` might contain many such transactions. * **Root (Merkle Root)**: A Merkle root is the single cryptographic hash at the top of a Merkle tree, allowing us to rapidly verify the integrity of all the data stored in that tree. * **Field**: In this context, a field is a part of a blockchain transaction. For example, a field could be the transaction `status` (success/failure) or the `value` field of a transfer event emitted by that transaction. A dApp's Attestcoin Smart Contract extracts transaction data directly from verified transaction bytes. * **Standard Merkle Tree**: Attestcoin readability uses standard Merkle trees (*Keccak-256* hashing). Merkle proofs are verified natively by the precompile, providing fast and efficient verification without requiring specialized proof systems. ## **Merkle Proving Transaction Fields** In the example below, we show how fields containing the data we want are packed in transactions then hashed to form a Merkle tree. `Transaction 1`, as shown below, is an `ERC20` transfer. This implies it has fields such as `from`, `to`, and `value`. > Other fields have been excluded from this diagram for simplicity's sake. Note how the transaction fields we want to prove are all part of a single transaction, `T1`. Each transaction in the block is hashed to form a leaf node. These leaf nodes are then combined pairwise and hashed to form parent nodes, with this process continuing recursively until a single `root` hash is created. Using the hashes of each sibling node along the path to `T1` in combination with the Merkle root itself, we can prove that `T1` was part of this specific block. This is known as a 📰 [Merkle proof](https://medium.com/@swastika0015/merkle-proofs-explained-208a72971a50#c6a9). The Proof Builder service generates this Merkle proof and submits it (along with continuity proof) for verification to the native precompile, which verifies it by reconstructing the path from transaction to root. Once the precompile has verified the Merkle proof (confirming `T1` is included in the block), the transaction data is immediately available. ASC contracts can then decode the fields they need directly from `T1`.
# Gas Costs The on-chain verification of readability queries incurs normal gas costs for compute. We attempt to describe the scale and variance of those costs here. ## What Influences Verification Cost? 1. **Continuity Proof Length (Large effect):** For each block in a continuity proof, the Block Prover Precompile must perform a hashing operation to calculate a digest. All these hashing ops cost gas. For historical transactions, continuity proofs can be quite long (Eg: 1000 blocks). If you aren't already familiar with what a continuity proof is, see [continuity proving for queries](/attestcoin-protocol/attestcoin-readability/step-2-transaction-proving/continuity-proving-for-queries). 2. **Merkle Proof Size (Small effect):** Merkle proof size grows modestly as you increase the number of transactions in a block. For example: * 1024 tx block -> 11 hash merkle proof (1 to get leaf + 10 with siblings) * 1 tx block -> 1 hash merkle proof\ \ This will cause some modest fluctuation in gas costs, but isn't a large factor. 3. **Transaction Data Size:** While not strictly a part of the verification process, transaction decoding is still a necessary step for Attestcoin Readability. For almost all transactions the cost of decoding is negligable. But a few outliers make this cost potentially noteworthy. \ \ Transaction types to avoid: * A single transaction in which contracts circularly call each-other 1000's of times * Transactions which bundle state updates for layer 2 rollup chains\ \ If you do happen request verification and decoding of very large transactions repeatedly, then the cost will add up. Estimated cost for 1 maximal decoding workload is **0.0375 CTC**. ## Verification Gas Equation Below we provide a line of best fit equation which roughly estimates the gas cost of a query given the length of its continuity proof. ### Cost formula *Cost ≈ (base tx cost) + (hash op cost) · (continuity hash count)*
Based on it the approximate costs are: **CTC Cost ≈ 2.3×10****−5**** + 2.9×10****−7**** \* (continuity hash count)** ## Continuity Length Scenarios 1. Transaction which was finalized 10 minutes ago at height 10,870,001\ Because this transaction is recent, we have an attestation in storage at block 10,870,010. So continuity proof verification requires 10 hashing ops. \ \ This gives us the expected price: **2.59x10****−5**** CTC** 2. Same transaction as in the first case, but we've waited another 24 hours\ Now that we've waited for 1 day, the attestations in storage got replaced by more sparse checkpoints (1 per 1000 blocks). So continuity proof verification requires 1000 hashing ops. \ \ This gives us an expected price: **3.13×10****−4**** CTC**\ \ **That's more than 10x higher cost!**
## **Key Takeaways** * The cost of Attestcoin Protocol Readability is currently quite low, facilitating as much traffic as desired * To future proof against the potential of rising readability costs, try to make verification requests for transactions when they are recently finalized. This will reduce average continuity proof length by a factor of 10-100x. # Attestcoin Writability Attestcoin Protocol Writability allows Creditcoin users and contracts to send messages to any destination chain. These messages contain an arbitrary payload of data and trigger actions in the receiving contract. Writability has four simple steps: 1. **Message publishing -** A user or contract publishes a message to the outbox for their desired destination chain. Payment for delivery is submitted separately to a relayer contract. 2. **Message signing -** Attestors listen for new messages, wait for block finality per message on Creditcoin, then sign each message. The message is considered signed once a quorum of signatures (⅔ + 1) is reached. 3. **Message delivery -** Relayers listen to attestor P2P traffic and track signature counts. Once a message has a quorum of signatures, the relayer delivers both the message and its signatures to the destination chain via a call to its inbox contract. 4. **Message validation -** The inbox contract checks attestor signatures against the message it received. If the message was tampered with in any way, or if any signature doesn't correspond to a valid attestor, then this check fails. Validated message contents are then forwarded to the messages designated destination contract. There, data is unpacked and dApp specific logic is triggered. With these four steps Creditcoin contracts can interact with many previously isolated chains, connecting pools of functionality and liquidity. {% hint style="warning" %} Writability is undergoing 3rd party testing and audits. Once the writability feature is mature and released on Creditcoin testnet, additional details will be available in sub-pages here. {% endhint %} # dApp Builder Infrastructure Summarizes the infrastructure dApp builders must set up in order to effectively use the Attestcoin Protocol. {% hint style="danger" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} ## Infrastructure Components The Attestcoin Protocol is intended for use by dApp builders. However, in order to use the oracle *effectively* dApp teams will need to set up some infrastructure of their own. ### Source Chain Smart Contract > Deployed on source chain like `Ethereum`, `Sepolia` **What to implement:** A smart contract that supports the dApp's source chain logic and emits events that can be verified on Creditcoin. **Key requirements:** * Emit events with the data the dApp needs to verify * Events should be structured to allow easy extraction of relevant fields * Contract should handle any logic that must happen on the source chain (e.g., burning tokens) **Example:** To support a token bridge dApp the source chain smart contract might be an ERC20 contract that emits `TokensBurnedForBridging` events. ### Attestcoin Smart Contract (ASC) > Deployed on `Creditcoin` **What to implement:** A smart contract that verifies cross-chain transaction data using the Native Query Verifier Precompile (address `0x0FD2`) and then executes the dApp's business logic. **Key responsibilities:** * Receives proofs (Merkle and continuity) and encoded transaction data from workers via a smart contract call * Calls the Native Query Verifier Precompile on Creditcoin to verify proofs synchronously * Extracts transaction/event data from verified transaction bytes * Executes dApp Business Logic or calls separate business logic contract using the verified data **Example:** In a token bridge dApp, the ASC interprets oracle-provided data corresponding to the burn event on the source chain. ### dApp Business Logic Smart Contracts > Deployed to `Creditcoin` **What to implement:** One or more smart contracts that contain their dApp's state and business logic. **Contract organization:** dApp developers have flexibility in how they organize their code: * **Combined pattern**: ASC and business logic code can be kept in the same contract. This works well for simple use cases where the ASC contract directly implements the business logic (e.g., minting tokens). * **Separated pattern**: ASC and business logic can be kept in separate contracts. The ASC contract handles verification and then calls separate business logic contracts after verification succeeds. This pattern provides better modularity and is recommended for complex dApps. **Key responsibilities:** * Store dApp state (e.g., token balances, user data) * Implement dApp-specific logic (e.g., minting tokens, updating balances) * Provide functions that can be called by their ASC contract * Enforce access control (typically only allow calls from their ASC contract) **Example:** For a token bridge, this might be an ERC20 contract on Creditcoin that mints tokens when the ASC contract verifies a burn event from the source chain. **Integration pattern:** * Grant the ASC contract special permissions (e.g., minter role, admin role) * ASC contract calls business logic functions after verifying cross-chain data * Business logic contracts validate inputs and update state accordingly ### Readability Worker > Deployed :computer: `offchain` **What to implement:** An off-chain service that monitors source chain events and automatically submits verified transactions to their ASC contract. {% hint style="info" %} In the future Attestcoin relayers will offer a paid service to submit readability queries to dApp Attestcoin Smart Contracts. With this service, dApp teams can avoid standing up their own Oracle Workers, instead paying a small fee for query submission. {% endhint %} **Key responsibilities:** 1. Listen for events from the source Chain Smart Contract 2. Wait for the block containing the event to be attested on Creditcoin 3. Use the Proof Builder service to get Merkle and continuity proofs 4. Call the ASC contract with the proofs and encoded transaction data 5. Retry failed transactions, track processing status, prevent duplicates etc **Basic worker flow:** {% @mermaid/diagram content="flowchart LR A\["1. Detect Event"] --> B\["2. Wait for Attestation"] --> C\["3. Call Proof Builder"] --> D\["4. Receive Proofs"] --> E\["5. Call ASC"] --> F\["6. Verify & Execute"] " %} ## Complete Flow With all four components in place: 1. **User** signs transaction on source chain → emits event 2. **Oracle Worker** detects event → waits for attestation → fetches proofs → calls ASC 3. **ASC Contract** verifies proofs → extracts data → calls Business Logic Contract 4. **Business Logic Contract** executes dApp logic → updates state This enables seamless cross-chain interoperability where a transaction on one chain automatically triggers dApp logic execution on Creditcoin! # Source Chain Smart Contracts An overview of source chain smart contracts and the best practice pattern to securely query their data on Creditcoin using Attestcoin Protocol Readability. {% hint style="danger" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} ## What is a Source Chain Smart Contract? A source chain smart contract is a contract living on a source chain such as Ethereum Icon `Ethereum` that is supported by Attestcoin Protocol Readability. Source chain contracts have two main responsibilities: 1. Support any source chain logic required by their cross-chain dApp. 2. Emit events that contain the data their dApp needs to verify and process on Creditcoin Let's focus on these one by one. ### Source chain logic Most logic and data for cross-chain DApps should live in contracts on Creditcoin rather than the source chain. Keep source chain logic minimal—typically just enough to handle asset movements (e.g., burning tokens, locking assets) and emit events. **Best practices:** * Minimize source chain logic to reduce gas costs and complexity * Keep business logic on Creditcoin * So that data and liquidity from many chains can be used in one place * And to benefit from lower transaction + storage costs * Use source chain contracts primarily for emitting events that trigger cross-chain actions ### Emitting Events This is the way by which the source *chain* will communicate with Creditcoin. When a source chain contract emits an event, it becomes part of the transaction's receipt logs, which can be cryptographically verified on Creditcoin using Attestcoin Protocol Readability. Imagine that you want a simple dApp which burns ERC20 tokens on Ethereum and mints corresponding ERC20 tokens on Creditcoin. Then you would want your source chain smart contract to emit an event such as `TokensBurnedForBridging`. **Event design considerations:** * Use `indexed` parameters for efficient filtering (up to 3 indexed parameters) * Include all data the dApp needs in the event parameters * Keep event signatures consistent to simplify parsing in ASC contracts ### Example Source chain contract The following example shows a simple ERC20 contract that supports a token bridge dApp. When tokens are "burned" (transferred to a burn address), a custom `TokensBurnedForBridging` event is emitted, which can be verified on Creditcoin to trigger token minting. **Key features:** * Emits a custom `TokensBurnedForBridging` event for easy filtering by [offchain workers](/attestcoin-protocol/dapp-builder-infrastructure/offchain-readability-workers) * Uses a burn address (`0x...01`) to represent token burning * The `TokensBurnedForBridging` event includes all necessary data (`from`, `value`) * Workers can easily filter for this specific event signature and then generate proofs to submit to the ASC contract ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract TestERC20 is ERC20 { address public constant BURN_ADDRESS = address(1); // 0x...01 /// @notice Emitted when tokens are burned (sent to the burn address). /// @param from The address burning their tokens /// @param value The amount of tokens burned event TokensBurnedForBridging(address indexed from, uint256 value); constructor() ERC20("Burn Test", "TEST") { // Mint sender initial supply _mint(msg.sender, 1_000_000 ether); } /// @notice "Burn" by transferring tokens to the 0x...01 sink address. /// @dev This does NOT reduce totalSupply; it only makes tokens inaccessible. /// @param amount The amount of tokens to burn /// @return success Whether the transfer succeeded function burn(uint256 amount) external returns (bool) { _transfer(msg.sender, BURN_ADDRESS, amount); emit TokensBurnedForBridging(msg.sender, amount); return true; } } ``` # Attestcoin Smart Contracts {% hint style="danger" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} ## What is the Attestcoin Smart Contract? **Attestcoin Smart Contract (ASC):** A smart contract on Creditcoin that uses Attestcoin Protocol Readability or Writability. Unlike traditional omnichain or cross-chain solutions that focus narrowly on token transfers or specific assets, the Attestcoin Protocol provides a **general-purpose execution layer**. This enables contracts to act on externally verified data *without needing to rewrite core logic*. By adopting the Attestcoin Protocol into their tech stack, developers can transform their contracts into *universal* components powered by seamless cross-chain data, allowing for novel patterns of interoperability across multiple blockchains. ## Attestcoin Smart Contract Architecture ASCs verify cross-chain proofs and execute business logic. **DApp Business Logic Contracts** are contracts deployed on Creditcoin that contain the dApp's state and business logic. In the example implementation (`SimpleMinterASC`), the business logic (ERC20 token minting) is integrated directly into the ASC itself. While this combined pattern works well for simple use cases, for more complex dApps developers can separate concerns by deploying distinct contracts: * An Attestcoin smart contract that handles the core cross-chain read/write responsibilities * And separate business logic contracts that the ASC contract calls after verification succeeds. Both patterns are valid; the choice depends on the complexity and requirements of the dApp. ## How it works ASCs verify cross-chain transaction data using the **Block Prover Precompile** (address `0x0FD2`), a built-in runtime component that provides synchronous verification of Merkle and continuity proofs. ASCs integrate with it by calling its `verify()` (or alternatively `verifyAndEmit()` ) function directly to verify proofs before processing cross-chain data. Once a transaction is verified, the ASC extracts transaction and event data directly from the verified transaction bytes and executes dApp-specific business logic. **Key characteristics:** * **Synchronous verification**: Proofs are verified in the same transaction, no async processing * **Direct data extraction**: Transaction and event data is extracted directly from verified transaction bytes * **Replay protection**: ASCs implement mechanisms to prevent duplicate processing * **Native-speed execution**: The precompile runs as native Rust code for optimal performance {% hint style="danger" %} The block prover precompile ***does not*** validate if a transaction was successful or not. It only validates if a transaction is included in a block and that block is really a part of the confirmed source chain. Therefore, a dApp's ASC **MUST** check the "status" field of the transaction to ensure security `0x1` → ✅ **Success** {% endhint %} ## Core Attestcoin Smart Contract Pattern A typical ASC follows this pattern: 1. **Receives proofs and transaction data** from an off-chain worker 2. **Implements replay protection** to prevent duplicate processing 3. **Calls the Block Prover Precompile** to verify proofs synchronously 4. **Extracts transaction/event data** from verified transaction bytes 5. **Executes business logic** based on the verified data ### Example ASC Contract See [`ASCMinter.sol`](https://github.com/gluwa/usc-testnet-bridge-examples/blob/main/contracts/sol/USCMinter.sol) for a complete ASC implementation. The contract: * Receives proofs and transaction data from offchain worker * Implements replay protection using a `processedQueries` mapping * Uses the Block Prover Precompile to verify proofs * Validates transaction type and receipt status (must be successful) * Extracts event data from verified transaction bytes using `EvmV1Decoder` * Executes business logic (ERC20 token minting) within the same contract that mints tokens once a burn event is verified from the source chain **Key function signature:** ```solidity function mintFromQuery( uint64 chainKey, uint64 blockHeight, bytes calldata encodedTransaction, bytes32 merkleRoot, INativeQueryVerifier.MerkleProofEntry[] calldata siblings, bytes32 lowerEndpointDigest, bytes32[] calldata continuityRoots ) external returns (bool success) ``` ### dApp Business Logic Contracts dApp Business Logic Contracts are smart contracts deployed on Creditcoin that contain the dApp's state and business logic. In the example implementation (`SimpleMinterASC`), the business logic is integrated directly into the ASC. The contract: * Stores dApp state (e.g., token balances via ERC20) * Implements dApp-specific logic (e.g., minting tokens) * Executes business logic immediately after verifying cross-chain proofs and validating transaction contents * Validates inputs and updates state accordingly ### Transaction Data Extraction After verification succeeds, ASCs extract transaction and event data from the `encodedTransaction` bytes as part of the transaction content validation process. The transaction encoding follows a deterministic format that includes: * **Transaction fields**: Type, chain ID, nonce, from address, to address, value, etc. * **Receipt fields**: Status, gas used, logs (events) * **Event data**: Topics and data from transaction receipt logs ASCs can use libraries like `EvmV1Decoder` to selectively extract specific events or transaction fields only needed for their business logic. This selective extraction allows ASCs to efficiently validate specific events or transaction fields needed for their business logic without decoding the entire transaction structure. ### Query Processing Flow When an oracle query worker provides proof data for a source chain transaction: 1. **Worker generates proofs** using the Proof Builder service 2. **Worker calls ASC contract** with proofs and encoded transaction data 3. **ASC contract verifies proofs** synchronously using the Block Prover Precompile 4. **ASC contract extracts data** from verified transaction bytes 5. **ASC contract executes business logic** immediately in the same transaction All of this happens synchronously in a single transaction—there is no async query processing or result storage. ### Attestcoin Smart Contract Implementation Example The following sections break down a complete ASC implementation based on [`ASCMinter.sol`](https://github.com/gluwa/usc-testnet-bridge-examples/blob/main/contracts/sol/USCMinter.sol) {% hint style="danger" %} Since the creation of this article, the ASCMinter was updated to better reflect a production ready design. The minter responsibilities were split off into several contracts handling portions of the bridge token minting process. The code here, though not fit for production, more simply and succinctly demonstrates ASC design. So it remains unchanged. {% endhint %} #### Contract Structure {% hint style="info" %} The Block Prover Precompile was previously called Native Query Verifier, so you'll see that term throughout these code examples {% endhint %} ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.23; import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {EvmV1Decoder} from "./EvmV1Decoder.sol"; contract SimpleMinterASC is ERC20 { INativeQueryVerifier public immutable VERIFIER; mapping(bytes32 => bool) public processedQueries; // ... rest of contract } ``` **Key components:** * **Inherits from ERC20**: The contract uses the combined pattern—it's both an ASC (requests proof verification and decodes tx data) and a business logic contract (`ERC20` token with minting logic) * **VERIFIER**: Immutable reference to the Block Prover Precompile at address `0x0FD2` * **processedQueries**: Mapping for replay protection, preventing duplicate processing of the same transaction #### Main Entry Point: mintFromQuery ```solidity function mintFromQuery( uint64 chainKey, uint64 blockHeight, bytes calldata encodedTransaction, bytes32 merkleRoot, INativeQueryVerifier.MerkleProofEntry[] calldata siblings, bytes32 lowerEndpointDigest, bytes32[] calldata continuityRoots ) external returns (bool success) { // Calculate transaction index from merkle proof path uint256 transactionIndex = _calculateTransactionIndex(siblings); // Check if the query has already been processed bytes32 txKey; { assembly { let ptr := mload(0x40) mstore(ptr, chainKey) mstore(add(ptr, 32), shl(192, blockHeight)) mstore(add(ptr, 40), transactionIndex) txKey := keccak256(ptr, 72) } require(!processedQueries[txKey], "Query already processed"); } // First we verify the proof bool verified = _verifyProof( chainKey, blockHeight, encodedTransaction, merkleRoot, siblings, lowerEndpointDigest, continuityRoots ); require(verified, "Verification failed"); // Mark the query as processed processedQueries[txKey] = true; // Next we validate the transaction contents (bool valid, address burntFrom, uint256 burntValue) = _validateTransactionContents(encodedTransaction); require(valid, "Transaction contents validation failed"); // Execute business logic (mint tokens) corresponding to the burn on the source chain _mint(burntFrom, burntValue); emit TokensMinted(address(this), burntFrom, burntValue, txKey); return true; } ``` **Description:** * **Parameters**: Receives all proof components and transaction data from the off-chain worker * **Transaction Index Calculation**: Calculates the transaction index from the Merkle proof path using `_calculateTransactionIndex()` * **Transaction Key Generation**: Creates a unique key from `chainKey`, `blockHeight`, and `transactionIndex` using assembly for gas efficiency * **Replay Protection**: Checks if this transaction has already been processed * **Proof Verification**: Calls `_verifyProof()` to verify the Merkle and continuity proofs synchronously * **State Update (replay protection)**: Marks the transaction as processed in `processedQueries` mapping * **Transaction Content Validation**: Validates the transaction contents by checking transaction type and receipt status. * **Business Logic Execution:** If validation passes, executes business logic (minting tokens) * **Event Emission**: Emits `TokensMinted` event with the transaction details #### Constructor and Initialization ```solidity constructor() ERC20("Mintable (TEST)", "TEST") { // Get the precompile instance using the helper library VERIFIER = NativeQueryVerifierLib.getVerifier(); } ``` **Description:** * Initializes the ERC20 token with name and symbol * Sets the `VERIFIER` immutable variable to the precompile instance * The precompile address is constant and always available #### Replay Protection ```solidity mapping(bytes32 => bool) public processedQueries; ``` **Description:** * **processedQueries**: Maps transaction keys to boolean values to track processed transactions #### Proof Verification ```solidity function _verifyProof( uint64 chainKey, uint64 blockHeight, bytes calldata encodedTransaction, bytes32 merkleRoot, INativeQueryVerifier.MerkleProofEntry[] calldata siblings, bytes32 lowerEndpointDigest, bytes32[] calldata continuityRoots ) internal returns (bool verified) { INativeQueryVerifier.MerkleProof memory merkleProof = INativeQueryVerifier.MerkleProof({root: merkleRoot, siblings: siblings}); INativeQueryVerifier.ContinuityProof memory continuityProof = INativeQueryVerifier.ContinuityProof({ lowerEndpointDigest: lowerEndpointDigest, roots: continuityRoots }); // Verify inclusion proof verified = VERIFIER.verifyAndEmit(chainKey, blockHeight, encodedTransaction, merkleProof, continuityProof); return verified; } ``` **Description:** * Constructs the `MerkleProof` and `ContinuityProof` structs from the provided components * Calls the precompile's `verifyAndEmit()` function synchronously at address `0x0FD2` * Returns `true` if both Merkle proof (transaction inclusion) and continuity proof (block attestation chain) are valid; reverts on failure (transaction reverts if verification fails) * Emits `TransactionVerified` event on successful verification * Verification happens in the same transaction - no async processing #### Transaction Data Extraction The contract includes helper functions for extracting and validating transaction data from `encodedTransaction` bytes: ```solidity function _validateTransactionContents(bytes memory encodedTransaction) internal pure returns (bool found, address burntFrom, uint256 burntValue) { // Validate transaction type uint8 txType = EvmV1Decoder.getTransactionType(encodedTransaction); require(EvmV1Decoder.isValidTransactionType(txType), "Unsupported transaction type"); // Decode and validate receipt status EvmV1Decoder.ReceiptFields memory receipt = EvmV1Decoder.decodeReceiptFields(encodedTransaction); require(receipt.receiptStatus == 1, "Transaction did not succeed"); // Find transfer events and validate EvmV1Decoder.LogEntry[] memory transferLogs = EvmV1Decoder.getLogsByEventSignature(receipt, TRANSFER_EVENT_SIGNATURE); require(transferLogs.length > 0, "No transfer events found"); // Get the original sender EvmV1Decoder.CommonTxFields memory txFields = EvmV1Decoder.decodeCommonTxFields(encodedTransaction); // Check if there's an actual burn transfer from the sender (found, burntFrom, burntValue) = _processTransferLogs(transferLogs, txFields.from); require(found, "No valid burn transfer found"); return (found, burntFrom, burntValue); } ``` **Description:** * Uses `EvmV1Decoder` library to decode the transaction bytes * Validates transaction type and receipt status * Extracts event logs matching the `Transfer` event signature * Validates that a burn transfer occurred (transfer to address < 128) #### Complete Example See [`ASCMinter.sol`](https://github.com/gluwa/usc-testnet-bridge-examples/blob/main/contracts/sol/USCMinter.sol) for the complete implementation with all helper functions and event processing logic. A corresponding helper script and instructions to use this code are available in the [hello-bridge example](https://github.com/gluwa/usc-testnet-bridge-examples/tree/main/hello-bridge). # dApp Design Patterns: Readability An overview of common design patterns which allow a DApp to use the Attestcoin Protocol for cross chain readability. {% hint style="danger" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} ## Attestcoin Protocol Readability Design Patterns > *How you* **can** *use Attestcoin Readability vs how you* **should**. Cross-chain dApps use [Attestcoin Smart Contracts](/attestcoin-protocol/dapp-builder-infrastructure/attestcoin-smart-contracts) in a way that is intended to be *maximally flexible*. With Attestcoin Protocol Readability, data from a source chain such as Ethereum can be securely moved cross-chain by the Attestcoin Protocol. That data can then be verified and used by a dApp's Attestcoin Smart Contract which lives on Creditcoin. This way, the design space is left open for dApp teams to build whatever source chain logic they want and use Readability to provision whatever data they want. Most projects, however, are best served by following a specific pattern. ### Source Chain dApp Contract > *For more detail, read our page covering* [*Source Chain Smart Contracts*](/attestcoin-protocol/dapp-builder-infrastructure/source-chain-smart-contracts)*.* The scope of the source chain dApp contract should be as minimal as possible. It should focus on emitting events with data to be used by the [Attestcoin Smart Contract](/attestcoin-protocol/dapp-builder-infrastructure/attestcoin-smart-contracts) on Creditcoin. We want to keep logic on the source chain as *minimal* as possible! 1. Users call a source chain smart contract. 2. (optional) Sometimes there's a piece of business logic which must take place on the source chain. For example, burning tokens. If so then we execute that here before emitting events. 3. The source chain contract emits one or more events. That's all! ### **Attestcoin Smart Contract** > *For more detail, read our page covering the* [*Attestcoin Smart Contract*](/attestcoin-protocol/dapp-builder-infrastructure/attestcoin-smart-contracts)*.* We want to make executing the Attestcoin smart contract as *seamless* as possible! 1. An off-chain worker listens for events from the source chain smart contract 2. The worker waits for the block containing the event to be attested on Creditcoin 3. The worker generates Merkle and continuity proofs using the Proof Builder service 4. The worker calls the ASC contract with proofs and encoded transaction data 5. The ASC verifies proofs synchronously using the Block Prover Precompile 6. The ASC executes business logic immediately in the same transaction. Business logic execution either takes place in the ASC itself, or in a separate dApp contract which is called by the ASC. ## Best Practices Beyond the flow of data described above, we outline some best practices to manage the source chain side of your cross-chain dApp: 1. **An ASC-enabled dApp should have a single source chain contract** which emits all the events relevant to the Attestcoin Protocol. That way, the [offchain worker](/attestcoin-protocol/dapp-builder-infrastructure/offchain-readability-workers) building readability queries for your dApp only needs to follow events emitted from a single contract address. 2. **Unambiguous events:** Events should be unambiguous. Try to use unique events for each kind of readability query you want to submit. For instance, a lending dApp tracking loans on Ethereum would want separate events for `LoanInitiated` and `LoanRepaid`. 3. **Clear event naming**: Events should be named so that it's clear they will initiate cross-chain functionality. For instance, the event name `TokensBurnedForBridging` (as used in the examples) clearly indicates a token burn action with the intent to bridge tokens cross-chain. 4. **Avoid common events**: Don't initiate cross-chain functionality using common events such as standard `Transfer` events. Instead, prefer to wrap actions in calls that emit more specific events such as `TokensBurned`. This makes it easier for workers to filter and process the correct events. 5. **Include all necessary data**: Add all the relevant information you want moved cross-chain to the events emitted by the source chain contract. For instance, the `TokensBurned` event should have fields `from` and `value` indicating which account burned the tokens and how many tokens were burned. Otherwise the ASC on Creditcoin won't know which account to mint tokens to or how many. # Offchain Readability Workers An overview of Offchain Workers and how to use them to streamline user interactions. {% hint style="danger" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} ## **Motivation for Offchain Readability Workers** {% hint style="info" %} In the future, 3rd party relayers will offer the submission of readability queries as a service. A dApp team may choose to pay a small fee per readability query rather than maintaining their own worker. {% endhint %} When Attestcoin Protocol Readability provisions data from one chain to another, there are two transactions involved: 1. **The user submits a transaction on the source chain.** Usually this would be a source chain smart contract call emitting some event for which we want to transfer data to the execution chain. 2. **The ASC contract must be called on Creditcoin.** This requires generating proofs and submitting a call to the ASC with proofs and encoded transaction data. The ASC verifies the proofs synchronously and executes business logic immediately. The following diagram highlights where these two transactions take place:
The first transaction must always be submitted by the end user. However, the second transaction can be initiated by an off-chain worker on behalf of the user. Using an off-chain worker provides significant UX and technical benefits: * **Seamless user experience**: Without a worker, users would need to wait for attestation (several minutes), manually generate proofs, format the proof data correctly, and then submit a second transaction. With a worker, users only need to sign the initial source chain transaction. Everything else happens automatically in the background. * **Eliminates technical complexity for end users**: Proof generation requires calling the Proof Builder service, waiting for attestation, handling retries, and properly formatting complex proof structures (Merkle proofs, continuity proofs, encoded transactions). Off-chain workers handle all of this complexity automatically, so users don't need to understand the underlying oracle mechanics. * **Reduces transaction failures and improves reliability**: Workers can implement robust retry logic, handle API failures gracefully, and ensure proper error handling. Users attempting manual proof generation are more likely to encounter failures due to timing issues (submitting before attestation completes), formatting errors, or network problems. * **Enables better monitoring and observation**: Workers can track processing status, log events, and provide visibility into the cross-chain data flow. This helps DApp teams debug issues and monitor their DApp's health. ## Designing an Offchain Oracle Worker Using an off-chain worker can drastically improve the UX of your cross-chain DApp by reducing the number of user interactions needed to trigger core business logic on the Creditcoin chain. ### Worker Transaction Flow The worker automates the following process: 1. **Monitor source chain:** The worker constantly monitors the source chain contract for events (e.g., `TokensBurnedForBridging` events). 2. **Wait for attestation:** When an event is detected, the worker waits for the block containing the event to be attested on Creditcoin. 3. **Generate proofs:** The worker can generate Merkle and continuity proofs via the Proof Builder service. 4. **Call ASC contract:** The worker calls the ASC contract with the proofs and encoded transaction data. The ASC contract verifies the proofs synchronously and executes business logic immediately. 5. **Handle results:** The worker can listen for events from the ASC contract to confirm successful execution. All of this happens automatically - the user only needs to sign the initial source chain transaction. {% @mermaid/diagram content="sequenceDiagram participant User participant SC as Source Chain
(Smart Contract) participant Worker as Oracle Worker participant Attestors as Attestor Network participant Oracle as Block Prover Precompile participant ProofBuilder as Proof Builder
Service participant USC as ASC Contract participant BusinessLogic as dApp Business Logic
Contract ``` Note over User,BusinessLogic: Phase 1: User Initiates Transaction User->>SC: Submit Transaction
(e.g., burn tokens) SC->>SC: Execute Logic & Emit Event Note over Worker,BusinessLogic: Phase 2: Worker Monitors & Waits Worker->>SC: Monitor Source Chain
for Events SC-->>Worker: Event Detected Note over Attestors: Attestation Process
(happens independently) Attestors->>SC: Monitor Source Chain
for Blocks SC-->>Attestors: New Blocks Detected Attestors->>Oracle: Submit Aggregated Attestation Worker->>Oracle: Check if Block Attested Oracle-->>Worker: Block Attested ✓ Note over Worker,BusinessLogic: Phase 3: Generate Proofs Worker->>ProofAPI: Request Proofs
(chainKey, blockHeight, txHash) ProofAPI->>Oracle: Fetch Attestations Oracle-->>ProofAPI: Attestation Data ProofAPI->>SC: Fetch Source Chain Block SC-->>ProofAPI: Block Data ProofAPI->>ProofAPI: Generate Merkle & Continuity Proofs ProofAPI-->>Worker: Return Proofs & Encoded TX Note over Worker,BusinessLogic: Phase 4: Verify & Execute Worker->>USC: Call processCrossChainData()
(proofs + encoded tx) USC->>Oracle: Verify Proofs
(via precompile) Oracle->>Oracle: Verify Merkle & Continuity Proofs Oracle-->>USC: Verification Result: ✓ Valid USC->>BusinessLogic: Execute Business Logic
(e.g., mint tokens) BusinessLogic->>BusinessLogic: Update State and Emit Event
(e.g., TokensMinted) BusinessLogic-->>User: Listens to Dapp events (optional)" %} ``` ### Worker Implementation Considerations This has just been a starting point designed to introduce you to the use of Offchain Workers. Each dApp builder team will likely want to implement their Worker differently to fit the rest of their technology stack. Keeping this in mind, the main goal of an Offchain Worker should always be robustness. This includes: * **Retaining stored records of events in progress** in the event of a Worker shutdown * **Catching up with any event that might have been missed** as a result of an unexpected shutdown * **Avoiding submitting multiple ASC calls for the same event** (replay protection is handled by the ASC contract, but workers should also track processed events) * **Following multiple source chain nodes** to listen for events in case a node experiences issues * **Retrying failed proof generation or ASC calls** in case they fail. A call can fail for many reasons: for example, the Proof Builder services might be experiencing downtime or connectivity issues, or the ASC contract call might fail due to network issues Below is an example of the logical flow that a more advanced oracle worker might use {% @mermaid/diagram content="--- config: theme: neo ---------- stateDiagram s1:Monitor source chain for events state if\_events <> s2:Event detected s3:Wait for block attestation state if\_attested <> s4:Generate proofs via Proof Builder Service state if\_proof\_success <> s5:Call ASC contract with proofs state if\_usc\_success <> s6:ASC verifies synchronously s7:Business logic executed s8:Success! retryAttestation:Retry after delay retryProof:Retry proof generation retryUSC:Retry ASC call ``` [*] --> s1 s1 --> if_events if_events --> s2:Yes if_events --> s1:No s2 --> s3 s3 --> if_attested if_attested --> s4:Block attested if_attested --> retryAttestation:Not yet attested retryAttestation --> s3 s4 --> if_proof_success if_proof_success --> s5:Proofs generated if_proof_success --> retryProof:Service error/retry retryProof --> s4 s5 --> if_usc_success if_usc_success --> s6:Transaction submitted if_usc_success --> retryUSC:Network error/retry retryUSC --> s5 s6 --> s7 s7 --> s8 s8 --> [*] ``` " fullWidth="true" %} # Attestcoin SDK (USC SDK) This page describes the SDK developed by Gluwa to seamlessly interact with the Attestcoin Protocol in a reliable and efficient manner {% hint style="danger" %} The term USC (Universal Smart Contract) was replaced with the term Attestcoin Protocol. But repository names and other resources have yet to be updated. The usc-sdk is one such resource. {% endhint %} ## Getting Started The `@gluwa/usc-sdk` is a **TypeScript/JavaScript SDK** for verifying cross-chain transactions on the Creditcoin network. It lets you generate inclusion proofs for transactions on supported source chains (e.g. Ethereum Sepolia) and verify them on-chain via Creditcoin's precompile contracts. ### Installation ```sh npm install @gluwa/usc-sdk # or yarn add @gluwa/usc-sdk ``` The SDK requires [ethers.js v6](https://docs.ethers.org/v6/) as a peer dependency. ### Core concepts A **tra*****n*****saction inclusion proof** answers the question: *"Did this transaction really happen on chain X?"* It is made of two parts:
PartWhat it proves
Merkle proofThe transaction is included in a specific block's transaction tree
Continuity proofThat block is part of a sequence of blocks anchored to an attestation point on Creditcoin
The SDK provides three main components you will work with: * **`ProofBuilder`** — fetches pre-computed proofs from a hosted builder service (recommended starting point) * **`PrecompileChainInfoProvider`** — queries attestation state from Creditcoin * **`PrecompileBlockProver`** — submits proofs to Creditcoin's on-chain verifier ### Step by step guide First you'll need two JSON-RPC providers: one for the **source chain** (where the transaction happened) and one for **Creditcoin** (where proofs are verified). ```typescript import { JsonRpcProvider } from 'ethers'; import { chainInfo, blockProver, proofProvider } from '@gluwa/usc-sdk'; // Source chain (e.g. Ethereum Sepolia) const sourceProvider = new JsonRpcProvider('https://sepolia.infura.io/v3/'); //or other providers // Creditcoin CC3 Testnet (CC3 Mainnet only once you are redy for production) const creditcoinProvider = new JsonRpcProvider('https://rpc.cc3-testnet.creditcoin.network'); //or CC3 Tesnet RPC, https://rpc.cc3-testnet.creditcoin.network ``` #### Step 1: Query supported chains Use `PrecompileChainInfoProvider` to see which source chains are currently supported and find the `chainKey` for the chain you want to prove transactions from. ```typescript const chainInfoProvider = new chainInfo.PrecompileChainInfoProvider(creditcoinProvider); const supportedChains = await chainInfoProvider.getSupportedChains(); console.log(supportedChains); // [{ chainKey: 1, chainId: 11155111, chainName: 'Ethereum Sepolia', chainEncoding: 1 }, ...] ``` The `chainKey` is a Creditcoin-internal identifier for a source chain — it is **not** the same as the chain's EVM `chainId`. You will need it in every subsequent call. #### Step 2: Wait for attestation Before a proof can be generated, the block containing your transaction must be **attested** on Creditcoin. Attestation happens periodically and automatically; you just need to wait for it. ```typescript const txHash = '0x6fe777442b70a5511f3c443176ae860e50445bd93b663711717996a70c5022ab'; const chainKey = 1; // from Step 1 // Find which block the transaction is in const tx = await sourceProvider.getTransaction(txHash); const blockNumber = tx!.blockNumber!; // We create a connection to the proof builder service. We listen // for new attestations to be cached here rather than listening for // them directly on-chain. This prevents request timing issues. const proofBuilder = new proofProvider.service.ProofBuilder( chainKey, 'https://prover.cc3-testnet.creditcoin.network', 5000, // request timeout in ms (optional, default: 5000) ); // Wait until Creditcoin has attested that block await proofBuilder.waitUntilHeightAttested(chainKey, blockNumber); console.log(`Block ${blockNumber} is attested — ready to generate proof`); ``` `waitUntilHeightAttested` polls the `proofBuilder` service at a configurable interval (default: `15s`) and resolves once the necessary attestation is present in the prover cache. It will throw after a configurable timeout (default: `15m`). #### Step 3: Generate a proof with the Prover `ProofBuilder` is the simplest way to get a proof. It calls a hosted API that computes and caches proofs on your behalf — no RPC-heavy local computation required. ```typescript const result = await proofBuilder.getProof(txHash); if (!result.success) { throw new Error(`Proof generation failed: ${result.error}`); } const proofData = result.data!; console.log('Block number:', proofData.headerNumber); console.log('Transaction bytes:', proofData.txBytes); ``` The returned `proofData` object contains everything needed for on-chain verification: | Field | Type | Description | | ----------------- | ------------------------ | --------------------------------------------------------- | | `chainKey` | `number` | Source chain identifier | | `headerNumber` | `number` | Block number the transaction was in | | `txHash` | `string` | Transaction hash | | `txBytes` | `string` | ABI-encoded transaction | | `merkleProof` | `TransactionMerkleProof` | Siblings in the block's transaction Merkle tree | | `continuityProof` | `ContinuityProof` | Chain of Merkle roots linking the block to an attestation | | `cached` | `boolean` | Whether the proof was served from cache | #### Batch proof generation If you need proofs for multiple transactions at once, use `getBatchProof`. All transactions in a batch share a single continuity proof, which makes on-chain batch verification more efficient. The current `MAX_BATCH_SIZE` is 10 proofs, and these must be within a `MAX_BATCH_RANGE` of 1000 blocks. ```typescript const batchResult = await proofBuilder.getBatchProof([txHash1, txHash2]); if (!batchResult.success) { throw new Error(`Batch proof generation failed: ${batchResult.error}`); } const batchData = batchResult.data!; ``` #### Step 4: Verify the proof on-chain `PrecompileBlockProver` submits proofs to Creditcoin's verifier precompile. #### Single transaction ```typescript const prover = new blockProver.PrecompileBlockProver(creditcoinProvider); const verified = await prover.verifySingle( proofData.chainKey, proofData.headerNumber, proofData.txBytes, proofData.merkleProof, proofData.continuityProof, ); console.log('Verification result:', verified ? 'SUCCESS' : 'FAILED'); ``` #### Batch of transactions When using batch proofs, you need to flatten the proof data into parallel arrays: ```typescript const headers: number[] = []; const txBytesArr: string[] = []; const merkleProofs = []; for (const [headerNumber, proofsMap] of batchData.merkleProofs.entries()) { for (const [, proofEntry] of proofsMap.entries()) { headers.push(headerNumber); txBytesArr.push(proofEntry.txBytes); merkleProofs.push(proofEntry.merkleProof); } } const batchVerified = await prover.verifyBatch( batchData.chainKey, headers, txBytesArr, merkleProofs, batchData.continuityProof, ); console.log('Batch verification result:', batchVerified ? 'SUCCESS' : 'FAILED'); ``` ### Complete end-to-end example 
import { JsonRpcProvider } from 'ethers';
import { chainInfo, blockProver, proofProvider } from '@gluwa/usc-sdk';

async function proveTransaction(txHash: string) {
  // Resolve chain key
  const chainKey = 1; // Ethereum Sepolia on CC3 Testnet
  
  // Providers
  const sourceProvider = new JsonRpcProvider('https://sepolia.infura.io/v3/<api_key>'); //or other providers
  const creditcoinProvider = new JsonRpcProvider('https://rpc.cc3-testnet.creditcoin.network');

  const chainInfoProvider = new chainInfo.PrecompileChainInfoProvider(creditcoinProvider);
  const prover = new blockProver.PrecompileBlockProver(creditcoinProvider);
  const proofBuilder = new proofProvider.service.ProofBuilder(
    chainKey,
    'https://prover.cc3-testnet.creditcoin.network',
  );

  // Find block and wait for attestation
  const tx = await sourceProvider.getTransaction(txHash);
  await proofBuilder.waitUntilHeightAttested(chainKey, tx!.blockNumber!);

  // Generate proof via API
  const result = await proofBuilder.getProof(txHash);

  if (!result.success || !result.data) {
    throw new Error(`Proof generation failed: ${result.error}`);
  }

  const { chainKey: ck, headerNumber, txBytes, merkleProof, continuityProof } = result.data;

  // Verify on-chain
  const verified = await prover.verifySingle(ck, headerNumber, txBytes, merkleProof, continuityProof);
  console.log('Proof verification:', verified ? 'SUCCESS' : 'FAILED');

  return verified;
}
### Alternative: Raw proof generator For advanced use cases where you need full control (e.g. running your own indexer, offline proof computation, or custom block providers), the SDK also ships a `RawProofBuilder` that computes proofs locally by fetching data directly from source chain RPCs. ```typescript import { EncodingVersion } from '@gluwa/usc-sdk/encoding'; const blockProvider = new proofProvider.raw.blockProvider.SimpleBlockProvider(sourceProvider); const rawGenerator = new proofProvider.raw.RawProofBuilder( chainKey, blockProvider, chainInfoProvider, EncodingVersion.V1, ); const result = await rawGenerator.getProof(txHash); ``` Both `RawProofBuilder` and `ProofBuilder` implement the same `ProofProvider` interface and produce identical output, so you can swap between them without changing any downstream code. # Attestcoin Protocol Chains - Environments This page describes the various Creditcoin chains that are enabled for Attestcoin Protocol related flows ### CC3 Mainnet
ASC Dashboardhttps://dashboard.cc3-mainnet-usc.creditcoin.network/
Proof Builder APIhttps://proofbuilder.cc3-mainnet-usc.creditcoin.network/

To view a swagger, please use testnet version.
Decoder contract0x9D094C9f22B10FCf842c2fC6A0981630A4F94B5C
ChainInfo Precompile0x0000000000000000000000000000000000000fd3
BlockProver Precompile0x0000000000000000000000000000000000000FD2
SDKhttps://www.npmjs.com/package/@gluwa/usc-sdk
| **Supported Mainnet Chains** | **Chainkey** | **Genesis Block** | | ---------------------------- | ------------ | ----------------- | | Ethereum Mainnet | 1 | 0 | ### CC3 Testnet
ASC Dashboardhttps://dashboard.cc3-testnet.creditcoin.network/
Proof builder APIhttps://proof-gen-api.cc3-testnet.creditcoin.network/
Decoder contract0x731c345d79Fb8BbDC541f9DF3b6317585F849F9f
ChainInfo Precompile0x0000000000000000000000000000000000000fd3
BlcokProver Precompile0x0000000000000000000000000000000000000FD2
SDKhttps://www.npmjs.com/package/@gluwa/usc-sdk
| **Supported Testnet Chains** | **Chainkey** | **Genesis Block** | | ---------------------------- | ------------ | ----------------- | | Ethereum Sepolia | 1 | 0 | | Ethereum Mainnet | 3 | 0 | # Guided Tutorials {% hint style="warning" %} Please note that all information and code snippets provided in this section are for educational purposes only and not to be directly deployed in production. {% endhint %} The following guide is designed to help you get hands-on with the Attestcoin Protocol, walking you step-by-step from your very first bridge transaction to more advanced custom contract bridging. Each tutorial builds on the previous one, giving you both the *theoretical understanding* and *practical experience* you’ll need to successfully interact with the Attestcoin Protocol. **Modules:** 1. [​Introduction to Attestation Protocol](/attestcoin-protocol/guided-tutorials#introduction-to-creditcoin-usc)​ 2. [​Attestcoin Tutorial 1: Hello Bridge](/attestcoin-protocol/guided-tutorials#creditcoin-usc-tutorial-1-hello-bridge)​ 3. ​[Attestcoin Tutorial 2: Custom Contract Bridging](/attestcoin-protocol/guided-tutorials#creditcoin-usc-tutorial-2-custom-contracts)​ 4. ​[Attestcoin Tutorial 3: Bridge Off-chain Worker](/attestcoin-protocol/guided-tutorials#creditcoin-usc-tutorial-3-bridge-off-chain-worker)​ 5. [Attestcoin Tutorial 4: Cross-Chain Loan dApp](/attestcoin-protocol/guided-tutorials#creditcoin-usc-tutorial-4-cross-chain-loan-dapp) {% hint style="info" %} To help you follow each module, below there are companion walkthrough videos, if you have trouble by yourself or you'd prefer a more guided approach, please use them to your advantage! {% endhint %} ### **Introduction to the Attestcoin Protocol** Repository with tutorials: {% hint style="warning" %} Please note that the videos use the original term, Universal Smart Contracts (USC). This has since been renamed to Attestcoin Protocol. Also, the name of the tutorial repository has been updated. So the link above on this page should be used rather than any of the links contained in video slides! {% endhint %} {% file src="/files/cVI6IlwYGJb1SyIYOI3I" %} #### Attestcoin Protocol Tutorial 1: Hello Bridge {% file src="/files/i8jA6CTNj79dZX9kOASn" %} #### Attestcoin Protocol Tutorial 2: Custom Contracts Bridging {% file src="/files/5tqLVNCNijBpjYe7Q2Ql" %} #### Attestcoin Protocol Tutorial 3: Bridge Off-chain Worker {% file src="/files/Qji52PmEZEnSnyd2m4dV" %} #### Attestcoin Protocol Tutorial 4: Cross-Chain Loan dApp {% file src="/files/CUNIHiukqHTU1KsLfLsU" %} # Changelogs To get information on the latest releases visit # Attestcoin Protocol Operator Guides There are two decentralized operator roles for the Attestcoin Protocol on Creditcoin. Attestor and relayer. We detail the process of deploying these here. ### Attestor Role Attestors have two main functions: 1. **Following and attesting to source-chain blocks.** Attestors follow new blocks on a source chain and attest to them. This is done eagerly, and enables inexpensive and rapid readability of source-chain data. 2. **Signing writability messages** *(not yet released).* In an upcoming release, Attestors will also sign writability messages. This will enable Attestcoin Smart Contracts to send data to a destination chain, effectively providing full two-way interoperability. ### Relayer Role {% hint style="info" %} The Relayer role is evolving quickly. To keep up with the latest Relayer news, stay in touch with us through the Creditcoin [blog](https://creditcoin.org/blog), [Discord](https://discord.gg/creditcoin), and [X](https://x.com/creditcoin). {% endhint %} # Attestor Operator Guide Describes in detail how to launch and monitor your own attestor on Creditcoin 3 Mainnet or Testnet {% hint style="danger" %} During the initial launch phase of Attestcoin Protocol Readability, registering as an Attestor requires first party authorization. Eventually this role will be open to everyone. See the `Permissiveness` section for more details. {% endhint %} ### Overview This guide walks an **external operator** through running a single Creditcoin 3 (CC3) Attestor for **Ethereum Mainnet** on CC3 mainnet or testnet, while the attestation network is in `AuthorizedOnly` mode. An Attestor is a component that watches a source chain (for example: Ethereum Mainnet), produces signed attestations about its blocks, and submits them to CC3. You do **not** need Kubernetes or the Creditcoin attestor-operator to run one. The Attestor is a single binary shipped in the `gluwa/creditcoin3` Docker image. ### Permissiveness Attestor election operates under three possible modes: | Mode | Policy | | ---------------- | ----------------------------------------- | | `OpenToAny` | Any Attestor can be selected | | `AuthorizedOnly` | Only authorized Attestors can be selected | | `DeniedToAll` | No new Attestors can be selected | By default, all chain keys are created under the `OpenToAny` mode. In a production network, however, such as mainnet or testnet, chain keys will be operating under the `AuthorizedOnly` or `DeniedToAll` modes. This means that **for production networks, you will have to contact the Creditcoin team to be added to the on-chain set of authorized attestation entities**. You can find a list of on-chain authorized Attestors by querying the `attestation/authorizedAttestors` storage item on the [chainstate](https://polkadot.js.org/apps/#/chainstate?rpc=wss://rpc.cc3-testnet.creditcoin.network) tab of polkadotjs. For networks operating under `OpenToAny`, this will return `null`. {% hint style="warning" %} Make sure to first get into contact with the Creditcoin team and that your Attestor address is part of the authorized set before trying to set up an Attestor against a production network. {% endhint %} ### Attestor Setup Overview This section covers the following: 1. Prerequisites before you can set up an Attestor 2. An overview of the steps to set up an Attestor 3. The architecture decision of how to set up RPC endpoints for your Attestor {% hint style="info" %} You will need two separate CC3 accounts: * Attestor account - the "hot" key your node runs with. Its mnemonic goes in the node's config, and the same secret derives the node's BLS attestation key and libp2p identity. It only needs a small balance for fees. * Stash account - holds the bonded funds and signs the administrative extrinsics (registerAttestor, chill, unregisterAttestor, withdrawUnbonded). Keep it as cold as possible; its mnemonic never touches the Attestor host. The two must be different addresses. Step 1 below covers generating both. {% endhint %} **Prerequisites** * A Linux host (or VM) with Docker installed. Reasonable starting resources for the Attestor alone: 2 vCPU, 2 GB RAM, a few GB disk for logs/identity. Running your own RPC nodes needs substantially more (see Step 2). * Outbound network access, plus an **inbound** TCP port for libp2p P2P (default `9000`) so other Attestors can reach you. * Access to the `gluwa/creditcoin3` Docker image. This image contains the binary for your Attestor. If you elect to run a Creditcoin 3 RPC node, it will also use this image. Use the same tag Creditcoin runs in production; see `Creditcoin Release Image` in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings). * A way to sign extrinsics on CC3 mainnet or testnet: the Polkadot.js Apps UI connected to a CC3 mainnet RPC is the simplest. Import your Attestor mnemonic into the Polkadot.js browser extension. A link to the Polkadot.js App UI for your desired chain can be found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table * (Optional) `subkey` or Node.js for generating the account offline. **Setup Steps Overview** 1. Generate an sr25519 account (mnemonic + SS58 address) 2. Stand up / choose your CC3 + Ethereum RPC endpoints 3. Fund the account with at least 10 CTC 4. Send your SS58 address to the Creditcoin team -> they `authorize_attestor(chainKey, you)` \[AuthorizedOnly] 5. Use your stash account to submit `register_attestor(chainKey, you)` -> status: Idle 6. Start the Attestor node; it auto-submits `attest()` -> status: Waiting 7. Next election/epoch rotation promotes you -> status: Active 8. Your node commits attestations and earns rewards **Initial Decision: Which RPC Endpoints to Use** An Attestor needs **two** independent RPC connections: | Connection | Used for | Config key | | ------------------------------------ | --------------------------------------------------------------------- | -------------------------------------------- | | **CC3 RPC** (WebSocket) | Listening to CC3 events/storage and submitting attestation extrinsics | `cc3.url` / `--cc3-url` / `ATTESTOR_CC3_URL` | | **Ethereum Mainnet RPC** (WebSocket) | Pulling source-chain block data and generating continuity proofs | `eth.url` / `--eth-url` / `ATTESTOR_ETH_URL` | The two connections are independent, and they have different options: * **Creditcoin 3 RPC** - you can either use Creditcoin's public CC3 RPC or run your own CC3 node. * **Ethereum Mainnet RPC** - this must come from an external source, since Creditcoin does not run a public Ethereum RPC for external Attestors. You can use a commercial provider or run your own Ethereum node. See Step 2 for how to set up each of these. > **Recommendation:** Attestors are explicitly *advised to run their own RPC servers* (it's noted directly in the Attestor's own config template). A shared public endpoint is rate-limited and is a single point of failure for your liveness. Use Creditcoin's public CC3 RPC to validate your setup, then move to your own node for production. ### Attestor Setup Steps **Step 1: Generate your Attestor account** The Attestor signs with an **sr25519** key. The account's SS58 address is what gets authorized, registered, and funded on-chain. The *same* secret is also used to derive the node's BLS attestation key and libp2p identity automatically, so you only ever provide the one secret. Pick any **one** method: **Option 1: Polkadot.js browser extension.** Create a new account, choosing the `sr25519` (default) type, and back up the seed phrase. **Option 2:** `subkey` **(simplest, if you already have subkey installed):** ``` subkey generate --scheme sr25519 ``` Record the **secret phrase** (mnemonic) and the **SS58 Address**. **Option 3: offline Node.js snippet** (prints the address derived from a fresh mnemonic): ``` node --input-type=module -e ' import { mnemonicGenerate, cryptoWaitReady } from "@polkadot/util-crypto"; import { Keyring } from "@polkadot/keyring"; await cryptoWaitReady(); const mnemonic = mnemonicGenerate(); const address = new Keyring({ type: "sr25519" }).addFromMnemonic(mnemonic).address; console.log(JSON.stringify({ mnemonic, address }, null, 2)); ' ``` **For All Step 1 Options:** > **Keep the mnemonic secret and backed up.** It controls your funds and your Attestor identity. The Attestor accepts either a BIP-39 mnemonic or a raw `0x`-prefixed 32-byte hex seed as its secret. If you start the node with **no** secret, it generates a random one on each start. Never do this for a real Attestor. {% hint style="warning" %} Repeat this address creation step for your stash account. Your Attestor account and stash account must be different addresses!
The key idea of a stash account is **separation of concerns**: * **Stash account**: Holds the actual funds being staked. It's meant to stay as secure as possible - ideally a cold or rarely-used key - because it controls a large amount of value. * **Attestor controller account**: Used for day-to-day Attestor operations (starting/stopping attestation, setting preferences, etc.). It doesn't hold significant funds, so it can be a "hot" key used more frequently without much risk. {% endhint %} **Step 2: RPC Endpoints Setup** An Attestor needs **two** RPC endpoints: one for **Creditcoin 3** and one for **Ethereum Mainnet**. Set up each one as described below. {% hint style="info" %} **Recommendation:** Attestors are explicitly *advised to run their own RPC servers* (it's noted directly in the Attestor's own config template). A shared public endpoint is rate-limited and is a single point of failure for your liveness. Use Creditcoin's public CC3 RPC to validate your setup, then move to your own node for production. {% endhint %} **Creditcoin3 RPC** You have two options: *Option A - Use Creditcoin's public CC3 RPC.* No setup necessary! When you spin up your Attestor in Step 6, point it at Creditcoin's public CC3 RPC corresponding to the network you're joining. These are found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table. > Public endpoints are shared and rate-limited. Fine for bring-up and testing; for production, prefer running your own node (Option B). *Option B - Run your own CC3 node.* {% hint style="warning" %} If using this guide for an Attestor on CC3 Testnet, this option is unsupported. {% endhint %} To run a CC3 mainnet RPC node, see the RPC Guide. You can remove the following parameters when launching your RPC node, as it is only serving your Attestor, rather than the public. * \--prometheus-external * \--telemetry-url * \--public-addr * \--pruning archive Notes: * Wait for the node to fully sync before relying on it. The Attestor will connect over `ws://:9944`. * The current production bootnode(s) are published in the Creditcoin environment pages (they may rotate). See the [environment documentation](https://docs.creditcoin.org/environments/mainnet) for the up-to-date list. **Ethereum Mainnet RPC** The Ethereum Mainnet RPC must come from an external source - Creditcoin does not run a public Ethereum RPC for external Attestors. You'll need to find a provider of Ethereum Mainnet RPC with a rate limit that allows the volume of calls your Attestor makes. The Attestor connects over a **websocket (wss)** endpoint. Either: * Use a commercial provider (Alchemy, Infura, Chainstack, QuickNode, etc.) and use its websocket (wss) endpoint, **or** * Run your own execution client (e.g. Geth/Erigon/Nethermind) and expose its WS endpoint (e.g. `ws://:8546`). If the Creditcoin team shares an Ethereum endpoint with you, use that value for `eth.url` instead. The Attestor reads historical block data and builds continuity proofs, so the endpoint must serve the block ranges you attest over. A full node with adequate history (or a provider plan that allows historical lookups) is required. {% hint style="info" %} **Expected call volume:** * Initial sync: burst of \~50–100 req/s until caught up (2 requests per block, max 20 concurrent). Rule of thumb: 1 day of backlog clears in \~5 minutes. * Normal day: \~15,000 requests/day (\~10 req/min - 2 requests per new block), plus 2 WebSocket newHeads subscriptions (WS support required). * Peak: capped at 20 concurrent requests by design; worst case \~100–200 req/s on a low-latency endpoint during catch-up. {% endhint %} > Your endpoints for the Attestor config (Step 6): `cc3.url = ` (Option A) or `ws://:9944` (Option B) `eth.url = ` or your own node's `ws://:8546` **Step 3: Fund your account** The Attestor checks its balance at startup and **refuses to run** if the free balance is below the minimum: * **Minimum required: 1 CTC** (this is a hard check in the binary; below it, the node logs `⛔ Attestor has insufficient balance` and exits). In this step, you fund **two** accounts: * **Attestor account:** send at least **10 CTC** (minimum required **1 CTC** plus a few extra to cover the transaction fees), to your Attestor's SS58 address from any funded CC3 account you control, e.g., via Polkadot.js Apps → *Accounts → Transfer*, or the `balances.transferKeepAlive(dest, amount)` extrinsic. * **Stash account:** fund it with at least `MinBondRequirement` (see the hint below). > Ongoing cost is low: successful attestation submissions from an active Attestor have their fee **refunded**, so your balance mainly needs to stay above the 1 CTC floor and cover the occasional non-refunded fee. {% hint style="warning" %} Your stash account must have a balance greater than `MinBondRequirement`. Currently the `MinBondRequirement` for attesting to `EthMainnet` on `CC3 Mainnet` is 0. But in the future when the Attestor set is permissionless, that number will be set sufficiently high to economically secure the network. Still, the stash account must have at least enough funds to pay for the `registerAttestor` extrinsic.\ \ On `CC3 Testnet` the `MinBondRequirement` to attest to `EthMainnet` is 100 CTC. The public testnet faucet grants 10,000 CTC, which is more than enough to fund both accounts. {% endhint %} **Step 4: Get your account authorized (AuthorizedOnly)** Since the network uses the `AuthorizedOnly` election policy for this chain, your account must be on the on-chain allow-list **before** it can register or be elected. Authorization is gated behind the Creditcoin team's operator/governance origin (`attestation.authorize_attestor`). **You cannot do this step yourself.** **Action:** send the Creditcoin team the following and ask them to authorize you: * Your Attestor **SS58 address** (from Step 1). * The **chain key** you intend to attest for. You can find this in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table The Creditcoin team (sudo/governance) will execute: {% hint style="info" %} For the following command, \ is found in the [per-chain settings table](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) {% endhint %} `attestation.authorize_attestor(chainKey = , attestorId = )` You can confirm it landed by checking on-chain storage (Polkadot.js Apps → *Developer → Chain state*): {% hint style="info" %} For the following storage entry, \ is found in the [per-chain settings table](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) {% endhint %} `attestation.authorizedAttestors(, )` A returned entry (rather than empty) means you're authorized. You can also watch for the `attestation.AuthorizedAttestorAdded(, )` event. > If you skip this step, your `register_attestor` call in Step 5 will fail with `NotPreAuthorizedToRegister`, and even if you were already registered, the election will silently skip you because you aren't authorized. **Step 5: Register your Attestor on-chain** You perform this step yourself, signing with your Attestor stash account. Registration puts your account into the Attestor set with status `Idle`. {% hint style="warning" %} When you call `registerAttestor`, the calling account becomes the `stash` address of your Attestor. If the calling account doesn't have at least `MinBondRequirement` funds, then your `registerAttestor` call will fail. {% endhint %} 1. Go to Polkadot.js Apps → *Developer → Extrinsics* 2. In the account dropdown at the top, select your stash account - the calling account becomes the Attestor's stash 3. Select attestation in the left dropdown and registerAttestor in the right dropdown 4. Fill in the parameters: chainKey = (per-chain settings table), attestorId = your Attestor account's SS58 address 5. Submit and sign the transaction {% hint style="info" %} For the following command, \ is found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table {% endhint %} `attestation.registerAttestor(chainKey = , attestorId = )` Verify registration (Polkadot.js Apps → *Developer → Chain state*): `attestation.attestors(, )` A non-empty entry with `status: Idle` means you're registered and ready to run the node. > Order tip: you can register any time **after** authorization (Step 4) and **after** funding (Step 3). The node itself does not call `register_attestor` for you; it only takes over from the `Idle` state onward. **Step 6: Configure and run the Attestor** The Attestor reads configuration in this priority order: **CLI args > environment variables > config file** (`config.yaml`). Create `config.yaml`: {% hint style="info" %} To fill in \ and \ consult the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table\ \ To fill in \, ask your contact on the Creditcoin team. Attestor bootnodes aren't public yet. When you ask, specify whether you are setting up an Attestor for CC3 Mainnet or CC3 Testnet. {% endhint %} ``` attestor: name: "my-attestor" chain_key: # Ethereum Mainnet on CC3 mainnet or CC3 Testnet secret: "" # or a 0x-prefixed 32-byte hex seed api: port: 9100 p2p: port: 9000 no_mdns: true # recommended outside a local network boot_nodes: # Ask the Creditcoin team for this. See hint above. - "" eth: # External provider websocket (wss), or your own node, e.g. ws://eth-host:8546 url: "" cc3: # Option A: # Option B: your own node, e.g. ws://:9944 url: "" ``` Run it: To fill in \, see the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table ``` docker run -d --name cc3-attestor \ --entrypoint /bin/attestor \ -p 9000:9000 \ -p 9100:9100 \ -v "$PWD/config.yaml:/config.yaml:ro" \ -v "$PWD/logs:/logs" \ -v "$PWD/data:/data" \ gluwa/creditcoin3: \ --config /config.yaml --logs /logs ``` **P2P reachability:** make sure your P2P port (`9000`) is reachable from the internet (firewall/security-group inbound rule, and a port mapping if behind NAT). If you set a stable public hostname/IP, pass it via `public_addr` / `--public-addr` / `ATTESTOR_PUBLIC_ADDRESS` so peers can dial you back. **Boot node:** the multiaddr in `config.yaml` above is an example of the shared Eth-Mainnet Attestor bootnode. Confirm the **current** value with the Creditcoin team before relying on it. Without a reachable boot node your Attestor can't discover peers. **Step 7: Verify it's working** 1. **Watch the logs.** On a correctly funded, authorized, registered Attestor you should see, in order: * `🔍 Attestor has sufficient balance` * `📝 Submitting attest() extrinsic to transition from Idle to Waiting` * `✅ Successfully submitted attest() - now Waiting for election` * `⏲️ Waiting for attestor to be made eligible` * Then (after the next election) it begins producing/committing attestations. ``` docker logs -f cc3-attestor ``` 2. **Check on-chain status** (Polkadot.js Apps → *Developer → Chain state*): {% hint style="info" %} For the following command \ is found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table {% endhint %} ``` attestation.attestors(, ) ``` Status transitions you should expect: `Idle` → `Waiting` → `Active`. {% hint style="warning" %} After your Attestor is running and has marked itself as `Waiting` it won't be added to the active set until the end of the current epoch. Epochs last 12 hours on Creditcoin 3. You can see the current time until the next epoch on the Polkadot.js Apps explorer (Network → Explorer) for your network - use the RPC for your chain from the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table. {% endhint %} You can also check the active set: {% hint style="info" %} For the following command \ is found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table {% endhint %} ``` attestation.activeAttestors() # your address appears once Active ``` 3. **Query the metrics endpoint** (the API port you exposed): ``` curl http://localhost:9100/metrics ``` If you reach `Waiting` but never `Active`, the most common cause under `AuthorizedOnly` is that authorization (Step 4) didn't complete, or an election hasn't run yet. Elections happen at epoch boundaries. ### Attestor lifecycle reference | State | Meaning | How you reach it | | ------------------ | ----------------------------------------------------------------- | ----------------------------------------------------- | | *(not registered)* | No on-chain Attestor entry | n/a | | `Idle` | Registered, but not signaling readiness | `register_attestor` (Step 5) | | `Waiting` | Signaled readiness (BLS key + proof submitted), awaiting election | The **node** auto-submits `attest()` on startup | | `Active` | Elected; committing attestations and earning rewards | Election promotes a `Waiting` **authorized** Attestor | | `Leaving` | Voluntary chill scheduled | `chill` | Key point: **the node only automates the** `Idle` **→** `Waiting` **transition** (it submits the `attest()` extrinsic with your BLS public key and proof of possession). Everything before `Idle` (authorize, register, fund) is done out-of-band, as described above. To stop attesting cleanly:\ 1\. Submit `attestation.chill(, )` from your Attestor stash account. If your Attestor was Active, it moves to Leaving and becomes Idle at the next epoch boundary (epochs last 12 hours); if it was only Waiting, it becomes Idle immediately.\ 2\. Once status shows Idle, stop the Attestor container.\ 3\. (Optional) If you don't intend to restart your Attestor then call `attestation.unregister_attestor(, )` from your stash account.\ 5\. Finally, you can withdraw your stash by calling `attestation.withdraw_unbonded()` - No parameters - from your stash account. Look for the attestation. Withdrawn event to confirm that the funds have been released. ### Configuration reference | Config file | CLI flag | Env var | Req. | Default | Notes | | -------------------------- | ------------------------ | ------------------------------- | ---- | -------------- | -------------------------------------------------------------------------------------------------------------------- | | `attestor.name` | `--name` | `ATTESTOR_NAME` | Yes | n/a | Display/debug name | | `attestor.chain_key` | `--chain-key` | `ATTESTOR_CHAIN_KEY` | Yes | n/a | See [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table | | `attestor.secret` | `--secret` | `ATTESTOR_SECRET` | No | random | BIP-39 mnemonic or `0x` 32-byte hex seed. Always set it for a real Attestor | | `attestor.public_addr` | `--public-addr` | `ATTESTOR_PUBLIC_ADDRESS` | No | OS-assigned | Stable public address peers dial back | | `attestor.logs` | `--logs` | `ATTESTOR_LOGS` | No | `./logs` | Log folder | | `api.port` | `--api-port` | `ATTESTOR_API_PORT` | No | `9100` | `/metrics` endpoint | | `p2p.port` | `--p2p-port` | `ATTESTOR_P2P_PORT` | No | `9000` | libp2p listen port (open it!) | | `p2p.boot_nodes` | `--boot-nodes` | `ATTESTOR_BOOT_NODES` | No | none | Peer discovery; get from the Creditcoin team | | `p2p.no_mdns` | `--no-mdns` | `ATTESTOR_NO_MDNS` | No | false | Disable local mDNS discovery | | `eth.url` | `--eth-url` | `ATTESTOR_ETH_URL` | Yes | n/a | Ethereum Mainnet WS RPC | | `cc3.url` | `--cc3-url` | `ATTESTOR_CC3_URL` | Yes | n/a | CC3 mainnet WS RPC | | `attestation.start_height` | `--start-height` | `ATTESTOR_START_HEIGHT` | No | chain genesis | Override first source height | | `attestation.interval` | `--attestation-interval` | `ATTESTOR_ATTESTATION_INTERVAL` | No | on-chain value | Override attestation interval | By default the Attestor masks RPC URLs in its logs to avoid leaking API keys. Pass `--expose-urls-in-logs` only when debugging in a private environment. **Verifying the chain key** Chain keys are assigned when a source chain is registered on-chain, so confirm the value for Ethereum Mainnet before configuring `chain_key`. In Polkadot.js Apps → *Developer → Chain state*, inspect the `supportedChains` pallet storage (the registered chains list) and match Ethereum Mainnet's chain ID (`1`) to its chain key. The chain key depends on which CC3 chain you are running your Attestor on. The current chain keys for Ethereum Mainnet are found in the [per-chain settings](/attestcoin-protocol/attestcoin-protocol-operator-guides/per-chain-attestor-settings) table. ### Troubleshooting **`⛔ Attestor has insufficient balance` (and the node exits)** Your free balance is under 1 CTC. Top up the account (Step 3) and restart. We recommend keeping \~10 CTC so that occasional non-refunded fees never drop you below the floor. **`register_attestor` fails with `NotPreAuthorizedToRegister`** Your account isn't authorized yet. Complete Step 4 with the Creditcoin team, confirm `attestation.authorizedAttestors(, )` is populated, then retry registration. **`register_attestor` fails with `AlreadyAttestor`** You're already registered for this chain key. Skip to running the node. **Node logs `Attestor status is already ..., skipping attest()`** The node only submits `attest()` from the `Idle` state. If status is `None` (not registered) it won't register for you; go do Step 5. If it's already `Waiting`/`Active`, this is normal. **Stuck at `Waiting`, never `Active`** Either no election has run yet (they occur at epoch boundaries; wait for the next one), or your account is registered but **not authorized** (re-check Step 4). Under `AuthorizedOnly`, unauthorized `Waiting` Attestors are skipped at election time. **No peers / P2P connection issues** Confirm your P2P port (`9000`) is open inbound, the boot node multiaddr is the current one from the Creditcoin team, and (if behind NAT) you've set `public_addr` to a reachable hostname/IP. **RPC connection errors** Verify the `cc3.url` and `eth.url` endpoints are reachable from the container and are **WebSocket** URLs (`ws://` / `wss://`). If you are using a public endpoint, you may be hitting rate limits; consider moving to your own node. ### Quick summary checklist * Generate sr25519 account; back up mnemonic (Step 1) * Set up RPC endpoints: Creditcoin's public CC3 RPC or your own CC3 node, plus an external Ethereum Mainnet RPC (Step 2) * Fund the Attestor account with at least \~10 CTC (hard minimum 1 CTC), and the stash account with atleast `MinBondRequirement` (Step 3) * Send your SS58 address and the chain key from the per-chain settings table to the Creditcoin team for authorize\_attestor (Step 4). Only Ethereum Mainnet is supported at the time of writing. * Submit `register_attestor(, )` yourself (Step 5) * Run the Attestor container with your config (Step 6) * Confirm `Idle` → `Waiting` → `Active` and a healthy `/metrics` (Step 7) # Per-chain Attestor Settings Allows Attestor operator guide to be used with CC3 Mainnet or CC3 Testnet The Attestor operator guide should be chain agnostic, supporting attestor setup on CC3 Mainnet or CC3 Testnet. To allow for this, we outline the resources for Mainnet and Testnet here.
Setting\Resource NameFor MainnetFor Testnet
Creditcoin Release Image (as of 07/08/26)3.128.0-mainnet3.128.0-testnet
Eth Mainnet Chain Key13
Public Creditcoin3 Rpcwss://rpc.cc3-mainnet.creditcoin.networkwss://rpc.cc3-testnet.creditcoin.network
Polkadot.js Apps UI Linkhttps://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmainnet3.creditcoin.network#/explorerhttps://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.cc3-testnet.creditcoin.network#/explorer
# Attestcoin Design Diagrams Diagrams intended as further reading for the Attestcoin Whitepaper. 1. Readability Sequence Diagram (See [Readability section](/attestcoin-protocol/attestcoin-readability) for more details) {% @plantuml/diagram content=" @startuml CC3 !pragma teoz true Actor Claimer participant "Client Side CC3 Library\n (glorified web3 wrapper)" as Client box CC3 #lightblue participant Node database "On-chain storage" as Onchain box EVM #skyblue participant "Prover SC\n \[\[ link]]" as ProverSC end box box Proof-verifier #skyBlue participant "Proof-verifier\n precompile\n \[\[ link]]" as ProofVerifier end box end box participant "Attestors" as Attest database "Ethereum Data" as Eth participant Prover database ProverDb group #lightgrey Attestation Process Attest -> Attest: \[\[file://./Attestation.plantuml Attestation]] end Attest -> Node: Attestation/Checkpoint generated Node -> Prover: Notify about attestation/checkpoint Prover -> ProverDb: Cache attestation/checkpoint skinparam responseMessageBelowArrow true Claimer -> Client: Record ERC20 tx\n tx hash (String/Hash) note left Claimer wants to record on CC3 that they sent ERC20 transfer on ethereum. They provide the Eth transaction hash, together with the block number. end note Client -> Eth: Fetch block containing tx Eth -> Client: Get back the block and tx data Client -> Client: Location of tx in ethereum block Client -> ProverSC: Submit signed transaction with query information\ntx\_hash, chain\_id, block\_num, layout segments ProverSC -> ProverSC: Store query ProverSC <--> Prover: Query submitted event Prover -> Eth: Fetch queried block info Prover -> ProverDb: Fetch relevant checkpint/attestation info Prover -> Prover: Check query for continuity ref over Prover, Prover: \[\[file://./ContinuityProof.plantuml Continuity Proof]] Prover -> Prover: Check query for inclusion ref over Prover, Prover: \[\[file://./InclusionProof.plantuml Inclusion Proof]] Prover -> ProverSC: Submit query proof ProverSC -> ProofVerifier: Verify query proof ProofVerifier -> ProverSC: Return verification result ProverSC -> ProverSC: Store query proof results ProverSC -> Client: Return query proof results Client -> Claimer: Return requested proof results @enduml" %} 2. Continuity Proof Diagram (See [Continuity Proving Doc](/attestcoin-protocol/attestcoin-readability/step-1-attestation/continuity-proving-for-attestation) for more details) {% @plantuml/diagram content=" @startuml continuity-proof title Continuity Proof for Attestation\nBridging the gap between two sparse attestations on a source chain skinparam shadowing false skinparam roundcorner 8 skinparam defaultTextAlignment center skinparam ArrowColor #444444 skinparam rectangle { BorderColor #444444 } ' ---- Anchors: the sparse, on-chain finalized attestations / checkpoints ---- rectangle "Last finalized attestation\n(or checkpoint)\n\nblock N\ndigest = D(N)" as ANCHOR\_L #D5E8D4 rectangle "New attestation\n\nblock N+k\nprev\_digest = D(N+k-1)\ndigest = D(N+k)" as ANCHOR\_R #D5E8D4 ' ---- The continuity proof: only merkle roots are transmitted ---- package "Continuity Proof (lowerEndpointDigest, roots\[])" #EEF5FF { rectangle "block N+1\nroot r1\n=> D(N+1)" as B1 #FFF2CC rectangle "block N+2\nroot r2\n=> D(N+2)" as B2 #FFF2CC rectangle " ... \nroots\[i]" as BDOTS #FFF2CC rectangle "block N+k-1\nroot r(k-1)\n=> D(N+k-1)" as BK #FFF2CC } ' ---- The digest hash-chain: each digest binds the previous one ---- ANCHOR\_L -right-> B1 : lowerEndpointDigest = D(N) B1 -right-> B2 : prev = D(N+1) B2 -right-> BDOTS : prev = D(N+2) BDOTS -right-> BK : prev = D(N+k-2) BK -right-> ANCHOR\_R : reconstructed D(N+k-1)\nmust equal prev\_digest note bottom of B2 Digest chain (computed on-chain, roots are NOT trusted): **D(i) = keccak256( blockNumber\_i || merkleRoot\_i || D(i-1) )** Changing any block/root breaks every later digest. end note note bottom of ANCHOR\_L Attestations are produced sparsely (e.g. every 10 or 100 blocks) to save cost & bandwidth. The proof fills the gap. end note note bottom of ANCHOR\_R On-chain verification: 1. tail's prev\_digest (= lowerEndpointDigest) points to a known finalized attestation / checkpoint at block N 2. reconstruct the whole chain from roots 3. final digest D(N+k-1) == new attestation prev\_digest Honest attestors converge on the same final digest; bogus blocks yield a different digest and fail quorum. end note @enduml " %} 3. Transaction Proof Payload Diagram (See [Transaction Proving Section](/attestcoin-protocol/attestcoin-readability/step-2-transaction-proving) for more details) {% @plantuml/diagram content=" @startuml event-proof-package-overview title Event Proof Package — end-to-end\nProving a source-chain transaction/event to an Attestcoin Smart Contract (ASC) skinparam shadowing false skinparam roundcorner 8 skinparam defaultTextAlignment center skinparam ArrowColor #444444 skinparam rectangle { BorderColor #444444 } skinparam package { BorderColor #6C8EBF BackgroundColor #EEF5FF } ' ---- Source chain ---- rectangle "Source chain (e.g. Ethereum)\n\nblock matures at height H\ncontains the target tx & receipt\n(emits event such as: TokensBurnedForBridging)" as SRC #FFF2CC ' ---- Off-chain proof builder ---- rectangle "Off-chain Proof Builder\n(proof-gen-api / usc-sdk)\n\nQuery requesting proof: (chainKey, height H, txIndex)" as BUILDER #DAE8FC ' ---- The proof package ---- package "Event Proof Package (submitted to the ASC)" as PKG { rectangle "**encodedTransaction**\nABI(txType, chunks\[])\ntx fields + receipt fields\n(status, logs, logsBloom)" as ENC #FFE6CC rectangle "**MerkleProof**\nroot + siblings\[]\n=> proves tx is IN the block" as MP #D5E8D4 rectangle "**ContinuityProof**\nlowerEndpointDigest + roots\[]\n=> proves block is in attested chain" as CP #D5E8D4 } ' ---- ASC + precompile ---- rectangle "Attestcoin Smart Contract (ASC)\non Creditcoin" as ASC #E1D5E7 rectangle "Native Query Verifier precompile\n(0x…0FD2 / BlockProver)\n\nverify(chainKey, H, encodedTx,\n merkleProof, continuityProof)" as PC #E1D5E7 rectangle "On-chain Attestations / Checkpoints\n(pallet-attestation storage)" as ATT #D5E8D4 SRC -down-> BUILDER : fetch block, tx, receipt,\ncompute roots & digests BUILDER -down-> PKG : build 3-part package PKG -down-> ASC : dApp call with proof package ASC -right-> PC : forward proofs PC -up-> ATT : final digest must match\nan attestation/checkpoint PC -down-> ASC : returns true (or reverts) note bottom of ASC On success the ASC **decodes encodedTransaction** and acts on it: reads receipt **status** (1 = success) and scans **logs** for the event (e.g. TokensBurnedForBridging(burnedFrom, amount)), then runs its business logic (e.g. mint bridged tokens). See: merkle-proof-inclusion, proof-verification-pipeline, encoded-tx-rx-decoding. end note @enduml" %} 4. Writability Sequence Diagram
5. Writability With Acknowledgement (Acknowledgement part of flow uses readability)
6. Bridging tokens from External Chain A to External Chain B using the Attestcoin Protocol \ Simplified path:\ 1\. Readability read from Chain A -> Attestcoin Smart Contract on Creditcoin\ 2\. ASC sends writability message -> Chain B receives\ 3\. Readability carries message acknowledgement from Chain B back to ASC on Creditcoin {% @plantuml/diagram content=" @startuml bridge-with-readability title Bridge with Readability\nA proven burn on Chain A (READABILITY) triggers a mint on Chain B (WRITABILITY) autonumber skinparam shadowing false skinparam sequenceMessageAlign center skinparam ParticipantPadding 12 skinparam BoxPadding 12 skinparam maxMessageSize 220 box "Source Chain A (origin)" #FFF7E6 actor "User" as U participant "Bridge dApp" as BD participant "TokenA contract" as TA end box box "Creditcoin — Readability\n(attestation + transaction proving)" #EEF5FF participant "Readability Attestors\n(block attestation +\ncontinuity proofs)" as RATT participant "Proof Builder (off-chain)" as PB participant "Creditcoin Chain\n+ NativeQueryVerifier\nprecompile" as CC participant "ASC Bridge contract" as USC end box box "Creditcoin — Writability" #F3E6FF participant "Relayer Contract\n+ Quotation System" as RC participant "Outbox\n(one per source chain)" as OUT participant "Message Attestors\n+ Voting Layer" as MATT end box box "Relay" #F0F0F0 participant "Message Relayer" as REL end box box "Source Chain B (destination)" #E6FFE6 participant "Inbox contract" as INB participant "TokenB contract\n(target)" as TB end box \== 1) Burn on the origin chain (Chain A) == U -> BD : request bridge(amount, toChainB, recipient) BD -> TA : bridge(amount, toChainB, recipient) TA -> TA : burn(amount)\n**emit TokensBurnedForBridging(burnedFrom, amount)** note over TA: tx & receipt land in a Chain A block @ height H \== 2) READABILITY — attest & prove the burn to the ASC == BD -> CC : wait for attestation of block H on Creditcoin RATT -> RATT : attest Chain A blocks,\nbuild continuity proofs,\nreach consensus RATT -> CC : submit attestation (stored on Creditcoin) note over CC: after sumbissions, block with\nheight H is attested on Creditcoin CC -> BD : block H attested on Creditcoin BD -> PB : request proof package for tx at height H PB -> CC : read attested source-chain state PB -> PB : build **proof package**\n{ encodedTx/rx, MerkleProof, ContinuityProof } PB -> BD : return **proof package**\n{ encodedTx/rx, MerkleProof, ContinuityProof } BD -> USC : submit proof package (chainKey=A, height H, txIndex) USC -> USC : verify(): Merkle inclusion +\ncontinuity chain -> attestation/checkpoint USC -> USC : decode receipt: require status==1,\nmatch log TokensBurnedForBridging\n-> (burnedFrom, amount) note over RATT, USC #D5E8D4: The burn on Chain A is now cryptographically proven on Creditcoin \== 3) WRITABILITY — the verified burn triggers a cross-chain message == BD -> RC : request quote (deliver mint to Chain B) RC -> BD : signed quote (gas + fees) BD -> OUT : publishMessage(payload = mint `amount` to `recipient` on B)\n+ pay quoted fee OUT -> BD : **emit MessagePublished(msgId, payload)** BD -> U : report bridge completion on Chain A\n\*\*\[bridge complete]\*\* \== 4) Message attestation & voting == MATT -> OUT : observe MessagePublished MATT -> MATT : sign + vote + gossip over p2p MATT -> MATT : threshold reached\n**emit MessageReady(msgId)** \== 5) Relay & deliver on the destination chain (Chain B) == REL -> MATT : pick up ready message + attestor votes REL -> INB : deliver(msgId, payload, votes/signatures) INB -> INB : validate attestor votes,\ndecode payload INB -> TB : mint / release `amount` to `recipient` TB -> U : recipient credited on Chain B \[bridge complete] \== 6) (optional) Acknowledgement — READABILITY used again == INB -> INB : **emit MessageDelivered(msgId)** note over REL, USC #FFF2CC Relayer waits for Chain B finality, then submits a query proof of MessageDelivered (same readability path: Merkle + continuity) to the Outbox's Validator. On valid proof the Outbox emits **MessageAcknowledged(msgId)**, which the dApp reports back to the User. end note OUT -> BD : emit MessageAcknowledged(msgId) BD -> U : report bridge completion with acknowledgement @enduml" %} # Environments A node can be configured to connect to different Creditcoin networks. Each network has different configurations and use cases. | | | | | | ------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------- | | Overview | Local/public development environment | Public testing environment | Live production environment | | Users | Developers | Developers & testers | End users | | Function | To develop new features & improvements | To test new features & improvements | To secure credit history on-chain | | Tokens | Test tokens with no real world economic value | Test tokens with no real world economic value | Real tokens with economic value | | Chain history | Wiped frequently | Wiped occasionally | Preserved | The network configuration is specified using the `--chain` flag and the `--bootnodes` flag, which specifies the initial nodes to connect to. ### **ChainSpecs** Creditcoin networks are configured using a `ChainSpec`. The `ChainSpec` is a JSON file that defines the initial configuration of the network. To use a `ChainSpec`, use the `--chain` flag when starting the node. ### **Bootnodes** Bootnodes are nodes that are always on and can be used to bootstrap new nodes and discover other nodes in the network. To use a bootnode, use the `--bootnodes` flag when starting the node followed by the bootnode's address. ### ChainSpec and Bootnode values to use for Mainnet and Testnet For a list of available bootnodes, please refer to the Mainnet and Testnet quickstart documents. * [Mainnet Quickstart](/environments/mainnet) * [Testnet Quickstart](/environments/testnet) # Mainnet Creditcoin operates a Mainnet bootnode and RPCs, as well as a few nodes in two regions. ### Quickstart - Mainnet For a more detailed guide on how to connect to mainnet, please refer to the [Validator Guides](/validator-guides) Summary of essential Mainnet urls and configurations:
NameValue
Subscan (Substrate Explorer)https://creditcoin.subscan.io/
Blockscout (EVM Explorer)https://creditcoin.blockscout.com/
Staking Dashboardhttps://staking.creditcoin.org/#/overview
PolkadotJS AppsListed under "LIVE NETWORKS" as Creditcoin
Telemetryhttps://telemetry.creditcoin.network/#list/0x4436a7d64e363df85e065a894721002a86643283f9707338bf195d360ba2ee71
Latest Docker Imagegluwa/creditcoin3/3.131.0-mainnet
Bootnode 1/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWLGyvbdQ3wTGjRAEueFsDnstZnV8fN3iyPTmHeyswSPGy
Bootnode 2/dns4/cc3-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWBp9zYL1zf2rKYgCepLubeWBH2zV7kJn7Pvebn6PvfmxP
RPCwss://mainnet3.creditcoin.network
--chain/mainnetSpecRaw.json
EVM ChainId102030
Min Validator Bond0
Min Join Pool Bond0
Min Solo Nominator Bond1000 CTC
Min Pool Creation Bond10000 CTC
### ASC
ASC Dashboardhttps://dashboard.cc3-mainnet-usc.creditcoin.network/
Proof Builder APIhttps://proofbuilder.cc3-mainnet-usc.creditcoin.network/
Decoder contract0x9D094C9f22B10FCf842c2fC6A0981630A4F94B5C
| **Supported Mainnet Chains** | **Chainkey** | **Genesis Block** | | ---------------------------- | ------------ | ----------------- | | Ethereum Mainnet | 1 | 0 | # Testnet Creditcoin Testnet usually runs newer versions of the Creditcoin runtime which are under active development and testing. It is the recommended network to try out new features. ### Quickstart - Testnet
NameValue
Subscan (Substrate Explorer)https://creditcoin3-testnet.subscan.io/
Blockscout (EVM Explorer)https://creditcoin-testnet.blockscout.com/
Staking Dashboard

https://staking.creditcoin.org/

Select Testnet in the Network select at the bottom of the menu

PolkadotJS AppsListed under "TEST NETWORKS" as Creditcoin Testnet
Telemetryhttps://telemetry.creditcoin.network/#list/0xfc4ec97a1c1f119c4353aecb4a17c7c0cf7b40d5d660143d8bad9117e9866572
Latest Docker Imagegluwa/creditcoin3:3.131.0-testnet
Bootnode 1/dns4/cc3-test-bootnode.creditcoin.network/tcp/30333/p2p/12D3KooWAxmsWr6iEjFyLqQBzfLvbCRTAhYBeszyr8UWgQx6Zu7K
Minimum @polkadot/api version16.1.1
RPCwss://rpc.cc3-testnet.creditcoin.network
--chaintestnet
EVM ChainId102031
Min Validator Bond20000 tCTC
Min Join Pool Bond0
Min Solo Nominator Bond19500 tCTC
Min Pool Creation Bond19500 tCTC
### Quickstart - ASC on cc3 testnet
NameValue
Dashboardhttps://dashboard.cc3-testnet.creditcoin.network/
USC SDK js (Attestcoin SDK)https://www.npmjs.com/package/@gluwa/usc-sdk
Proof generator api

https://prover.cc3-testnet.creditcoin.network/

or
https://proof-gen-api.cc3-testnet.creditcoin.network/

Verify Precompilehttps://creditcoin-testnet.blockscout.com/address/0x0000000000000000000000000000000000000FD2?tab=contract
Code Exampleshttps://github.com/gluwa/usc-testnet-bridge-examples
Video tutorialshttps://docs.creditcoin.org/usc/quickstart/usc-tutorials
| **Supported Mainnet Chains** | **Chainkey** | **Genesis Block** | | ---------------------------- | ------------ | ----------------- | | Ethereum Sepolia | 1 | 0 | | Ethereum Mainnet | 3 | 0 | # Technical Specification CC3 Mainnet Technical Specification This page provides a comprehensive overview of Creditcoin's core network metrics and protocol parameters on Mainnet. Whether you're building on Creditcoin or integrating EVM-compatible applications, the data below offers additional insight into the performance, scalability, and technical structure of the blockchain.
MetricValue
Frontier versionCurrent: stable2409
EVM CompatibilityYes
PolkadotSDK versionCurrent: polkadot-stable2409
ConsensusPoS
Block time15s
Finality time1-3 blocks
TPS - Substrate with full EVM use~350 tps *
TPS - Substrate with no EVM use~1400 tps *
TPS - ERC20 Transfers filled blocks100 tps **
TPS - Simple eth transfers filled blocks238 tps **
TPS - Simple eth transfers filled blocks
Using batch transfers		745 tps **
On-Chain Data Size~150g as of February 2026
Supported EIPs

EIP-20 (ERC-20), EIP-721 (NFTs), EIP-1155 (ERC-1155)

EIP-1559, EIP-4337, EIP-712, EIP-1271, EIP-7913

BLOCK_GAS_LIMIT75_000_000
Epoch2880 blocks
Era2 epochs
Base gas price0.5 gwei
Elasticity

125_000

lower() 0

ideal() 500_000

upper() 1_000_000

Peak Observed EVM volume~375k transactions in a day
Peak Observed Substrate volume~400k extrinsics in a day
Substrate extrinsics fee0.015932248 CTC for basic balance transfer

Substrate large data input fee

per megabyte

110 CTC
EVM Transaction fee

Varies based on gas price, which varies based on % fill of recent blocks

Formula

Current gas price in wei * (estimated native transfer gas unit) / (decimals)

Example with base fee for a simple transfer, assuming base gas price of 0.5 gwei

500000000*21000/(10^18) = 0.0000105 CTC

\* May vary depending on factors such as other concurrent volume, type of transactions and extrinsics. \*\* Capacity calculated based on BLOCK\_GAS\_LIMIT, which can be increased to a desired value. # MiCA Creditcoin's MiCA report 1. [Creditcoin](#id-1.-creditcoin) 2. [MiCA](#id-2.-mica) 3. [Methodology](#id-3.-methodology) * [Hardware](#id-3.1.-hardware) * [Foundation power usage](#id-3.2.-creditcoin-foundation-power-usage) * [Community power usage](#id-3.3.-community-power-usage) * [Auxiliary energy use](#id-3.4.-remarks-on-energy-consumption-of-auxiliary-components) 4. [Total and per transaction energy report](#id-4.-report-on-total-energy-consumption-and-energy-used-per-transaction) ### **1. Creditcoin** Creditcoin is a PoS (Proof of Stake) Layer 1 blockchain empowering organizations with bold missions to achieve greater global social impact. Creditcoin is EVM-compatible, so anyone can program new smart contracts for Creditcoin using the same programming language and techniques used by Ethereum and other EVM-compatible blockchains. ### **2. MiCA** The EU Markets in Crypto-Assets (MiCA) regulation mandates that token issuers and crypto-asset service providers (CASPs) provide disclosures related to resource use and sustainability. ### 3. Methodology In order to estimate the power consumption of the entire network, this methodology estimates and combine power consumption by components operated by the Creditcoin Foundation, as well as components operated by our community. Since Creditcoin is a Decentralized Network, community members are welcome to operate blockchain components which can include: * General archive or full nodes * RPCs (remote procedure call) nodes * Bootnodes * Validators The methodology is summarized by those steps: 1. Obtain power consumption information for recommended hardware 2. Estimate energy consumption by components operated by the Foundation 3. Estimate energy consumption by components operated by the Community 4. Remarks on energy consumption of auxiliary components #### 3.1. Hardware **Recommended specs** The Creditcoin Foundation has hardware recommendations in its Developer Guide which will be used in this document to calculate the Community’s power consumption as well as parts of the Foundation’s operated components. The minimum specs recommended is: * Intel Core i5-8400 6 Cores @ 2.8Ghz \*\* The recommended processor has a TDP (W) of 65. Due to the decentralized nature of Blockchains, it is not possible to obtain specific hardware specification of Community members hardware. The most accurate total power consumption figures can be obtained by using the recommended processor since while some community members may run slightly different specs, they can’t run specs that deviate significantly from the recommendations. If they did, they would either not have a strong enough machine to operate their components or they would have economic disincentives to do so. **Data collection and metrics** The Creditcoin Foundation operates components to provide services to the community and to participate in its decentralized network. The Foundation collects metrics of the components it operates, for technical as well as environmental purposes. The data collected includes the percentage usage of resources such as CPU, which can then be combined with the power consumption disclosures by chip makers to provide more accurate estimates of power consumption. RPCs - The Foundation currently operates 12 RPCs. Its 30 days average ***mCPU*** (used to determine % CPU used) usage is 81. We then can use that number to divide the TDP, to obtain a more accurate estimated power consumption per RPC. | Total CPU available | 6000 mCPU | | ---------------------------------- | --------------- | | CPU ***TDP*** (W) | 65 | | Power usage per mCPU used (W/mCPU) | 0.01083333333 W | | RAM Average Power Use (W/GB) | 0.3125 W | \ **30 days average CPU power usage for one RPC instance in Watts** \= Power usage per mCPU used \* avg used mCPU = 0.01083333333 \* 81 = **0.877 Watts.** Validators - The Foundation currently operates 3 validators and up to 10 other nodes such as archive and bootnodes. Its 30 days average mCPU (milli CPU which can be interpreted as % used) usage is 152. We then can use that number to divide the TDP, to obtain a more accurate estimation of power used per validator or general nodes. **30 days average power usage for one validator or general node in Watts** \= Power usage per mCPU used \* avg used mCPU = 0.01083333333 \* 152 = **1.646 Watts.** **RAM power usage per node, based on recommended specs** \= Power usage per GB \* RAM size = 0.3125 \* 8 = **2.5 Watts.** #### **3.2. Creditcoin Foundation power usage** The current total power consumption of the Blockchain components operated by the Foundation can be obtained by multiplying the power consumption of one node type by the number of instances. | **Blockchain node type** | **CPU power consumption per node** | **RAM power consumption** | **Instances** | **Total CPU power consumption** | **Total RAM power consumption** | **Total Daily power consumption** | | -------------------------------------------------- | ---------------------------------- | ------------------------- | ------------- | ------------------------------- | ------------------------------- | --------------------------------- | | RPC | 0.877 Watts | 2.5 Watts | 12 | 10.52 Watts | 30 Watts | 0.97 kWh | |

Validator

Bootnode

Archive node

| 1.646 Watts | 2.5 Watts | 13 | 21.39 Watts | 32.5 Watts | 1.29 kWh | #### **3.3. Community power usage** Due to the decentralized architecture of the Creditcoin blockchain, it can be challenging to know exactly how many nodes are running at any given time. However, we estimate based on the following facts and presumptions: * Community members operate their nodes with recommended specs * 47 validators are currently operated by the community * On average, 5 validators are in the waiting set to become one of the 50 active validators * The community mostly operates validators, but it can run other type of nodes if it desires. Based on those assumptions, we can obtain the power consumption of the community with: | **Blockchain node type** | **CPU power consumption per node** | **RAM power consumption** | **Instances** | **Total CPU power consumption** | **Total RAM power consumption** | **Total Daily power consumption** | | ------------------------ | ---------------------------------- | ------------------------- | ------------- | ------------------------------- | ------------------------------- | --------------------------------- | | Active Validators | 1.646 Watts | 2.5 Watts | 47 | 77.36 Watts | 117.5 Watts | 4.67 kWh | | Waiting Validators | 1.646 Watts | 2.5 Watts | 5 | 8.23 Watts | 12.5 Watts | 0.50 kWh | #### **3.4. Remarks on energy consumption of auxiliary components** This document aims to give a comprehensive energy consumption of the energy requirements of operating the Creditcoin blockchain. Typically, blockchains also have auxiliary components such as explorers, wallets, dashboards and other websites and third party components operated specifically for a given blockchain or provided as a service that can adapt and connect to multiple blockchains. The ecosystem surrounding the Creditcoin blockchain does include components such as explorers and wallets. However, since they do not typically scale with the number of nodes or transaction on a blockchain, those components will not be included as part of the calculation of the energy consumption of the blockchain. ### **4. Report on total energy consumption and energy used per transaction** Now that we have obtained energy consumption per component as well as for the entire blockchain operations, we can obtain power usage per transactions, by dividing the total power consumption by the amount of transactions finalized per day. Summary of power consumption:
Blockchain node typeFoundation kWhCommunity kWhDaily Total kWh
RPC0.97 kWh-0.97 kWh

Validator

Bootnode

Archive node

1.29 kWh5.17 kWh6.46 kWh
Total: 7.43 kWh *
Summary of transactions count: Average daily transactions (Available on Subscan): 151,366 Estimated power consumed per transaction: \= Daily energy / Daily avg txns = 7.43 kWh / 151366 = 4.90e-5 kWh As adoption and usage of the blockchain increases, power consumption may slightly increase. However, we want to highlight that it will not increase linearly with transaction count. Transactions increase would need to very significant for the current recommended specs to no longer be sufficient to operate nodes, which would be the primary driver of increasing energy demand. In conclusion, it is good to reiterate that due to the decentralized nature of a blockchain, the amount of nodes operated by the community and the Foundation is subject to change. Community members are free to join and leave the network as they wish, using hardware of their choice. The power consumption of the entire network thus varies from one moment to another. However, the data collected by the Creditcoin Foundation operating its own nodes, combined with its recommended specs, provide valuable insights in the Creditcoin blockchain energy consumption. *** \* Due to variability in hardware configurations and usage patterns, actual consumption may vary ±10–15%. \*\* Subject to change. Equivalent or slightly different specs may provide sufficient and comparable performance for comparable energy used. **Definitions** ***TDP*** (Thermal Design Power) is used as a proxy for maximum CPU power draw. Actual usage is based on reported average utilization. ***mCPU*** stands for "milliCPU" and represents a thousandth of a CPU core # Releases This page lists and describes Docker Images created after the public launch. {% hint style="warning" %} Creditcoin docker image numbers may not be consecutive since some internal versions are not publicly released. We recommend to always use the latest version number available. {% endhint %} ### Mainnet Docker Images Releases
VersionReleased onChange
3.131.0-mainnet2026-08-06
  • Attestor network improvements
  • Dependency update
3.130.0-mainnet2026-07-29
  • Attestor improvements
3.128.0-mainnet2026-07-13
  • Improved precompiles
  • Hardened attestor registration
3.125-mainnet2026-06-18
  • Launched USC protocol layer
3.125-mainnet2026-06-16
3.66.0-mainnet2026-05-15
  • Dependency update
  • Precompile improvements
3.65.0-mainnet2026-05-15
  • Dependency update
3.64.0-mainnet2026-04-15
  • Added ed25519-verifier precompiled smart contract
3.61.0-mainnet2026-02-03
  • Added signature-verifier precompile smart contract
  • Added bn128 precompile smart contracts
  • Migrated pallets Grandpa and Staking
  • Updated dependencies
3.55.0-mainnet*2025-09-19
  • Minor node logs display bug fix
3.54.0-mainnet2025-09-18
  • Migrating pallet-identity
3.52.0-mainnet2025-09-16
  • Introduced Ledger compatibility
  • Introduced "Paged" staking rewards
  • Improved Staking Dashboard user experience
  • Introduced a new CLI for checking validator rewards
  • Updated dependencies to a new stable version of polkadot-sdk (Core, Node, CLI)
3.39.0-mainnet2025-01-22
  • Payout Stakers fee reduction. Other fees adjustments
  • Improved dependencies
3.35.0-mainnet2024-11-06
  • Improved Blockscout log decoding for EVM to Substrate transfers (precompile calls)
  • Improved dependencies upgrade flow
3.32.0-mainnet2024-08-28
  • Added EVM compatibility.
  • Introduced an EVM Explorer (Blockscout)
  • Added Staking Pools support
  • Improved Staking Dashboard user experience
  • Improved CLI user experience
  • Created a precompile to streamline EVM to Substrate transfers
  • Updated CI pipelines to increase efficiency
  • Updated tests (Core, CLI) to increase coverage
  • Updated various dependencies (Core, CLI)
\* - minimum recommended version ### Testnet Docker Images Releases
VersionReleased onChange
3.131.0-testnet2026-08-04
  • Attestor network improvements
  • Depencency update
3.130.0-testnet2026-07-22
  • Attestor improvements
  • Dependency update
3.128.0-testnet2026-07-08
  • Dependency update
3.127.0-testnet2026-06-29
  • Dependency update
  • USC improvements (Proof Builder + attestors)
  • Precompiles improvements
3.125.0-testnet2026-06-01
  • Dependency update
  • USC improvements (Prover + attestors)
3.121.0-testnet2026-05-15
  • Dependency update
  • Precompiles improvements
3.116.0-testnet2026-05-05
  • USC Launch
3.114.0-testnet2026-05-01
3.65.0-testnet2026-04-24
  • Dependency update
3.64.0-testnet2026-04-09
  • Added ed25519-verifier precompile smart contract
3.61.0-testnet2026-01-30
  • Dependency update
3.60.0-testnet2026-01-19
  • Added signature-verifier precompile smart contract
  • Added bn128 precompile smart contracts
  • Migrated pallets Grandpa and Staking
3.55.0-testnet2025-09-18
  • Minor node logs display bug fix
3.54.0-testnet2025-09-17
  • Migrating pallet-identity
3.52.0-testnet2025-08-11
  • Increased Payout.stakers to pages of 512 instead of 64
3.48.0-testnet2025-07-29
  • Adjustment of EVM base fee back to what they were before 3.42.0
  • Upgraded dependencies
  • balance.transfer extrinsic was removed
  • Fee estimation of payout.stakers was lowered
  • Ledger support was enabled on Testnet
  • Payout.stakers will now needed to be executed more than once for validators with > 64 nominators
  • New validator nodes will no longer generate network key automatically on start-up.
3.42.0-testnet2025-03-13
  • Adjustments to EVM base fee to bring closer to Substrate fees
3.39.0-testnet2024-11-18
  • Payout Stakers fee reduction. Other fees adjustments
3.38.0-testnet2024-11-13
  • Adjustments to reduce Staking Rewards Claim and other extrinsics' fees
3.35.0-testnet2024-10-01
  • Improved Blockscout log decoding for EVM to Substrate transfers (precompile calls)
  • Improved dependencies upgrade flow
3.28.0-testnet2024-06-07
  • Improvement on EVM to substrate precompile indexing
3.27.0-testnet2024-05-22
  • CLI improvements.
  • Precompile to facilitate EVM to Substrate transfers.
3.24.0-testnet2024-03-26
  • Minor CLI Unbound command bug fix.
3.23.0-testnet2024-03-20
  • Initial release
# 3.52.0-Mainnet Runtime upgrade 3.52.0-Mainnet was applied on Creditcoin3 Mainnet at Era 384, the 16th of September, 2025. # 3.52.0-Mainnet Considerations ### Introduction Version `mainnet-3.52.0` includes important changes that may temporarily affect polkadot.js functions. The functionalities listed in this document may have a slightly different behavior between era 384 and 469, and will resume to their behavior prior to era 384. Below is a shortlist of potential issues that a user may encounter after this release. Please note the [important API changes](#important-api-changes) introduced by this release. ### Shortlist of potential issues * ["Payouts" page showing inaccurate information](#payouts-page-showing-inaccurate-information) * [Inability to payout a nominator from the "Payouts" page](#inability-to-payout-a-nominator-from-the-payouts-page) #### "Payouts" page showing inaccurate information The latest version is the ["Payouts" page](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmainnet3.creditcoin.network#/staking/payout) displaying inaccurate information regarding the eras for which the validators have pending payouts. Protocol payout functionalities are not affected, only the amounts may be displayed incorrectly in some cases. The Creditcoin team provides a CLI tool that allows you to view the eras where a validator has pending rewards correctly. You can follow the [`validator-rewards`](https://www.npmjs.com/package/@gluwa/validator-rewards) package readme for instructions on installation and running the tool, or follow the steps given below: Run without installing: ``` npx @gluwa/validator-rewards ``` Global install: ``` npm i -g @gluwa/validator-rewards validator-rewards ``` You’ll be asked to select a network: * Mainnet → `wss://mainnet3.creditcoin.network/ws` * Testnet → `wss://rpc.cc3-testnet.creditcoin.network/ws` * Custom → type any `ws://` or `wss://` network URL (prefilled from `.env` if present) Then enter a validator stash (SS58). You’ll see a table like: ``` ┌─────────┬──────┬────────┬──────────────┬─────────────┬────────────┐ │ (index) │ era │ points │ pagesClaimed │ pagesToClaim│ totalPages │ ├─────────┼──────┼────────┼──────────────┼─────────────┼────────────┤ │ 0 │ 578 │ 1234 │ '0' │ 1 │ 2 │ │ 1 │ 579 │ 987 │ '—' │ 1 │ 1 │ └─────────┴──────┴────────┴──────────────┴─────────────┴────────────┘ ``` The tool will display the eras for which the specified validator has pending rewards, together with the number of points accumulated through that era and the number of pages that the validator has to claim #### Inability to payout a nominator from the "Payouts" page If you are an active nominator and you are unable to see the "Payout" button (or if it is grey/not clickable) on the[ "Payouts" page](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmainnet3.creditcoin.network#/staking/payout), and/or the page looks something like this:
Here are alternative ways to claim your rewards. * [Creditcoin staking dashboard](https://cc3-staking.creditcoin.org/#/overview) is always the best way to look and claim your pending rewards, be it a solo nomination or nomination pools. You can check out your rewards under "Pending Payouts" and claim them by pressing the "Claim" button
* Alternatively, if you know the list of the validators that you are nominating, you can use the [`validator-rewards`](https://www.npmjs.com/package/@gluwa/validator-rewards) CLI tool and get the list of the eras for which they have pending rewards: * Run without installing: ``` npx @gluwa/validator-rewards ``` Global install: ``` npm i -g @gluwa/validator-rewards validator-rewards ``` * You’ll be asked to select a network: * Mainnet → `wss://mainnet3.creditcoin.network/ws` * Testnet → `wss://rpc.cc3-testnet.creditcoin.network/ws` * Custom → type any `ws://` or `wss://` network URL (prefilled from `.env` if present) Then enter a validator stash (SS58). You’ll see a table like: ``` ┌─────────┬──────┬────────┬──────────────┬─────────────┬────────────┐ │ (index) │ era │ points │ pagesClaimed │ pagesToClaim│ totalPages │ ├─────────┼──────┼────────┼──────────────┼─────────────┼────────────┤ │ 0 │ 578 │ 1234 │ '0' │ 1 │ 2 │ │ 1 │ 579 │ 987 │ '—' │ 1 │ 1 │ └─────────┴──────┴────────┴──────────────┴─────────────┴────────────┘ ``` * Copy the validator stash address, go to the [extrinsics tab](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmainnet3.creditcoin.network#/extrinsics), select `Staking` > `payoutStakers` copy the address of your validator into the `validatorStash` field and the era taken from the previous step into the `era` field, and sign and submit the transaction
* Repeat the process for all of your validators and all of their unpaid eras # Eras - 384 to 385 This page is an archive of expected display issues that existed during the first 2 eras (384-385) post `3.52.0-mainnet` runtime upgrade, which are no longer relevant. ### Summary * ["Other Stake" disappearing on Polkadot.js frontend](#other-stake-disappearing-on-polkadot.js-frontend) * ["Active Nominators" disappearing from the "Targets" view on Polkadot.js frontend](#alternative-places-where-these-numbers-can-be-checked-are) #### "Other Stake" disappearing on Polkadot.js frontend During the first era, after the runtime upgrade, the users will notice that the "other stake" indicator, together with the "active" nominators on the [polkadotjs apps frontend](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmainnet3.creditcoin.network#/legacy-staking) staking page, will disappear. This happens due to the update in `pallet-staking` storage API.
This issue resolved itself once the first era ended. "other stake" became visible as well as the identities of the nominators nominating a specific validator
#### Alternative places where these numbers can be checked are: * Creditcoin3 Subscan: \ \ This resource will be useful to visually check the number and identity of nominators for individual validators, while the polkadotjs app frontend is not displaying the values correctly during the first few eras post-runtime upgrade
As well as checking individual nominators per validator and their stake by clicking on the number of nominators
* Staking Dashboard: \ \ If you need more details about your specific nominations, you should head over to the Creditcoin3 Staking Dashboard, which will display every detail correctly for your specific nominations, as well as the number of total active nominators, together with the pending payout amounts for the past 7 days.
* Blockchain Storage Calls: \ \ Querying `staking > erasStakers` for the current era and your nominated validator, will show you the full list of the nominator stashes and their stakes for this specific validator for a given era. You can verify that your account is indeed in the list of nominators and earning rewards. \ \ *Note: for the eras after the runtime upgrade (Era 384), use staking > erasStakersPaged to get the staking information.*
#### Active nominators disappearing from the "Targets" view Same as above, the users will see the number indications for active nominators disappear across corresponding validators. All the sources stated above can be used to verify that the nominations are still very much active.
And this issue, as well as the first one, gets resolved after the first era post-runtime upgrade
# 3.52.0-Mainnet API Changes ### API changes for runtime users * `pallet-balances` * Extrinsics * `transfer > transferAllowDeath` / `transferKeepAlive` * `pallet-staking` * Extrinsics * If a validator has more than `maxExposurePageSize` nominators (512 in our case) then `payoutStakers` will need to be called multiple times to repay all of the nominators. The extrinsic only pays out the top one page (512) nominators at a time. * Alternatively, if you know which page your nominator stash belongs to, you can perform `payoutStakersByPage` and specify the page (0, 1, 2, etc) to pay out specific nominators that belong to that page. This can be used to avoid paying transaction fees while unintentionally paying out other accounts. * Storage Calls * `erasstakers > erasStakersPaged` Use the old API for eras up to the runtime upgrade, and the new api for eras after it * `erasStakersClipped > erasStakersOverview` Use the old API for eras up to the runtime upgrade, and the new api for eras after it * `claimedRewards` inside the `ledger` storage item has been deprecated and changed to `legacyClaimedRewards`. It will only reflect the rewards claimed before the runtime upgrade. Users should use the new `staking.claimedRewards` storage call to get the history of claimed paged rewards by era and validator * Storage Constants * `maxNominatorRewardedPerValidator > maxExposurePageSize` * `pallet-nomination-pools` * Added the ability to configure who can claim commission from nomination pools. * Previously, only the pool's root role was allowed to call `claim_commission`. This was limiting for use cases where pools wanted to allow third-party bots, external accounts, or anyone to claim commission on their behalf. This change allows pool operators to configure this behavior. * A new `claim_permission` field has been added to the `Commission` struct inside `BondedPool`. * If `claim_permission` is set to: * `Permissionless`: **anyone** can call `claim_commission` * `Account(some_account)`: only the specified account can call `claim_commission` * `None`: falls back to current behavior (only the pool's root can call it) This change introduces a migration to extend existing pools with the new optional field. All existing pools will default to `None`, preserving the current behavior unless explicitly updated. To enable permissionless claiming or delegate it to another account, the pool's root role must update the `claim_permission` field accordingly. This could be done by: * Extrinsics > `nominationPools` > `setCommissionClaimPermission` * provide `pool_id` and enable `CommissionClaimPermission`option, and set it either to `Permissionless` or specify an `Account` that will have the permission to withdraw commissions * No action is required unless the pools want to change this behavior. # Register Native Address for Creditcoin Airdrops Step-by-step guide to register your Creditcoin Native address and become eligible for future airdrop rewards on Creditcoin. ## How to Register Your Creditcoin Native Address for Airdrops on Creditcoin
If you own a Creditcoin Native address and hold CTC in it, you must register an EVM address to be eligible for any airdrops on Creditcoin. Here's a step-by-step guide on how to do it: 1. Install the [Polkadot{.js} Extension](https://chromewebstore.google.com/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd) 2. Connect your account 1. Go to 2. Select your Creditcoin Native address that holds your tokens 3. Set up the transaction 1. In the "submit the following extrinsic" section: 1. Left dropdown: Select `identity` 2. Right dropdown: Select `setIdentity(info)` 4. Enter your EVM address 1. In the `legal: Data` field: 1. Click `None` → Change it to `Raw` 2. Enter your EVM address in the `Raw: Bytes` input field. This should be the 0x format EVM address where you want to receive the airdrop. Example:`0x1234567890123456789012345678901234567890` 5. Submit the transaction 1. Sign and submit the transaction.

Register Creditcoin Native Address

### How To Verify the Registration * Go to [Creditcoin Native explorer](https://creditcoin.subscan.io/) * Search for your Creditcoin Native address * Check the "Legal name" field * If your EVM address appears correctly, you're registered. * Now sit tight, and keep your eyes on [@creditcoin](https://x.com/creditcoin) for exciting updates about upcoming airdrops.

Verify Registration

### Important Details to Remember * If the registered EVM address does not match the address you use to claim, you will not receive the airdrop. * You must complete the registration before the snapshot. * Any changes made after the snapshot will not be accepted. * If you register the same EVM address to multiple Creditcoin Native addresses, the airdrop amounts will be aggregated and shown as a total. # Terms of Use ## Creditcoin OÜ. Terms of Use Last revised on: February 6, 2025 *** Please review these Terms of Use (“Terms” or “Creditcoin Website Terms”) carefully, as they set forth the legally binding terms and conditions that govern your use of our websites located at , and [https://penguinswap.org/](https://penguinswap.org) (each a “Website”, and collectively, “Websites”), your access to and use of our mobile, tablet and other smart device applications, and application program interfaces (“API”) services (collectively, "Apps"), including related trademarks, software code, and other intellectual property, as well as software service for storing and transferring digital assets on various blockchain networks including self-custody externally owned accounts (“EOA”) and smart contract wallets (commonly known as Credit Wallet) (the “Credit Wallet” or the "Wallet"). By accessing or using the Websites, Wallet, or Apps, you represent that you are age 18 or older (or age 19 or older as required by certain, applicable jurisdictions). If you are between the ages of 13 and 17 or below the age of majority in your jurisdiction, you represent that your legal guardian has reviewed and agreed to these Terms. The Websites are a copyrighted work belonging to Creditcoin OÜ (“Creditcoin,” “Company,” “us,” “our,” and “we”). Your submission of information, including personally identifiable information (“PII”), through or in connection with the Websites is governed by the terms of our privacy policy as updated from time to time, available at (“Privacy Policy”). \ You consent to us collecting, accessing, using, processing, disclosing and retaining any PII you provide to us for the purpose of us providing the Services or the Wallet (defined below) to you. This consent is not related to, and does not affect, any rights or obligations we or you have in accordance with data protection laws, privacy laws, and regulations. \*\*\*\ THESE TERMS SET FORTH THE LEGALLY BINDING TERMS AND CONDITIONS THAT GOVERN YOUR USE OF THE SERVICES AND THE WALLET. BY ACCESSING OR USING THE SERVICES OR THE WALLET, YOU ARE ACCEPTING THESE TERMS (ON BEHALF OF YOURSELF OR THE ENTITY THAT YOU REPRESENT), AND YOU REPRESENT AND WARRANT THAT YOU HAVE THE RIGHT, AUTHORITY, AND CAPACITY TO ENTER INTO THESE TERMS (ON BEHALF OF YOURSELF OR THE ENTITY THAT YOU REPRESENT). IF YOU DO NOT AGREE WITH ALL OF THE PROVISIONS OF THESE TERMS, DO NOT ACCESS AND/OR USE THE SERVICES (AS DEFINED BELOW) OR THE WALLET. THESE TERMS REQUIRE THE USE OF ARBITRATION (SECTION 9) ON AN INDIVIDUAL BASIS TO RESOLVE DISPUTES, RATHER THAN JURY TRIALS OR CLASS ACTIONS (SECTION 10) , AND ALSO LIMIT THE REMEDIES AVAILABLE TO YOU IN THE EVENT OF A DISPUTE. \*\*\* Changes to Terms of Use. We may modify the Terms at any time at our sole discretion. If we do so, we’ll let you know either by posting the modified Terms on the Website, by providing you with a notice through the Wallet, or through other methods of communication which we deem reasonable. The modified Terms will be effective at the time they are posted on the Website. It’s important that you review the Terms whenever we modify them because if you continue to use the Services or the Wallet after we have modified the Terms, you agree to be bound by the modified Terms. If you don’t agree to be bound by the modified Terms, then you may not use the Services or the Wallet. Because our Services are evolving over time we may change or discontinue all or any part of the Wallet, or Services, at any time and without notice, at our sole discretion. ### 1. DESCRIPTION OF SERVICES. 1. **Interface.**\ The Interface provides a web or mobile-based means of access to (a) a decentralized protocol on the Creditcoin blockchain that allows users to trade certain compatible digital assets (the "Protocol"). The Interface is distinct from the Protocol and is one, but not the exclusive, means of accessing the Protocol. The Protocol itself is open-source or source-available self-executing smart contracts that are deployed on the Creditcoin Blockchain. Creditcoin does not control or operate any version of the Protocol on any blockchain network . Creditcoin operates the Interface solely for the purposes of ensuring its functionality, reliability, and security. Creditcoin’s operations of the Interface do not provide it with any control over the Protocol, nor can it influence or control any of the trades conducted on the Protocol. By using the Interface, you understand that you are not buying or selling digital assets from us and that we do not operate any liquidity pools on the Protocol or control trade execution on the Protocol. However, to facilitate initial liquidity and Protocol stability, Creditcoin may provide liquidity to one specific pool. This provision of liquidity is solely for the purposes of starting the exchange and does not imply any control or influence over the Protocol or the trades conducted on it. When traders pay fees for trades, those fees accrue to liquidity providers for the Protocol. As a general matter, Creditcoin is not a liquidity provider into Protocol liquidity pools and liquidity providers are independent third parties. Deployments on other networks typically make use of cross-chain bridges, which allow assets native to one blockchain to be transferred to another blockchain. Please note that digital assets that have been "bridged" or "wrapped" to operate on other blockchain networks (including to blockchains compatible with the Ethereum Virtual Machine that are designed to ensure the Ethereum blockchain can effectively process more transactions or other blockchains that are frequently referred to as "Layer 2" solutions) are distinct from the original Creditcoin mainnet asset. \ \ To access the Interface, you must use a non-custodial wallet software, which allows you to interact with public blockchains. Your relationship with that non-custodial wallet provider is governed by the applicable terms of service (with respect to the Wallet, this Agreement, and with respect to a third party wallet, the applicable terms of service of such third party). We do not have custody or control over the contents of your wallet and have no ability to retrieve or transfer its contents. By connecting your wallet to our Interface, you agree to be bound by this Agreement and all of the terms incorporated herein by reference.
2. **Users.** \ Users of the Websites ("Users") will be able to access and browse the Website including the Documentation ("Browsing Services"), and access Creditcoin's Apps. A User is not required to register an account to access the Browsing Services or the Wallet. 3. **Use of Services.** \ No accounts are required for any apps on Creditcoin, and this policy is expected to continue. The Creditcoin app functions as a wallet with Create and Import wallet features. Users can access the Services without the need for registration. The "Services" refer to the Browsing Services, the Wallet, API services, and Swap Services, which are further defined in the sections below. 4. **Use of the Wallet.** \ Creditcoin offers access to its Wallet which enables users to (i) store digital assets; (ii) access a digital asset browser and link to third party decentralized exchanges ("DEXs") and third party decentralized applications (together with DEXs, collectively "Dapp(s)"); (iii) view addresses and information that are part of digital asset networks and broadcast transactions; (iv) participate in retail DEX trades and associated DEX activity; (v) utilize the Credit Wallet for storing and managing digital assets; and (vi) additional functionality as Creditcoin may add to the Wallet from time to time; and educational resources ("Documentation") through its Websites. 5. **Swap Services.** \ Creditcoin provides the following swap services: \ (a) wCTC <-> CTC Swap: A service enabling users to exchange CTC from the Creditcoin blockchain to wCTC on the Ethereum blockchain, and vice versa. (i) Users send tokens to a designated address provided by Creditcoin. (ii) Creditcoin sends the equivalent amount to the user's address on the respective network. (iii) Users are responsible for providing accurate addresses and covering network fees.(iv) Creditcoin may, at its sole discretion, implement and modify various terms and conditions for the swap service, including but not limited to minimum and maximum swap amounts, processing times, and other operational parameters. These terms are subject to change from time to time without prior notice. Users are encouraged to review the current terms before initiating a swap.
(b) G-CRE -> CTC Swap: A one-way service exchanging G-CRE on Ethereum for CTC on Creditcoin at a 1:1 ratio. (i) The process may be automated or manual, subject to change without notice. (ii) Users must provide a valid CTC address for receiving swapped tokens. (iii) The service is subject to availability and may be suspended at Creditcoin's discretion.\ \ PenguinSwap provides the following swap services:
(a) Decentralized token swapping: A service that enables users to swap from any\ 2 tokens provided there is a valid route. (i) Users are responsible for selecting valid tokens.
(b) Liquidity providing: A service that allows adding liquidity to any pools already created or to create a pool provided the required tokens are held. Liquidity can be removed at any time. (i) Users take the risk of impermanent loss by providing liquidity.
(c) Claim fees: A service that allows claiming accrued fees by providing liquidity. (i) The fees are claimed in the form of both tokens that are part of the pool. (ii) The fee may be claimed in CTC or WCTC if this is one of the tokens provided. For both swap services: \ \ (a) Blockchain transactions are irreversible; Creditcoin and PenguinSwap cannot recover funds sent to incorrect addresses.
(b) (Creditcoin and PenguinSwap may require additional verification for large amounts or suspicious activities.
(c) Users must comply with applicable laws and regulations.
(d) Creditcoin and PenguinSwap reserves the right to refuse service at its sole discretion. ### 2. ACCESS TO THE SERVICES. 1. **License.**\ Subject to these Terms, Creditcoin grants you a non-transferable, non-exclusive, revocable, limited license to use and access the Services or the Wallet for your own personal and noncommercial use. 2. **Certain Restrictions.**\ The rights granted to you in these Terms are subject to the following restrictions: (a) you shall not license, sell, rent, lease, transfer, assign, distribute, host, or otherwise commercially exploit the Websites, whether in whole or in part, or any content displayed on the Websites; (b) you shall not (directly or indirectly) modify, decipher, disassemble, reverse compile or reverse engineer or otherwise attempt to derive any source code or underlying ideas or algorithms of any part of the Services or the Wallet; (c) you shall not access the Service or Wallet in order to build a similar or competitive website, product, or service; (d) translate, or otherwise create derivative works of any part of the Services or the Wallet; (e) rent, lease, distribute, or otherwise transfer any of the rights that you receive hereunder; (f) frame or mirror any part of the Service without Creditcoin’s express prior written consent; (g) create a database by systematically downloading and storing Website or API content; (h) use any robot, spider, search/retrieval application or other manual or automatic device to retrieve, harvest, index, “scrape,” “data mine” or in any way gather Website, Wallet, or API content or reproduce or circumvent the navigational structure or presentation of the Website without Creditcoin’s express prior written consent and (i) except as expressly stated herein, no part of the Website may be copied, reproduced, distributed, republished, downloaded, displayed, posted or transmitted in any form or by any means. Unless otherwise indicated, any future release, update, or other addition to functionality of the Website or API shall be subject to these Terms, (j) engage in any activity that violates any applicable law, rule, or regulation concerning the trading of securities or derivatives, including, but not limited to, the unregistered offering of securities and the offering of leveraged and margined commodity products to retail customers in the United States; (k) engage in activity that violates any applicable law, rule, or regulation concerning the integrity of trading markets, including, but not limited to, the manipulative tactics commonly known as “rug pulls”, pumping and dumping, and wash trading; (l) buying, selling or transferring stolen, fraudulently obtained, illegally obtained, or unauthorized digital assets and crypto commodity; and (m) engage in any activity that violates any applicable law, rule, or regulation of the United States or another relevant jurisdiction, including, but not limited to, the restrictions and regulatory requirements imposed by U.S. law. All copyright and other proprietary notices on the Website or API (or on any content displayed on the Website or API) must be retained on all copies thereof. 3. **Who May Use the Wallet.**\ You may use the Wallet if you are 18 years or older and are not barred from using the Wallet under applicable law. 4. **Modification.**\ Creditcoin reserves the right, at any time, to modify, suspend, or discontinue the Services or the Wallet (in whole or in part) with or without notice to you. You agree that Creditcoin will not be liable to you or to any third party for any modification, suspension, or discontinuation of the Services or any part thereof. Creditcoin further reserves the right to modify the Wallet to incorporate Web3 functionalities, enhance user experience, or comply with emerging technological standards. Despite any such modifications, you, as the user, will retain full responsibility for the security and management of your own private keys associated with the Wallet. 5. **No Support or Maintenance.**\ You acknowledge and agree that Creditcoin will have no obligation to provide you with any support or maintenance in connection with the Services or the Wallet. 6. **Ownership.**\ You acknowledge that all the intellectual property rights, including copyrights, patents, trademarks, and trade secrets, in the Services or the Wallet and its content are owned by Creditcoin. Neither these Terms (nor your access to the Services or the Wallet) transfer to you or any third party any rights, title or interest in or to such intellectual property rights, except for the limited access rights expressly set forth in these Terms. Creditcoin and its suppliers reserve all rights not granted in these Terms. There are no implied licenses granted under these Terms. You own and control digital assets held in your Wallet. As the sole owner of digital assets in your Wallet, you shall bear all risk of loss of such digital assets. Creditcoin OÜ shall have no liability for digital asset fluctuations or loss associated with your use of the Wallet. At any time, subject to outages, downtime, and other applicable policies, you may withdraw your digital assets by sending it to a different blockchain address. You acknowledge that by engaging to use the Wallet you are at no time transferring your assets to Creditcoin OÜ or its affiliates. 7. **Fees.**\ Blockchain transactions require the payment of transaction fees to the appropriate network. We may charge fees for some or part of the use of the Services or Wallet we make available to you. We reserve the right to change those fees at our discretion. We will disclose the amount of fees we will charge you for the applicable Services or Wallet function at the time that you access the Wallet function. You will be solely responsible for paying the fees for any transaction that you initiate via any of our Services. \ You may incur charges from third parties for use of linked services. For example, you may be charged fees via the Dapps and/or DEXs that you may access via use of the Wallet. Third party fees are not charged by Creditcoin OÜ and are not paid to Creditcoin OÜ. 8. **Acceptable Use Policy.**\ The following terms constitute our “Acceptable Use Policy”: (a) You agree not to: (i) upload, transmit, or distribute to or through the Services or the Wallet any computer viruses, worms, or any software intended to damage or alter a computer system or data; (ii) use the Services or the Wallet to harvest, collect, gather or assemble information or data regarding other users, including e-mail addresses, without their consent; (iii) interfere with, disrupt, or create an undue burden on servers or networks connected to the Services or the Wallet, or violate the regulations, policies or procedures of such networks; (iv) attempt to gain unauthorized access to the Services or the Wallet (or to other computer systems or networks connected to or used together with the Services or the Wallet), whether through password mining or any other means; (v) harass or interfere with any other user’s use and enjoyment of the Services or the Wallet; or (vi) use software or automated agents or scripts to produce multiple accounts on the Websites, or to generate automated searches, requests, or queries to (or to strip, scrape, or mine data from) the Services or the Wallet (provided, however, that we conditionally grant to the operators of public search engines revocable permission to use spiders to copy materials from the Services or the Wallet for the sole purpose of and solely to the extent necessary for creating publicly available searchable indices of the materials, but not caches or archives of such materials, subject to the parameters set forth in our robots.txt file). 9. **Wallet Restrictions.**\ You may use the Wallet or Service only for lawful purposes and in accordance with these Terms. You must not use the Wallet in any way that violates any applicable federal, state, local, or international law or regulation. You must not use the Wallet or Services if you are on any U.S. sanctions lists or located in any country that is subject to U.S. government sanctions or has been designated by the U.S. government as a "terrorist supporting" country. You must not use the Wallet or Services to engage in any fraudulent, abusive, or illegal activity, or to interfere with the security or functionality of the Wallet or any blockchain network. You must not attempt to gain unauthorized access to the Wallet, Services or any Creditcoin systems or networks. You must not copy, modify, distribute, sell, or lease any part of the Wallet or its content, or reverse engineer or attempt to extract the source code of the Wallet, except as expressly permitted by applicable law or with our prior written consent. We reserve the right to take any action we deem necessary to protect the Wallet and our rights and interests, including suspending or terminating your access to the Wallet, without notice or liability to you. \ Creditcoin reserves the right to determine what conduct it considers to be in violation of these restrictions. Creditcoin reserves the right to take action as a result, which may include prohibiting you from accessing Services provided by Creditcoin in whole or in part. Any restrictions imposed by Creditcoin will not affect your ability to transfer your digital assets. 10. **Recovery Phrase and Passkeys.**\ You are solely responsible for the retention and security of your Wallet credentials, your twelve-word recovery phrase for EOA wallets (“Recovery Phrase”) and your unique digital or hardware credentials (for example, iCloud and Google Passkeys, hardware authentication devices such as Yubikeys) that are tied to your smart contract wallets (“Passkeys”). Your Recovery Phrase and/or Passkeys are the only way to access the cryptocurrency associated with your account. Anyone that has access to your Recovery Phrase and/or Passkeys can access your cryptocurrency. 11. **Biometric Data.**\ The Wallet allows you to use biometric data, such as your fingerprint or face recognition, to unlock the Wallet and authorize transactions. You acknowledge and agree that your biometric data is stored locally on your device and not by Creditcoin. You are solely responsible for the security and integrity of your biometric data and your device. You must not share your device or your biometric data with anyone or allow anyone to access the Wallet using your biometric data. You must notify us immediately if you suspect any unauthorized use of your biometric data or your device. We are not liable for any loss or damage resulting from your use of biometric data or your device. 12. **Enforcement.**\ We reserve the right (but have no obligation) to investigate and/or take appropriate action against you in our sole discretion if you violate the Acceptable Use Policy or any other provision of these Terms or otherwise create liability for us or any other person. Such action may include terminating your access to the Services in accordance with Section 9, and/or reporting you to law enforcement authorities. 13. **Feedback.**\ If you provide Creditcoin with any feedback or suggestions regarding the Services or the Wallet (“Feedback”), you hereby assign to Creditcoin all rights in such Feedback and agree that Creditcoin shall have the right to use and fully exploit such Feedback and related information in any manner it deems appropriate. Creditcoin will treat any Feedback you provide to Creditcoin as non-confidential and non-proprietary. You agree that you will not submit to Creditcoin any information or ideas that you consider to be confidential or proprietary. ### 3. INDEMNIFICATION. You agree to indemnify and hold Creditcoin (and its officers, employees, and agents) harmless, including costs and attorneys’ fees, from any claim or demand made by any third party due to or arising out of (a) your use of the Services or the Wallet, (b) your violation of these Terms, or (c) your violation of applicable laws or regulations. Creditcoin reserves the right, at your expense, to assume the exclusive defense and control of any matter for which you are required to indemnify us, and you agree to cooperate with our defense of these claims. You agree not to settle any matter without the prior written consent of Creditcoin. Creditcoin will use reasonable efforts to notify you of any such claim, action or proceeding upon becoming aware of it. ### 4. THIRD-PARTY LINKS & ADS; OTHER USERS 1. **Third-Party Links & Ads.**\ The Websites may contain links to third-party websites and services, and/or display advertisements for third parties (collectively, “Third-Party Links & Ads”). The inclusion of any link is not and does not imply an affiliation, sponsorship, endorsement, approval, investigation, verification or monitoring by Creditcoin of any information, materials, products, or services contained in or accessible through any Third-Party Application. Such Third-Party Links & Ads are not under the control of Creditcoin, and Creditcoin is not responsible for any Third-Party Links & Ads. Creditcoin provides access to these Third-Party Links & Ads only as a convenience to you, and does not review, approve, monitor, endorse, warrant, or make any representations with respect to Third-Party Links & Ads. Neither Creditcoin nor its partners endorse any of the opportunities that appear on these Websites, nor does Creditcoin and/or its partners make any recommendations regarding the appropriateness of particular opportunities for any Users. Each User must review and evaluate the opportunities in such User’s own discretion and determine the suitability of entering into any transaction. You use all Third-Party Links & Ads at your own risk, and should apply a suitable level of caution and discretion in doing so. When you click on any of the Third-Party Links & Ads, the applicable third party’s terms and policies apply, including the third party’s privacy and data gathering practices. You should make whatever investigation you feel necessary or appropriate before proceeding with any transaction in connection with such Third-Party Links & Ads. 2. **Release.**\ You hereby release and forever discharge Creditcoin (and our officers, employees, agents, successors, and assigns) from, and hereby waive and relinquish, each and every past, present and future dispute, claim, controversy, demand, right, obligation, liability, action and cause of action of every kind and nature (including personal injuries, death, and property damage), that has arisen or arises directly or indirectly out of, or that relates directly or indirectly to, the Services or the Wallet (including any or act or omission of any Third-Party Links & Ads). IF YOU ARE A CALIFORNIA RESIDENT, YOU HEREBY WAIVE CALIFORNIA CIVIL CODE SECTION 1542 IN CONNECTION WITH THE FOREGOING, WHICH STATES: “A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS WHICH THE CREDITOR DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE, WHICH IF KNOWN BY HIM OR HER MUST HAVE MATERIALLY AFFECTED HIS OR HER SETTLEMENT WITH THE DEBTOR.” ### 5. ACCURACY OF INFORMATION. We attempt to ensure that the information that we provide on these Websites are complete, accurate and current. Despite our efforts, the information on these Websites may occasionally be inaccurate, incomplete or out of date. We make no representation as to the completeness, accuracy or correctness of any information on these Websites. ### 6. DISCLAIMERS. 1. **Assumption of Risk – Generally**\ BY ACCESSING AND USING ANY OF OUR SERVICES, YOU REPRESENT THAT YOU ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS ASSOCIATED WITH USING CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS, AND THAT YOU HAVE A WORKING KNOWLEDGE OF THE USAGE AND INTRICACIES OF DIGITAL ASSETS SUCH AS ETHER (ETH), SO-CALLED STABLECOINS, AND OTHER DIGITAL TOKENS SUCH AS THOSE FOLLOWING THE ETHEREUM TOKEN STANDARD (ERC-20).\ \ IN PARTICULAR, YOU UNDERSTAND THAT THE MARKETS FOR THESE DIGITAL ASSETS ARE NASCENT AND HIGHLY VOLATILE DUE TO RISK FACTORS INCLUDING, BUT NOT LIMITED TO, ADOPTION, SPECULATION, TECHNOLOGY, SECURITY, AND REGULATION. YOU UNDERSTAND THAT ANYONE CAN CREATE A TOKEN, INCLUDING FAKE VERSIONS OF EXISTING TOKENS AND TOKENS THAT FALSELY CLAIM TO REPRESENT PROJECTS, AND ACKNOWLEDGE AND ACCEPT THE RISK THAT YOU MAY MISTAKENLY TRADE THOSE OR OTHER TOKENS. SO-CALLED STABLECOINS MAY NOT BE AS STABLE AS THEY PURPORT TO BE, MAY NOT BE FULLY OR ADEQUATELY COLLATERALIZED, AND MAY BE SUBJECT TO PANICS AND RUNS.\ \ FURTHER, YOU UNDERSTAND THAT SMART CONTRACT TRANSACTIONS AUTOMATICALLY EXECUTE AND SETTLE, AND THAT BLOCKCHAIN-BASED TRANSACTIONS ARE IRREVERSIBLE WHEN CONFIRMED. YOU ACKNOWLEDGE AND ACCEPT THAT THE COST AND SPEED OF TRANSACTING WITH CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS SUCH AS ETHEREUM ARE VARIABLE AND MAY INCREASE DRAMATICALLY AT ANY TIME. YOU FURTHER ACKNOWLEDGE AND ACCEPT THE RISK OF SELECTING TO TRADE IN EXPERT MODES, WHICH CAN EXPOSE YOU TO POTENTIALLY SIGNIFICANT PRICE SLIPPAGE AND HIGHER COSTS.\ \ IF YOU ACT AS A LIQUIDITY PROVIDER TO THE PROTOCOL THROUGH THE INTERFACE, YOU UNDERSTAND THAT YOUR DIGITAL ASSETS MAY LOSE SOME OR ALL OF THEIR VALUE WHILE THEY ARE SUPPLIED TO THE PROTOCOL THROUGH THE INTERFACE DUE TO THE FLUCTUATION OF PRICES OF TOKENS IN A TRADING PAIR OR LIQUIDITY POOL.\ \ FINALLY, YOU UNDERSTAND THAT WE DO NOT CREATE, OWN, OR OPERATE CROSS-CHAIN BRIDGES AND WE DO NOT MAKE ANY REPRESENTATION OR WARRANTY ABOUT THE SAFETY OR SOUNDNESS OF ANY CROSS-CHAIN BRIDGE, INCLUDING ITS USE FOR GOVERNANCE.
IN SUMMARY, YOU ACKNOWLEDGE THAT WE ARE NOT RESPONSIBLE FOR ANY OF THESE VARIABLES OR RISKS, DO NOT OWN OR CONTROL THE PROTOCOL, AND CANNOT BE HELD LIABLE FOR ANY RESULTING LOSSES THAT YOU EXPERIENCE WHILE ACCESSING OR USING ANY OF OUR PRODUCTS. ACCORDINGLY, YOU UNDERSTAND AND AGREE TO ASSUME FULL RESPONSIBILITY FOR ALL OF THE RISKS OF ACCESSING AND USING THE INTERFACE TO INTERACT WITH THE PROTOCOL. 2. **No Warranties**\ THE SERVICES AND THE WALLET ARE PROVIDED ON AN “AS-IS” AND “AS AVAILABLE” BASIS, AND CREDITCOIN (AND OUR SUPPLIERS) EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES AND CONDITIONS OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ALL WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, QUIET ENJOYMENT, ACCURACY, OR NON-INFRINGEMENT. WE (AND OUR SUPPLIERS) MAKE NO WARRANTY THAT THE SERVICES OR THE WALLET WILL MEET YOUR REQUIREMENTS, WILL BE AVAILABLE ON AN UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE BASIS, OR WILL BE ACCURATE, RELIABLE, FREE OF VIRUSES OR OTHER HARMFUL CODE, COMPLETE, LEGAL, OR SAFE. IF APPLICABLE LAW REQUIRES ANY WARRANTIES WITH RESPECT TO THE SERVICES OR THE WALLET, ALL SUCH WARRANTIES ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF FIRST USE.\ \ IF YOU LOSE YOUR RECOVERY PHRASE AND/OR PASSKEYS OF YOUR WALLET, YOU WILL NOT BE ABLE TO ACCESS YOUR CRYPTOCURRENCY IN THE WALLET. YOU ACKNOWLEDGE THAT CREDITCOIN OÜ DOES NOT STORE AND IS NOT RESPONSIBLE IN ANY WAY FOR THE SECURITY OF YOUR RECOVERY PHRASE AND/OR PASSKEYS. YOU AGREE TO HOLD CREDITCOIN OÜ. AND ITS AFFILIATES HARMLESS FOR ANY LOSSES ARISING FROM YOU LOSING YOUR RECOVERY PHRASE AND/OR PASSKEYS. YOU AGREE THAT CREDITCOIN OÜ AND ITS AFFILIATES SHALL NOT BE LIABLE IN ANY WAY IF YOU LOSE YOUR RECOVERY PHRASE AND/OR PASSKEYS AND CANNOT ACCESS YOUR CRYPTOCURRENCY.\ \ CREDITCOIN DOES NOT ENDORSE ANY OTHER THIRD PARTY AND SHALL NOT BE RESPONSIBLE IN ANY WAY FOR ANY TRANSACTIONS YOU ENTER INTO WITH OTHER USERS. YOU AGREE THAT CREDITCOIN WILL NOT BE LIABLE FOR ANY LOSS OR DAMAGES OF ANY SORT INCURRED AS THE RESULT OF ANY INTERACTIONS BETWEEN YOU AND OTHER USERS.\ \ SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. SOME JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU 3. **No Investment Advice**\ WE MAY PROVIDE INFORMATION ABOUT TOKENS IN OUR PRODUCTS SOURCED FROM THIRD-PARTY DATA PARTNERS. WE MAY ALSO PROVIDE WARNING LABELS FOR CERTAIN TOKENS. THE PROVISION OF INFORMATIONAL MATERIALS DOES NOT MAKE TRADES IN THOSE TOKENS SOLICITED; WE ARE NOT ATTEMPTING TO INDUCE YOU TO MAKE ANY PURCHASE AS A RESULT OF INFORMATION PROVIDED. ALL SUCH INFORMATION PROVIDED BY ANY OF OUR PRODUCTS IS FOR INFORMATIONAL PURPOSES ONLY AND SHOULD NOT BE CONSTRUED AS INVESTMENT ADVICE OR A RECOMMENDATION THAT A PARTICULAR TOKEN IS A SAFE OR SOUND INVESTMENT. YOU SHOULD NOT TAKE, OR REFRAIN FROM TAKING, ANY ACTION BASED ON ANY INFORMATION CONTAINED IN ANY OF OUR PRODUCTS. BY PROVIDING TOKEN INFORMATION FOR YOUR CONVENIENCE, WE DO NOT MAKE ANY INVESTMENT RECOMMENDATIONS TO YOU OR OPINE ON THE MERITS OF ANY TRANSACTION OR OPPORTUNITY. YOU ALONE ARE RESPONSIBLE FOR DETERMINING WHETHER ANY INVESTMENT, INVESTMENT STRATEGY OR RELATED TRANSACTION IS APPROPRIATE FOR YOU BASED ON YOUR PERSONAL INVESTMENT OBJECTIVES, FINANCIAL CIRCUMSTANCES, AND RISK TOLERANCE. ### 7. LIMITATION ON LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT SHALL CREDITCOIN BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOST PROFITS, LOST DATA, OR ANY INDIRECT, CONSEQUENTIAL, EXEMPLARY, INCIDENTAL, SPECIAL OR PUNITIVE DAMAGES ARISING FROM OR RELATING TO THESE TERMS OR YOUR USE OF, OR INABILITY TO USE, THE SERVICES OR THE WALLET, EVEN IF CREDITCOIN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ACCESS TO, AND USE OF, THE SERVICES OR THE WALLET IS AT YOUR OWN DISCRETION AND RISK, AND YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR DEVICE OR COMPUTER SYSTEM, OR LOSS OF DATA RESULTING THEREFROM. TO THE MAXIMUM EXTENT PERMITTED BY LAW, NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED HEREIN, OUR LIABILITY TO YOU FOR ANY DAMAGES ARISING FROM OR RELATED TO THIS AGREEMENT (FOR ANY CAUSE WHATSOEVER AND REGARDLESS OF THE FORM OF THE ACTION), WILL AT ALL TIMES BE LIMITED TO A MAXIMUM OF FIFTY US DOLLARS (U.S. $50). THE EXISTENCE OF MORE THAN ONE CLAIM WILL NOT ENLARGE THIS LIMIT. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU. ### 8. TERMS AND TERMINATION. Subject to this Section, these Terms will remain in full force and effect while you use the Services or the Wallet. We may suspend or terminate your rights to use the Services or the Wallet at any time for any reason at our sole discretion, including for any use of the Services or the Wallet in violation of these Terms. Upon termination of your rights under these Terms, your right to access and use the Services or the Wallet will terminate immediately. You understand that any termination of your right to use the services may involve deletion of your access to your API keys associated with your right to use the services from our live databases. Creditcoin will not have any liability whatsoever to you for any termination of your rights under these Terms, including for termination of your right to use the services. Even after your rights under these Terms are terminated, the following provisions of these Terms will remain in effect: Sections 2.2 through 2.6, and Sections 3, 4, 6 and 7. ### 9. DISPUTE RESOLUTION Please read this Arbitration Agreement carefully. It is part of your contract with Creditcoin and affects your rights. It contains procedures for mandatory binding arbitration and a class action waiver. 1. **Governing Law.**\ You agree that the laws of the State of Delaware, without regard to principles of conflict of laws, govern this Terms of Use and any dispute between you and us. You further agree that each of our Services shall be deemed to be based solely in the State of Delaware, and that although a Product may be available in other jurisdictions, its availability does not give rise to general or specific personal jurisdiction in any forum outside the State of Delaware. The parties acknowledge that this Terms of Use evidences interstate commerce. Any arbitration conducted pursuant to this Agreement shall be governed by the Federal Arbitration Act.\ \ If you are located outside of the United States (U.S.), your use or access the Services or the Wallet solely at your own risk and initiative. The Service is controlled and operated from facilities within the U.S. This Services is not intended to subject Creditcoin to non-U.S. jurisdiction or laws, except as otherwise expressly stated in this Agreement. The Service may not be appropriate or available for use in some jurisdictions. Creditcoin and its partners do not represent or warrant that the Services or the Wallet or any part thereof are appropriate or available for use in any particular jurisdiction other than the United States. In choosing to access the Services or the Wallet, you do so on your own initiative and at your own risk, and you are responsible for complying with all local laws, rules and regulations.
SOME JURISDICTIONS HAVE CONSUMER PROTECTION AND OTHER LEGISLATION WHICH MAY APPLY TO THE SERVICES OR THE WALLET AND WHICH DO NOT ALLOW CERTAIN PROVISIONS SUCH AS LIMITATIONS OF LIABILITY AND EXCLUSION OF CERTAIN WARRANTIES, AMONG OTHERS. TO THE EXTENT THAT A LIMITATION, EXCLUSION, RESTRICTION OR OTHER PROVISION SET OUT BELOW IS SPECIFICALLY PROHIBITED BY APPLICABLE LAW, SUCH LIMITATION, EXCLUSION, RESTRICTION OR PROVISION MAY NOT APPLY TO YOU. 2. **Notice Requirement and Informal Dispute Resolution.**\ Before either party may seek arbitration, the party must first send to the other party a written Notice of Dispute (“Notice”) describing the nature and basis of the claim or dispute, and the requested relief. Each party hereby irrevocably and unconditionally consents to service of process through personal service at their corporate headquarters, registered address, or primary address (for individuals or sole proprietors). Nothing in these Terms will affect the right of any party to serve process in any other manner permitted by Law. After the Notice is received, you and Creditcoin may attempt to resolve the claim or dispute informally. If you and Creditcoin do not resolve the claim or dispute within thirty (30) days after the Notice is received, either party may begin an arbitration proceeding. The amount of any settlement offer made by any party may not be disclosed to the arbitrator until after the arbitrator has determined the amount of the award, if any, to which either party is entitled. 3. **Arbitration Rules.**\ Arbitration shall be initiated through the American Arbitration Association (“AAA”), an established alternative dispute resolution provider (“ADR Provider”) that offers arbitration as set forth in this section. If AAA is not available to arbitrate, the parties shall agree to select an alternative ADR Provider. The rules of the ADR Provider shall govern all aspects of the arbitration, including but not limited to the method of initiating and/or demanding arbitration, except to the extent such rules are in conflict with the Terms. The AAA Consumer Arbitration Rules (“Arbitration Rules”) governing the arbitration are available online at [www.adr.org](http://www.adr.org) or by calling the AAA at 1-800-778-7879. The arbitration shall be conducted by a single, neutral arbitrator. Any claims or disputes where the total amount of the award sought is less than Ten Thousand U.S. Dollars (US $10,000.00) may be resolved through binding non-appearance-based arbitration, at the option of the party seeking relief. For claims or disputes where the total amount of the award sought is Ten Thousand U.S. Dollars (US $10,000.00) or more, the right to a hearing will be determined by the Arbitration Rules. The arbitration will be held in New York, New York, unless you and we both agree to hold it elsewhere. Unless we agree otherwise, the arbitrator may not consolidate your claims with those of any other party. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. If the arbitrator grants you an award that is greater than the last settlement offer that Creditcoin made to you prior to the initiation of arbitration, Creditcoin will pay you the greater of the award or $2,500.00. Each party shall bear its own costs (including attorney’s fees) and disbursements arising out of the arbitration and shall pay an equal share of the fees and costs of the ADR Provider.\ You agree that the federal and state courts of New York County, New York are the proper forum for any appeals of an arbitration award or for court proceedings in the event that this Agreement's binding arbitration clause is found to be unenforceable 4. **Additional Rules for Non-Appearance Based Arbitration.**\ If non-appearance-based arbitration is elected, the arbitration shall be conducted by telephone, online and/or based solely on written submissions; the specific manner shall be chosen by the party initiating the arbitration. The arbitration shall not involve any personal appearance by the parties or witnesses unless otherwise agreed by the parties. 5. **Time Limits.**\ If you or Creditcoin pursue arbitration, the arbitration action must be initiated and/or demanded within the statute of limitations (i.e., the legal deadline for filing a claim) and within any deadline imposed under the AAA Rules for the pertinent claim. 6. **Authority of Arbitrator.**\ If arbitration is initiated, the arbitrator will decide the rights and liabilities, if any, of you and Creditcoin, and the dispute will not be consolidated with any other matters or joined with any other cases or parties. The arbitrator shall have the authority to grant motions dispositive of all or part of any claim. The arbitrator shall have the authority to award monetary damages, and to grant any non-monetary remedy or relief available to an individual under applicable law, the AAA Rules, and the Terms. The arbitrator shall issue a written award and statement of decision describing the essential findings and conclusions on which the award is based, including the calculation of any damages awarded. The arbitrator has the same authority to award relief on an individual basis that a judge in a court of law would have. The award of the arbitrator is final and binding upon you and Creditcoin.
7. **Confidentiality.**\ All aspects of the arbitration proceeding, including but not limited to the award of the arbitrator and compliance therewith, shall be strictly confidential. The parties agree to maintain confidentiality unless otherwise required by law. This paragraph shall not prevent a party from submitting to a court of law any information necessary to enforce this Agreement, to enforce an arbitration award, or to seek injunctive or equitable relief. 8. **Severability.**\ If any part or parts of this Arbitration Agreement are found under the law to be invalid or unenforceable by a court of competent jurisdiction, then such specific part or parts shall be of no force and effect and shall be severed and the remainder of the Agreement shall continue in full force and effect. 9. **Right to Waive.**\ Any or all of the rights and limitations set forth in this Arbitration Agreement may be waived by the party against whom the claim is asserted. Such waiver shall not waive or affect any other portion of this Arbitration Agreement. 10. **Survival of Agreement.**\ This Arbitration Agreement will survive the termination of your relationship with Creditcoin. 11. **Claims Not Subject to Arbitration.**\ Notwithstanding the foregoing, claims of defamation, violation of the Computer Fraud and Abuse Act, and infringement or misappropriation of the other party’s patent, copyright, trademark or trade secrets shall not be subject to this Arbitration Agreement. ### 10. WAIVER OF JURY TRIAL 1. **Waiver of Jury Trial.**\ THE PARTIES HEREBY WAIVE THEIR CONSTITUTIONAL AND STATUTORY RIGHTS TO GO TO COURT AND HAVE A TRIAL IN FRONT OF A JUDGE OR A JURY, INSTEAD ELECTING THAT ALL CLAIMS AND DISPUTES SHALL BE RESOLVED BY ARBITRATION UNDER THIS ARBITRATION AGREEMENT. ARBITRATION PROCEDURES ARE TYPICALLY MORE LIMITED, MORE EFFICIENT AND LESS COSTLY THAN RULES APPLICABLE IN A COURT AND ARE SUBJECT TO VERY LIMITED REVIEW BY A COURT. IN THE EVENT ANY LITIGATION SHOULD ARISE BETWEEN YOU AND CREDITCOIN IN ANY STATE OR FEDERAL COURT IN A SUIT TO VACATE OR ENFORCE AN ARBITRATION AWARD OR OTHERWISE, YOU WAIVE ALL RIGHTS TO A JURY TRIAL, INSTEAD ELECTING THAT THE DISPUTE BE RESOLVED BY A JUDGE. 2. **Waiver of Class or Consolidated Actions.**\ ALL CLAIMS AND DISPUTES WITHIN THE SCOPE OF THIS ARBITRATION AGREEMENT MUST BE ARBITRATED OR LITIGATED ON AN INDIVIDUAL BASIS AND NOT ON A CLASS BASIS, AND CLAIMS OF MORE THAN ONE USER CANNOT BE ARBITRATED OR LITIGATED JOINTLY OR CONSOLIDATED WITH THOSE OF ANY OTHER USER. ### 11. GENERAL. 1. **Changes.**\ These Terms are subject to occasional revision, and if we make any substantial changes, we may notify you by sending you an e-mail to the last e-mail address you provided to us (if any), and/or by prominently posting notice of the changes on our Services. You are responsible for providing us with your most current e-mail address. In the event that the last e-mail address that you have provided us is not valid, or for any reason is not capable of delivering to you the notice described above, our dispatch of the e-mail containing such notice will nonetheless constitute effective notice of the changes described in the notice. Any changes to these Terms will be effective one (1) day following the earlier of our dispatch of an e-mail notice to you (if applicable) or one (1) day following our posting of notice of the changes on our Websites. These changes will be effective immediately for new users of our Services. Continued use of our Services following notice of such changes shall indicate your acknowledgement of such changes and agreement to be bound by the terms and conditions of such changes. 2. **Trading**\ You agree and understand that: (a) all trades you submit through any of our Websites and Services are considered unsolicited, which means that they are solely initiated by you; (b) you have not received any investment advice from us in connection with any trades, including those you place via our API; and (c) we do not conduct a suitability review of any trades you submit. 3. **Non-Custodial and No Fiduciary Duties**\ Each of the Services is a purely non-custodial application, meaning we do not ever have custody, possession, or control of your digital assets at any time. It further means you are solely responsible for the custody of the cryptographic private keys to the digital asset wallets you hold and you should never share your wallet credentials or seed phrase with anyone. We accept no responsibility for, or liability to you, in connection with your use of a wallet and make no representations or warranties regarding how any of our Services will operate with any specific wallet. Likewise, you are solely responsible for any associated wallet and we are not liable for any acts or omissions by you in connection with or as a result of your wallet being compromised. For the avoidance of doubt, any references herein to a "wallet" shall include the Creditcoin Wallet.
This Agreement is not intended to, and does not, create or impose any fiduciary duties on us. To the fullest extent permitted by law, you acknowledge and agree that we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated. You further agree that the only duties and obligations that we owe you are those set out expressly in this Agreement. 4. **Not Registered with the SEC or Any Other Agency**\ We are not registered with the U.S. Securities and Exchange Commission as a national securities exchange or in any other capacity. You understand and acknowledge that we do not broker trading orders on your behalf. We also do not facilitate the execution or settlement of your trades, which occur entirely on public distributed blockchains like Ethereum. As a result, we do not (and cannot) guarantee market best pricing or best execution through our Services. Any references to "best price" in our Services do not constitute a representation or warranty about pricing available through our Services or elsewhere. 5. **Export.**\ The Services and the Wallet may be subject to U.S. export control laws and may be subject to export or import regulations in other countries. You agree not to export, reexport, or transfer, directly or indirectly, any U.S. technical data acquired from Creditcoin, or any products utilizing such data, in violation of the United States export laws or regulations. 6. **Disclosures.**\ If you are a California resident, you may report complaints to the Complaint Assistance Unit of the Division of Consumer Product of the California Department of Consumer Affairs by contacting them in writing at 400 R Street, Sacramento, CA 95814, or by telephone at (800) 952-5210. 7. **Electronic Communications.**\ The communications between you and Creditcoin use electronic means, whether you use the Services or the Wallet or send us emails, or whether Creditcoin posts notices on the Websites or communicates with you via email. For contractual purposes, you (a) consent to receive communications from Creditcoin in an electronic form; and (b) agree that all terms and conditions, agreements, notices, disclosures, and other communications that Creditcoin provides to you electronically satisfy any legal requirement that such communications would satisfy if it were be in a hardcopy writing. The foregoing does not affect your non-waivable rights. Your consent will remain in effect until you withdraw it. 8. **Entire Terms.**\ These Terms constitute the entire agreement between you and us regarding the use of the Services or the Wallet. The section titles in these Terms are for convenience only and have no legal or contractual effect. The word “including” means “including without limitation.” If any provision of these Terms is, for any reason, held to be invalid or unenforceable, the other provisions of these Terms will be unimpaired and the invalid or unenforceable provision will be deemed modified so that it is valid and enforceable to the maximum extent permitted by law. You confirm that you are acting on your own behalf and not for the benefit of any other person. Your relationship to Creditcoin is that of an independent contractor, and neither party is an agent or partner of the other. These Terms, and your rights and obligations herein, may not be assigned, subcontracted, delegated, or otherwise transferred by you without Creditcoin’s prior written consent, and any attempted assignment, subcontract, delegation, or transfer in violation of the foregoing will be null and void. Creditcoin may freely assign these Terms. The terms and conditions set forth in these Terms shall be binding upon assignees. 9. **Waiver.**\ A waiver by Creditcoin of any right or remedy under these Terms shall only be effective if it is in writing, executed by a duly authorized representative of Creditcoin and shall apply only to the circumstances for which it is given. Our failure to exercise or enforce any right or remedy under these Terms shall not operate as a waiver of such right or remedy, nor shall it prevent any future exercise or enforcement of such right or remedy. No single or partial exercise of any right or remedy shall preclude or restrict the further exercise of any such right or remedy or other rights or remedies. 10. **Copyright/Trademark Information.**\ Copyright © 2024 Creditcoin OÜ All rights reserved. All trademarks, logos and service marks (“Marks”) displayed on the Websites are our property or the property of other third parties. You are not permitted to use these Marks without our prior written consent or the consent of such third party which may own the Marks. 11. **Contact Information :** \ Creditcoin OÜ\ ### 10. ASSOCIATED BRANDS. 1. **Cafe GM.**\ Cafe GM is a brand associated with Creditcoin OÜ. It is not a separate legal entity. Any services, products, or content provided under the Cafe GM brand are subject to these Terms. 2. **PenguinSwap**\ PenguinSwap is a brand associated with Creditcoin OÜ. It is not a separate legal entity. Any services, products, or content provided under the PenguinSwap brand are subject to these Terms. 3. **Spacecoin.** \ Spacecoin is a separate legal entity with its own website (). Creditcoin OÜ may provide links to the Spacecoin website. Your use of the Spacecoin website and any associated services is governed by Spacecoin's own terms of use and privacy policy. ### 11. DATA COLLECTION, USE, AND STORAGE. Creditcoin OÜ collects, uses, and stores user data in accordance with these Terms, our Privacy Policy, and applicable laws and regulations. By using our Services, you consent to our data practices as described in this section and our Privacy Policy. We may update our data practices from time to time, and your continued use of our Services after such changes constitutes acceptance of the updated practices. We may collect various types of data to provide and improve our Services. This includes personal information such as name, email address, and blockchain addresses; service usage data about your interactions with our Services; and device information about the hardware and software you use to access our Services. For our swap services, we specifically collect and process your email address and blockchain addresses for token transfers. This information is used solely for executing transactions, providing customer support, and communications related to the swap services. Regarding the Credit Wallet, and as stated above in Section 3.11 of this Agreement, the Wallet allows you to use biometric data, such as your fingerprint or face recognition, to unlock the Wallet and authorize transactions. You acknowledge and agree that any biometric data used for authentication is stored locally on your device and not collected, transmitted to, or stored by Creditcoin OÜ. You are solely responsible for the security and integrity of your biometric data and your device. You must not share your device or your biometric data with anyone or allow anyone to access the Wallet using your biometric data. You must notify us immediately if you suspect any unauthorized use of your biometric data or your device. We are not liable for any loss or damage resulting from your use of biometric data or your device. However, we may collect and store public blockchain addresses associated with your Credit Wallet, transaction histories, and token balances to provide and improve our Services. We use the collected data to provide, maintain, and improve our Services; process transactions and send notices about your transactions; resolve disputes and troubleshoot problems; prevent potentially prohibited or illegal activities; and enforce our Terms of Use. We may also use aggregated, anonymized data for analytical and statistical purposes. Creditcoin OÜ does not sell, rent, or share personal information with third parties except as described in these Terms and our Privacy Policy. We may share data with service providers and business partners who assist in providing our Services, law enforcement or regulatory agencies as required by law or to protect our rights, and other parties with your consent or at your direction. We implement reasonable security measures to protect against unauthorized access, alteration, disclosure, or destruction of personal information. However, no method of transmission over the Internet or electronic storage is 100% secure, and we cannot guarantee absolute security of your data. You may have certain rights regarding your personal information, including rights to access, correct, or delete your data. To exercise these rights or for any questions about our data practices, please contact us at . We retain personal information for as long as necessary to provide our Services and comply with legal obligations. You may request deletion of your account and associated personal information, subject to our legal and operational requirements. Please note that your information may be transferred to and processed in countries other than your country of residence. By using our Services, you consent to the transfer of information to countries that may have different data protection rules than your country.
# Privacy Policy ## Creditcoin OÜ Privacy Policy Last revised on: February 4, 2025 *** Thank you for choosing to be part of our community at Creditcoin OÜ. We are committed to protecting your personal information (also known as personally identifiable information or “PII”) and your right to privacy. If you have any questions or concerns about our Privacy Policy, or our practices with regards to your PII, please contact us at . This Privacy Policy explains what you can expect from Creditcoin in protecting your PII and what we need from you to ensure such efforts succeed. This Privacy Policy applies to: (i) all information collected through our websites located at (the “Website(s)”), (ii) your access to and use of our API or Apps, (iii) and/or any related services, marketing, or events (collectively, the “Services”); and to the extent applicable, (iv) your access to and use of the Credit Wallet in connection with any biometric data – please also see the Creditcoin Terms, including Section 2 on biometric data: . The Creditcoin Terms are incorporated by reference into these Privacy Policy, and all capitalized terms (unless defined in this document) are defined in the Creditcoin Terms. **Please read this Privacy Policy carefully as it is legally binding when you access or use our Services, and will help you make informed decisions about sharing your PII with us. If you do not agree with our Privacy Policy as contained herein, do not use our Services. By accessing or using our Services, you agree to be bound by this Privacy Policy. This Privacy Policy may change from time to time (see Changes to Our Privacy Policy). Your continued use of our Services after we make changes is deemed to be acceptance of those changes, so please check back periodically for updates.** ## 1. WHAT INFORMATION DO WE COLLECT? We collect your PII directly from you when you provide it to us when utilizing the Services, automatically as you navigate through the Websites and when you participate in activities on the Websites, Apps, or when you otherwise contact us. The PII we collect may include (but is not limited to): * Email address * Public wallet address * Biometric data, such as your fingerprint(s), facial scan, or other physical or behavioral identifiers in connection with your use of the Services or Creditcoin’s Wallet. * Usage details, IP addresses, etc. * Blockchain-related information, blockchain identifiers, such as: blockchain addresses and public keys * Transaction information, transactions you make via our Services, including: names of recipients, amounts of transactions, time stamps. * Third-party wallet (“Third-Party Wallet”) information, such as: public wallet address, encrypted Wallet private keys (although private keys are not visible on to us), and token IDs that you own. (See Third-Party Wallet Extensions below). * Other PII that is deemed helpful in verifying whether you are eligible to register on our Services. * Other PII that is deemed helpful in ensuring our compliance with legal obligations under applicable anti-money laundering (AML) obligations, including but not limited to the U.S. Bank Secrecy Act (BSA) and/or the European Union’s Fourth AML Directive. * Other PII that is required by any court order, applicable law, administrative regulation or any order by a competent government agency. ## 2. HOW DO WE USE YOUR INFORMATION? We only use your PII when we are permitted to do so under applicable legislation. We always ensure that we have a lawful basis for any use of PII. Most commonly, we will use your PII: (1) to perform pursuant to a contract , (2) pursuant to our own legitimate interests, (3) to comply with legal obligations, and (4) pursuant to customer consent. We use the PII we collect or receive to: * **Provide Services to you.**\ We may use your PII to provide the Wallet Services and Browsing Services to you, such as your biometric data. We may use your PII in connection with, or during your use of our Services to facilitate interaction and/or collaboration with other users of our Services. * **Send administrative information to you.**\ We may use your PII to send you information about changes to our terms, conditions, and policies. * **Send marketing communications to you.**\ We may use your PII to send you marketing communications regarding our newsletters and other promotional materials. You may opt out of these communications at any time by emailing us at [team@creditcoin.org](emailto:team@Creditcoin.org). * **Request Feedback.** \ We may use your PII to request feedback and to contact you about your use of our Websites or Apps. * **Protect our Websites and Apps.** \ We may use your PII as part of our efforts to keep our Websites and Apps safe and secure (for example, for fraud monitoring and prevention). * **Enforce our terms.**\ We may use your PII to assist with enforcement of the Creditcoin Terms and this Privacy Policy and other agreements. * **Respond to legal requests and prevent harm.**\ If we receive a subpoena or other legal, regulatory or compliance request, we may need to inspect the information we hold to determine how to respond. * **Verify your identity.**\ We may use your PII to verify your identity, the nature and ownership of your business, source of funds, to facilitate the processing of funds, to evaluate the risk of doing business with you, or for other purposes related to the provision of the Services. ## 3. WHO WILL YOUR INFORMATION BE SHARED WITH? **Data Processors** We use carefully selected service providers (data processors) in processing your PII. We only use service providers that provide sufficient guarantees to implement appropriate technical and organizational security measures to protect your PII. Such data processors may include the following: email service providers, website analytics service providers, liquidity providers and data hosting service providers. Should you require more detailed information as regards the data processors we use, please contact us at [team@creditcoin.org](emailto:team@Creditcoin.org). **Third Parties**. In some circumstances, we share your PII with third parties who act as independent data controllers as regards to your PII. We only share and disclose your PII with the following third parties. We have categorized each party so that you may easily understand the purpose of our data collection and processing practices. * **Business Partners.** \ We may share or transfer your PII in connection with, or during your use of our Services for, facilitating interaction and/or collaboration with other users of our Services; including by not limited to third-party partners like Veriff for identity verification and certification services. * **Purchasers of Our Business.**\ We may share or transfer your PII to an acquirer, successor, or assignee/licensee in connection with, or during negotiations of, any merger, sale of company assets, financing, or acquisition of all or a portion of our business to another company. The legal basis for this is our legitimate interest to exercise our right to business. In such case, we ensure that your rights and conditions as a data subject shall not be harmed or affected. * **Law Enforcement.**\ We may share your PII in order to comply with our legal, compliance, regulatory, insurance policy and record-keeping obligations as well as to respond to mandatory legal or governmental requests or demands for information, enforce our agreements, policies, procedures and terms of use, and protect ourselves, our Users, or the general public from illegal activities. * **Parties Pursuant to Protecting Our Legal Rights** \ We may also need to share your PII with third parties in relation to our need to protect our legal rights (which may include attorneys and debt collection agencies). This is done under our own legitimate interest to protect our legal rights and ensure the performance of this Privacy Policy and any other agreements related to our Services. * **Parties Pursuant to Our Legal Obligations**\ We may need to share your PII with third persons in order to fulfill our legal obligations. Such third persons may include auditors, national regulators or other authorities. The legal basis for such sharing is to maintain compliance with our legal obligations and statutory requirements. ## 4. HOW LONG DO WE KEEP YOUR INFORMATION? To determine the appropriate retention period for PII, we consider the amount, nature and sensitivity of the PII, the potential risk of harm from unauthorized use of or disclosure of your PII, the purposes for which we process your PII and whether we can achieve those purposes through other means, and the applicable legal, regulatory, tax, accounting or other requirements. We will only keep your PII for as long as it is necessary for the purposes set out in this Privacy Policy, unless a longer retention period is required or permitted by law (such as tax, accounting, reporting, national and international AML or other legal requirements). When we have no ongoing legitimate business need to process PII, we will either delete or anonymize it, or, if this is not possible (for example, because the PII has been stored in backup archives), then we will securely store the PII and isolate it from any further processing until deletion is possible. Your PII will only be accessed internally on a need-to-know basis, and it will only be accessed or processed if absolutely necessary. We will constantly monitor and delete data that is no longer required by any relevant law or jurisdiction in which we operate. If your PII is processed for several different purposes, the longest retention period shall apply. ## 5. HOW DO WE KEEP YOUR INFORMATION SAFE? **Security.** Creditcoin strives to ensure that our systems are secure and that they meet industry standards. We seek to protect PII that is provided to Creditcoin by implementing physical and electronic safeguards, including measures designed to secure your PII from accidental loss and from unauthorized access, use, alteration, and disclosure. Creditcoin endeavors to engage third-party service providers that have security and confidentiality policies, if such third-party service providers have access to our PII. Despite our best efforts to protect the security of your PII, no security system is always effective and we cannot guarantee that our systems will be completely secure. Any transmission of PII is at your own risk. We are not responsible for circumvention of any privacy settings or security measures contained on the Websites. ## 6. DO WE COLLECT INFORMATION FROM MINORS? Persons under the age of 18 are not allowed to use the Websites or Apps and we do not knowingly collect PII from persons under 18 years of age. By using the Websites or Apps, you represent that you are at least 18. If we learn that we have collected PII about a person under the age of 18 years of age, we will deactivate the account and take reasonable measures to promptly delete such data from our records. If you become aware of any PII we have collected from a person under age 18, please contact us at [team@creditcoin.org](emailto:team@Creditcoin.org). ## 7. USE OF COOKIES Cookies are small files that a site or its service provider transfers to your computer’s hard drive through your web browser (if you permit it) that enables the site to recognize your browser and capture and remember certain information. Creditcoin uses cookies in order to provide better service, to facilitate our Users’ use of our Websites, to track usage of the Websites, to collect data and to address certain security issues. When you access our Websites, we send the cookies to your computer or phone. Your computer or phone stores the cookie in a file located inside your web browser. The cookies help Creditcoin keep track of your visits to our Websites and your activity on our Websites and to understand how you interact with us. We may link the information collected by cookies with other information we collect from you pursuant to this Privacy Policy and use the combined information as set forth herein. Similarly, the third parties who serve cookies on our Websites may link your name or email address to other information they collect, which may include past purchases made offline or online, or your online usage information. You can generally activate or later deactivate the use of cookies through a functionality built into your web browser. Please note that removing or deactivating cookies can impact your user experience on our Services, including limiting the functionality of certain features. If you want to learn more about cookies, or how to control, disable or delete them, please visit this site for detailed guidance. In addition, certain third-party advertising networks, including Google, permit users to opt out of or customize preferences associated with your internet browsing. To learn more about this feature from Google, [click here](https://adssettings.google.com/u/0/authenticated). Creditcoin also uses Google Analytics, which uses cookies and similar technologies to collect and analyze information about the use of the Websites and report on activities and trends. The following link explains how Google uses data when you use its partners’ websites and applications: . Your use of Creditcoin’s website is evidence of your consent to Creditcoin storing and accessing cookies and other information on your computer or phone and Creditcoin’s use of Google Analytics in connection with such activities. Please read the information at the link provided so you understand what you are consenting to. Should you wish to opt-out of Google’s practices, you may do so by downloading the Google Analytics opt-out browser add-on, available at . ## 8. CONTROLS FOR DO-NOT-TRACK FEATURES Most web browsers and some mobile operating systems and mobile applications include a Do-Not-Track (“DNT”) feature or setting you can activate to signal your privacy preference not to have data about your online browsing activities monitored and collected. No uniform technology standard for recognizing and implementing DNT signals has been finalized. As such, we do not currently respond to DNT browser signals or any other mechanism that automatically communicates your choice not to be tracked online. If a standard for online tracking is adopted that we must follow in the future, we will inform you about that practice in a revised version of this Privacy Policy. ## 9. THIRD-PARTY WALLET INFORMATION AND EXTENSIONS We collect Third-Party Wallet information in order to facilitate your use of the Services. Certain transactions conducted via our Services, will require you to connect a Third-Party Wallet to the Services. By using such Third-Party Wallet to conduct such transactions via the Services, you agree that your interactions with such Third-Party Wallets are governed by the privacy policy for the applicable Third-Party Wallet. We expressly disclaim any and all liability for actions arising from your use of Third-Party Wallets, including but without limitation, to actions relating to the use and/or disclosure of PII by such Third-Party Wallets. ## 10. PRIVACY RIGHTS WITH RESPECT TO YOUR PII Depending on the jurisdiction, you may have the right to access, correct, delete, or restrict the use of your PII covered by this Privacy Policy. Depending on the jurisdiction, you may also have the right to request that we refrain from processing your PII. Please bear in mind that if you choose to exercise such rights, this may affect our ability to provide Creditcoin services. For further inquiries about your PII, please contact us by sending an email to and Creditcoin will make reasonable efforts to accommodate your request. However, we also reserve the right to impose certain restrictions and requirements on such requests, if allowed or required by applicable laws. Please also note that it may take some time to process your requests, consistent with applicable law across jurisdictions. ## 11. PRIVACY RIGHTS UNDER THE EUROPEAN GENERAL DATA PROTECTION REGULATION (“GDPR”) Residents of the European Economic Area (“EEA”) and Switzerland (“EEA Residents”) are entitled to make requests regarding the processing and storage of their PII. Specifically, if you are an EEA Resident, you may submit a request to us to take the following actions in relation to your PII that we hold: * **Opt-out.**\ You may request that we stop sending you direct marketing communications which you have previously consented to receive. We may continue to send you service-related and other non-marketing communications. * **Access.**\ You may request we provide you with information about our processing of your PII and give you access to your PII. * **Rectify.**\ You may request we update or correct inaccuracies in your PII. * **Erase.**\ You may request we erase your PII. * **Export.**\ You may request we transfer a machine-readable copy of your PII to you or a third party of your choice. * **Restrict.**\ You may request we restrict the processing of your PII. * **Object.**\ You may object to our reliance on our legitimate interests as the basis of our processing of your PII that impacts your rights. You may do this at any time by emailing [team@Creditcoin.org](emailto:team@Creditcoin.org). Note that we may refuse to grant your requests in whole or in part as permitted by applicable law. You have the right to complain to a data protection authority about our collection and use of your PII. For more information, please contact your local data protection authority. To find contact details, [click here](https://ec.europa.eu/justice/article-29/structure/data-protection-authorities/index_en.htm). ## 12. LEGAL BASIS FOR PROCESSING PII Our legal basis for collecting and using the PII described above will depend on the PII concerned and the specific context in which we collect it. However, we will normally collect PII from you only (i) where we need the PII to perform a contract with you; (ii) where the processing is in our legitimate interests and not overridden by your rights; or (iii) where we have your consent to do so. We have a legitimate interest in operating our Services and communicating with you as necessary to provide these Services, for example when responding to your queries, improving our Services, undertaking marketing, or for the purposes of detecting or preventing illegal activities. In some cases, we may also have a legal obligation to collect PII from you or may otherwise need the PII to protect your vital interests or those of another person. If we ask you to provide PII to comply with a legal requirement or to perform a contract with you, we will make this clear at the relevant time and advise you whether the provision of your PII is mandatory or not (as well as of the possible consequences if you do not provide your PII). ## 13. INTERNATIONAL TRANSFERS OF PII Your PII will be stored and processed in the United States and will be governed by applicable United States laws and regulations, as well as the rules outlined in this Privacy Policy. If you use the Services from outside the United States, you acknowledge that we will transfer your PII to, and store your PII in, the United States, which may have different data protection rules than in your country. PII may become accessible as permitted by law in the United States, including to law enforcement and/or national security authorities in the United States. Additionally, your PII may be transferred to, processed, and stored by our service providers in other countries. For instance, we may engage ID verification services located outside the United States, which may use non-US servers to store and process your PII. By submitting your PII, you consent to its transfer to and storage in both the United States and other countries designated by us, its exclusive governance by the law and regulations of the United States and any applicable state laws, and its use in accordance with the purposes for which it was originally collected and as set forth in this Privacy Policy. ## 14. NOTICE TO CALIFORNIA RESIDENTS – YOUR CALIFORNIA PRIVACY RIGHTS (AS PROVIDED BY CALIFORNIA CIVIL CODE SECTION 1798.83) CALIFORNIA RESIDENT WHO HAS PROVIDED PII TO A BUSINESS WITH WHOM HE/SHE HAS ESTABLISHED A BUSINESS RELATIONSHIP FOR PERSONAL, FAMILY, OR HOUSEHOLD PURPOSES (A “CALIFORNIA CUSTOMER”) MAY REQUEST INFORMATION ABOUT WHETHER THE BUSINESS HAS DISCLOSED PII TO ANY THIRD PARTIES FOR THE THIRD PARTIES’ DIRECT MARKETING PURPOSES. IN GENERAL, IF THE BUSINESS HAS MADE SUCH A DISCLOSURE OF PII, UPON RECEIPT OF A REQUEST BY A CALIFORNIA CUSTOMER, THE BUSINESS IS REQUIRED TO PROVIDE A LIST OF ALL THIRD PARTIES TO WHOM PII WAS DISCLOSED IN THE PRECEDING CALENDAR YEAR, AS WELL AS A LIST OF THE CATEGORIES OF PII THAT WERE DISCLOSED. CALIFORNIA CUSTOMERS MAY REQUEST FURTHER INFORMATION ABOUT OUR COMPLIANCE WITH THIS LAW BY E-MAILING [TEAM@CREDITCOIN.ORG](emailto:team@Creditcoin.org). PLEASE NOTE THAT WE ARE REQUIRED TO RESPOND TO ONE REQUEST PER CALIFORNIA CUSTOMER EACH YEAR AND WE ARE NOT REQUIRED TO RESPOND TO REQUESTS MADE BY MEANS OTHER THAN THROUGH THIS E-MAIL ADDRESS. ## 15. CHANGES TO OUR PRIVACY POLICY Creditcoin reserves the right to make changes to this Privacy Policy from time to time, and you are responsible for periodically checking this policy for any changes. If we make material changes to our Privacy Policy, our revised Privacy Policy will be promptly posted at , and it will either be prominently noted on our Websites that material changes have been made or we will notify our Users by email. The date of the most recent update to our Privacy Policy will be set forth in the header to the Privacy Policy. ## 16. HOW CAN YOU CONTACT US ABOUT THIS PRIVACY POLICY? If you have questions or concerns about our Privacy Policy practices, you may email us at [team@Creditcoin.org](emailto:team@Creditcoin.org).

# What is Credit Wallet? Credit Wallet is the official wallet app for the Creditcoin ecosystem, available for both Android and iOS platforms. It serves as your all-in-one tool for managing digital assets, interacting with decentralized applications (dApps), and engaging directly with the Creditcoin network. Experienced users and novices alike will find that Credit Wallet provides a seamless, secure, and intuitive solution for handling your crypto assets on the go. ### **What Can You Do with Credit Wallet?** With Credit Wallet, you gain full control over your digital assets and the ability to manage them within the Creditcoin ecosystem. Here's what you can do: * **Manage Your Digital Assets**: Store, send, and receive your assets securely. * **Interact with dApps**: Connect to a wide range of decentralized applications within the EVM ecosystem using WalletConnect. * **Seamless Transfers**: Easily transfer your Mainnet CTC tokens between Creditcoin’s Native and EVM-compatible addresses. * **Optimize Transactions**: Adjust your gas fees and transaction speeds according to your needs. * **Test Features Safely**: Switch to Testnet mode to explore the app and its features in a safe test environment. ### **Key Features of Credit Wallet** 1. **Multi-Address Support** Credit Wallet supports up to 3 wallets, each capable of generating 15 unique wallet addresses. This allows you to manage your assets across multiple accounts while keeping them secure and private. 2. **EVM Compatibility** Credit Wallet is compatible with the Ethereum Virtual Machine ecosystem, enabling you to seamlessly interact with various decentralized applications via WalletConnect. 3. **User-Friendly Interface** Navigate through your wallet, track your assets, and interact with dApps effortlessly, regardless of your crypto experience level. 4. **Enhanced Security** As a non-custodial wallet, Credit Wallet ensures that you maintain control over your private keys. It employs top-level security measures, so your funds are secure, recoverable, and accessible only by you. 5. **Optimized Gas Fees** Choose between three different transaction speeds, each with a corresponding gas fee rate, allowing you to prioritize cost or speed based on your needs. 6. **Testnet Mode** Enable Testnet Mode to explore and experiment within supported testnet environments, risk-free. 7. **Native<>EVM Transfers** Seamlessly transfer Mainnet CTC tokens between your Creditcoin Native and EVM-compatible addresses, simplifying asset flows within the Creditcoin ecosystem. ### **How to Get Started with Credit Wallet** Getting started with Credit Wallet is quick and easy. Follow these steps: 1. **Download Credit Wallet** Install the app on your smartphone using the links below: * [Download on Google Play](https://bit.ly/3yMmVcM) * [Download on iOS App Store](https://apple.co/4dHFaiE) 2. **Set Up Your Wallet** Upon opening the app, follow the setup instructions to create your wallet and securely back up your recovery phrase. 3. **Fund Your Wallet** Transfer funds into your wallet by sending assets to your Credit Wallet address from any supported exchange or wallet. Ensure that you have enough funds to cover transaction fees. 4. **Start Using Credit Wallet** Begin managing your assets, interacting with dApps, and exploring the Creditcoin ecosystem. For a more detailed guide on using Credit Wallet, check out our [Step-by-Step Tutorial](https://bit.ly/4e4C7Re). # Credit Wallet Guide
Welcome Credit Penguins to the Credit Wallet App Guide! This tutorial will walk you through the phases of setting up and using your wallet. Let's get into it! #### 1. Download and Installation Start by downloading the Credit Wallet app: * Google Play: [https://play.google.com/store/apps/details?id=com.creditcoin.mobile](https://play.google.com/store/apps/details?id=com.creditcoin.mobile) * iOS App Store: The good news is that you can download Credit Wallet on multiple devices, allowing you to access your crypto assets wherever and whenever you need it most. #### 2. Wallet Creation and Recovery Once you’ve installed and opened the app, you have a few options to pick from: **Create a New Wallet** You can generate an entirely new wallet. When you do, be sure to store your recovery phrase in a safe and secure location. Some people choose to stamp their seed phrases into metallic plates, but one thing has to be clear—**never share your personal recovery phrase and avoid storing it online**.
You can create up to 3 wallets with the app, each of which may contain 15 unique addresses! For convenience, you can even give nicknames to frequently used or even hide addresses to keep everything clutter-free. **Wallet Recovery and Cloud Backup** If you already have an existing wallet, you can easily recover it with a recovery phrase. The app also supports cloud backups, allowing you to utilize either iCloud or Google Drive. #### 3. Asset Management **Adding and Viewing Assets** * **Manage Assets:** You can add Creditcoin, Ethereum, and other EVM-supported assets to the wallet and keep track of the balances in one place. When new tokens are added, the ticker and logo will be automatically detected and recognized within 1-2 minutes. * **Transaction History:** Whenever you add new tokens and interact with smart contracts on-chain, you can always review recent activities to find details like the wallets involved, the transaction hash, and the swapped funds.
#### 4. Token Transactions **Receiving Assets** * **Generate QR Code:** First, navigate to the receiving page and generate a QR code. You can also copy it to your clipboard with a single tap, and use it to populate smart contracts with your address. **Sending Assets** * **Set the Amount:** Select how much to send based on our available funds. You can also select ‘Max’ to send all the funds available from a given token you wish to send. * **Select Recipient:** Enter the recipient’s address manually, copy it from your clipboard, or select from any of your nicknamed contacts in the address book. * **Adjust Transaction Fees:** Depending on network congestion, choose from three tiers of transaction speeds to optimize the desired gas fees.
**Creditcoin Testnet Support** * **Activate Testnet Mode:** Enable testnet mode from the settings menu to play around with testnets. Creditcoin Testnet (EVM), Creditcoin Native Testnet (Substrate), and Ethereum Sepolia are supported. **Token Transfer Between Creditcoin Native (Substrate) and Creditcoin (EVM)** * **Substrate to EVM Transfer:** Select the CTC token on the Creditcoin Native chain, enter the Creditcoin chain address (0x...xx), and send. * **EVM to Substrate Transfer:** Select the CTC token on the Creditcoin chain, enter the Creditcoin Native chain address (5x...xx), and send. #### 5. Address Book Feature **Managing the Address Book** * **Add and Edit Addresses:** Store frequently used addresses in your address book for quick access and make edits as needed. * **Delete Addresses:** Remove any addresses you no longer use to keep your address book organized.
#### 6. WalletConnect **Connect to third-party apps:** Use the WalletConnect integration to securely connect your wallet to supported dApps like Uniswap and Blur. Always stay vigilant to ensure you’re on the official websites and that you trust the dApp to which you’re connecting your wallet.
# How to enable Testnet tokens In order to interact with testnet with CreditWallet, you will need to enable testnet assets. First tap on the "More" button at the bottom right of the screen :
Then tap on "Display Testnet Asset"\
Then tap on the slider button to enable showing testnet assets
Testnet assets will now display in your CreditWallet. # How to Delete Your Wallet Deleting your wallet will permanently remove it and all associated data from the app. This action cannot be undone, so please ensure that you have securely backed up your recovery phrase and transferred any funds to another wallet before proceeding. ### Steps to Delete Your Wallet To delete your wallet, follow these steps: #### 1. Access the "More" Menu * Open the wallet app on your device. * Tap on the **"More"** option located at the bottom right of the screen.
#### 2. Initiate the Sign Out Process * Select **"Delete wallets"**. A confirmation pop-up will appear with the message **"Are you sure you want to delete you wallets?"**. This message is a reminder that if you delete your wallets without saving your recovery phrase, you could lose access to your wallet. * In the pop-up, tap on **"Delete everything"** to proceed with the deletion process.
#### 3. Confirm the Deletion * On the final screen, you will be asked to confirm that you have saved your recovery phrase. Ensure that you check the box confirming this. * Tap on **"Delete wallets now"** to permanently delete the wallet.
Once these steps are completed, your wallet will be deleted from the app, and all personal information (passcode, biometrics) will be deleted from your device. # Terms Of Use ## Creditcoin OÜ. Terms of Use Last revised on: August 27, 2024 *** Please review these Terms of Use (“Terms” or “Creditcoin Website Terms”) carefully, as they set forth the legally binding terms and conditions that govern your use of our websites located at , (“Websites”), your access to and use of our mobile, tablet and other smart device applications, and application program interfaces (“API”) services (collectively, "Apps"), including related trademarks, software code, and other intellectual property, as well as software service for storing and transferring digital assets on various blockchain networks including self-custody externally owned accounts (“EOA”) and smart contract wallets (commonly known as Credit Wallet) (the “Credit Wallet” or the "Wallet"). By accessing or using the Websites, Wallet, or Apps, you represent that you are age 18 or older (or age 19 or older as required by certain, applicable jurisdictions). If you are between the ages of 13 and 17 or below the age of majority in your jurisdiction, you represent that your legal guardian has reviewed and agreed to these Terms.\ The Websites are a copyrighted work belonging to Creditcoin OÜ (“Creditcoin,” “Company,” “us,” “our,” and “we”). Your submission of information, including personally identifiable information (“PII”), through or in connection with the Websites is governed by the terms of our privacy policy as updated from time to time, available at (“Privacy Policy”). \ You consent to us collecting, accessing, using, processing, disclosing and retaining any PII you provide to us for the purpose of us providing the Services or the Wallet (defined below) to you. This consent is not related to, and does not affect, any rights or obligations we or you have in accordance with data protection laws, privacy laws, and regulations. \* \* \*\ THESE TERMS SET FORTH THE LEGALLY BINDING TERMS AND CONDITIONS THAT GOVERN YOUR USE OF THE SERVICES AND THE WALLET. BY ACCESSING OR USING THE SERVICES OR THE WALLET, YOU ARE ACCEPTING THESE TERMS (ON BEHALF OF YOURSELF OR THE ENTITY THAT YOU REPRESENT), AND YOU REPRESENT AND WARRANT THAT YOU HAVE THE RIGHT, AUTHORITY, AND CAPACITY TO ENTER INTO THESE TERMS (ON BEHALF OF YOURSELF OR THE ENTITY THAT YOU REPRESENT). IF YOU DO NOT AGREE WITH ALL OF THE PROVISIONS OF THESE TERMS, DO NOT ACCESS AND/OR USE THE SERVICES (AS DEFINED BELOW) OR THE WALLET.\ THESE TERMS REQUIRE THE USE OF ARBITRATION ([SECTION 9.2](#id-9.-general)) ON AN INDIVIDUAL BASIS TO RESOLVE DISPUTES, RATHER THAN JURY TRIALS OR CLASS ACTIONS, AND ALSO LIMIT THE REMEDIES AVAILABLE TO YOU IN THE EVENT OF A DISPUTE.\ \* \* \* Changes to Terms of Use. We may modify the Terms at any time at our sole discretion. If we do so, we’ll let you know either by posting the modified Terms on the Website, by providing you with a notice through the Wallet, or through other methods of communication which we deem reasonable. The modified Terms will be effective at the time they are posted on the Website. It’s important that you review the Terms whenever we modify them because if you continue to use the Services or the Wallet after we have modified the Terms, you agree to be bound by the modified Terms. If you don’t agree to be bound by the modified Terms, then you may not use the Services or the Wallet. Because our Services are evolving over time we may change or discontinue all or any part of the Wallet, or Services, at any time and without notice, at our sole discretion. ### 1. DESCRIPTION OF SERVICES. 1. **Users.** \ Users of the Websites ("Users") will be able to access and browse the Website including the Documentation ("Browsing Services"), and access Creditcoin's Apps. A User is not required to register an account to access the Browsing Services or the Wallet. 2. **Use of Services.** \ No accounts are required for any apps on Creditcoin, and this policy is expected to continue. The Creditcoin app functions as a wallet with Create and Import wallet features. Users can access the Services without the need for registration. The "Services" refer to the Browsing Services, the Wallet, API services, and Swap Services, which are further defined in the sections below. 3. **Use of the Wallet.** \ Creditcoin offers access to its Wallet which enables users to (i) store digital assets; (ii) access a digital asset browser and link to third party decentralized exchanges ("DEXs") and third party decentralized applications (together with DEXs, collectively "Dapp(s)"); (iii) view addresses and information that are part of digital asset networks and broadcast transactions; (iv) participate in retail DEX trades and associated DEX activity; (v) utilize the Credit Wallet for storing and managing digital assets; and (vi) additional functionality as Creditcoin may add to the Wallet from time to time; and educational resources ("Documentation") through its Websites. 4. **Swap Services.** \ Creditcoin provides the following swap services: \ (a) wCTC <--> CTC Swap: A service enabling users to exchange CTC from the Creditcoin blockchain to wCTC on the Ethereum blockchain, and vice versa. (i) Users send tokens to a designated address provided by Creditcoin. (ii) Creditcoin sends the equivalent amount to the user's address on the respective network. (iii) Users are responsible for providing accurate addresses and covering network fees.(iv) Creditcoin may, at its sole discretion, implement and modify various terms and conditions for the swap service, including but not limited to minimum and maximum swap amounts, processing times, and other operational parameters. These terms are subject to change from time to time without prior notice. Users are encouraged to review the current terms before initiating a swap.
(b) G-CRE -> CTC Swap: A one-way service exchanging G-CRE on Ethereum for CTC on Creditcoin at a 1:1 ratio. (i) The process may be automated or manual, subject to change without notice. (ii) Users must provide a valid CTC address for receiving swapped tokens. (iii) The service is subject to availability and may be suspended at Creditcoin's discretion. For both swap services:\ (i) Blockchain transactions are irreversible; Creditcoin cannot recover funds sent to incorrect addresses. (ii) Creditcoin may require additional verification for large amounts or suspicious activities. (iii) Users must comply with applicable laws and regulations. (iv) Creditcoin reserves the right to refuse service at its sole discretion. ### 2. ACCESS TO THE SERVICES. 1. **License.**\ Subject to these Terms, Creditcoin grants you a non-transferable, non-exclusive, revocable, limited license to use and access the Services or the Wallet for your own personal and noncommercial use. 2. **Certain Restrictions.**\ The rights granted to you in these Terms are subject to the following restrictions: (a) you shall not license, sell, rent, lease, transfer, assign, distribute, host, or otherwise commercially exploit the Websites, whether in whole or in part, or any content displayed on the Websites; (b) you shall not (directly or indirectly) modify, decipher, disassemble, reverse compile or reverse engineer or otherwise attempt to derive any source code or underlying ideas or algorithms of any part of the Services or the Wallet; (c) you shall not access the Service or Wallet in order to build a similar or competitive website, product, or service; (d) translate, or otherwise create derivative works of any part of the Services or the Wallet; (e) rent, lease, distribute, or otherwise transfer any of the rights that you receive hereunder; (f) frame or mirror any part of the Service without Creditcoin’s express prior written consent; (g) create a database by systematically downloading and storing Website or API content; (h) use any robot, spider, search/retrieval application or other manual or automatic device to retrieve, harvest, index, “scrape,” “data mine” or in any way gather Website, Wallet, or API content or reproduce or circumvent the navigational structure or presentation of the Website without Creditcoin’s express prior written consent and (i) except as expressly stated herein, no part of the Website may be copied, reproduced, distributed, republished, downloaded, displayed, posted or transmitted in any form or by any means. Unless otherwise indicated, any future release, update, or other addition to functionality of the Website or API shall be subject to these Terms. All copyright and other proprietary notices on the Website or API (or on any content displayed on the Website or API) must be retained on all copies thereof. 3. **Who May Use the Wallet.**\ You may use the Wallet if you are 18 years or older and are not barred from using the Wallet under applicable law. 4. **Modification.**\ Creditcoin reserves the right, at any time, to modify, suspend, or discontinue the Services or the Wallet (in whole or in part) with or without notice to you. You agree that Creditcoin will not be liable to you or to any third party for any modification, suspension, or discontinuation of the Services or any part thereof. Creditcoin further reserves the right to modify the Wallet to incorporate Web3 functionalities, enhance user experience, or comply with emerging technological standards. Despite any such modifications, you, as the user, will retain full responsibility for the security and management of your own private keys associated with the Wallet. 5. **No Support or Maintenance.**\ You acknowledge and agree that Creditcoin will have no obligation to provide you with any support or maintenance in connection with the Services or the Wallet. 6. **Ownership.**\ You acknowledge that all the intellectual property rights, including copyrights, patents, trademarks, and trade secrets, in the Services or the Wallet and its content are owned by Creditcoin. Neither these Terms (nor your access to the Services or the Wallet) transfers to you or any third party any rights, title or interest in or to such intellectual property rights, except for the limited access rights expressly set forth in these Terms. Creditcoin and its suppliers reserve all rights not granted in these Terms. There are no implied licenses granted under these Terms. You own and control digital assets held in your Wallet. As the sole owner of digital assets in your Wallet, you shall bear all risk of loss of such digital assets. Creditcoin OÜ shall have no liability for digital asset fluctuations or loss associated with your use of the Wallet. At any time, subject to outages, downtime, and other applicable policies, you may withdraw your digital assets by sending it to a different blockchain address. You acknowledge that by engaging to use the Wallet you are at no time transferring your assets to Creditcoin OÜ or its affiliates. 7. **Fees.**\ We may charge fees for some or part of the use of the Services or Wallet we make available to you. We reserve the right to change those fees at our discretion. We will disclose the amount of fees we will charge you for the applicable Services or Wallet function at the time that you access the Wallet function. You may incur charges from third parties for use of linked services. For example, you may be charged fees via the Dapps and/or DEXs that you may access via use of the Wallet. Third party fees are not charged by Creditcoin OÜ and are not paid to Creditcoin OÜ. 8. **Acceptable Use Policy.**\ The following terms constitute our “Acceptable Use Policy”: (a) You agree not to: (i) upload, transmit, or distribute to or through the Services or the Wallet any computer viruses, worms, or any software intended to damage or alter a computer system or data; (ii) use the Services or the Wallet to harvest, collect, gather or assemble information or data regarding other users, including e-mail addresses, without their consent; (iii) interfere with, disrupt, or create an undue burden on servers or networks connected to the Services or the Wallet, or violate the regulations, policies or procedures of such networks; (iv) attempt to gain unauthorized access to the Services or the Wallet (or to other computer systems or networks connected to or used together with the Services or the Wallet), whether through password mining or any other means; (iv) harass or interfere with any other user’s use and enjoyment of the Services or the Wallet; or (v) use software or automated agents or scripts to produce multiple accounts on the Websites, or to generate automated searches, requests, or queries to (or to strip, scrape, or mine data from) the Services or the Wallet (provided, however, that we conditionally grant to the operators of public search engines revocable permission to use spiders to copy materials from the Services or the Wallet for the sole purpose of and solely to the extent necessary for creating publicly available searchable indices of the materials, but not caches or archives of such materials, subject to the parameters set forth in our robots.txt file). 9. **Wallet Restrictions.**\ You may use the Wallet or Service only for lawful purposes and in accordance with these Terms. You must not use the Wallet in any way that violates any applicable federal, state, local, or international law or regulation. You must not use the Wallet or Services if you are on any U.S. sanctions lists or located in any country that is subject to U.S. government sanctions or has been designated by the U.S. government as a "terrorist supporting" country. You must not use the Wallet or Services to engage in any fraudulent, abusive, or illegal activity, or to interfere with the security or functionality of the Wallet or any blockchain network. You must not attempt to gain unauthorized access to the Wallet, Services or any Creditcoin systems or networks. You must not copy, modify, distribute, sell, or lease any part of the Wallet or its content, or reverse engineer or attempt to extract the source code of the Wallet, except as expressly permitted by applicable law or with our prior written consent. We reserve the right to take any action we deem necessary to protect the Wallet and our rights and interests, including suspending or terminating your access to the Wallet, without notice or liability to you. Creditcoin reserves the right to determine what conduct it considers to be in violation of these restrictions. Creditcoin reserves the right to take action as a result, which may include prohibiting you from accessing Services provided by Creditcoin in whole or in part. Any restrictions imposed by Creditcoin will not affect your ability to transfer your digital assets. 10. **Recovery Phrase and Passkeys.**\ You are solely responsible for the retention and security of your Wallet credentials, your twelve-word recovery phrase for EOA wallets (“Recovery Phrase”) and your unique digital or hardware credentials (for example, iCloud and Google Passkeys, hardware authentication devices such as Yubikeys) that are tied to your smart contract wallets (“Passkeys”). Your Recovery Phrase and/or Passkeys are the only way to access the cryptocurrency associated with your account. Anyone that has access to your Recovery Phrase and/or Passkeys can access your cryptocurrency. 11. **Biometric Data.**\ The Wallet allows you to use biometric data, such as your fingerprint or face recognition, to unlock the Wallet and authorize transactions. You acknowledge and agree that your biometric data is stored locally on your device and not by Creditcoin. You are solely responsible for the security and integrity of your biometric data and your device. You must not share your device or your biometric data with anyone or allow anyone to access the Wallet using your biometric data. You must notify us immediately if you suspect any unauthorized use of your biometric data or your device. We are not liable for any loss or damage resulting from your use of biometric data or your device. 12. **Enforcement.**\ We reserve the right (but have no obligation) to investigate and/or take appropriate action against you in our sole discretion if you violate the Acceptable Use Policy or any other provision of these Terms or otherwise create liability for us or any other person. Such action may include terminating your access to the Services in accordance with Section 8, and/or reporting you to law enforcement authorities. 13. **Feedback.**\ If you provide Creditcoin with any feedback or suggestions regarding the Services or the Wallet (“Feedback”), you hereby assign to Creditcoin all rights in such Feedback and agree that Creditcoin shall have the right to use and fully exploit such Feedback and related information in any manner it deems appropriate. Creditcoin will treat any Feedback you provide to Creditcoin as non-confidential and non-proprietary. You agree that you will not submit to Creditcoin any information or ideas that you consider to be confidential or proprietary. ### 3. INDEMNIFICATION. You agree to indemnify and hold Creditcoin (and its officers, employees, and agents) harmless, including costs and attorneys’ fees, from any claim or demand made by any third party due to or arising out of (a) your use of the Services or the Wallet, (b) your violation of these Terms, or (c) your violation of applicable laws or regulations. Creditcoin reserves the right, at your expense, to assume the exclusive defense and control of any matter for which you are required to indemnify us, and you agree to cooperate with our defense of these claims. You agree not to settle any matter without the prior written consent of Creditcoin. Creditcoin will use reasonable efforts to notify you of any such claim, action or proceeding upon becoming aware of it. ### 4. THIRD-PARTY LINKS & ADS; OTHER USERS 1. **Third-Party Links & Ads.**\ The Websites may contain links to third-party websites and services, and/or display advertisements for third parties (collectively, “Third-Party Links & Ads”). The inclusion of any link is not and does not imply an affiliation, sponsorship, endorsement, approval, investigation, verification or monitoring by Creditcoin of any information, materials, products, or services contained in or accessible through any Third-Party Application. Such Third-Party Links & Ads are not under the control of Creditcoin, and Creditcoin is not responsible for any Third-Party Links & Ads. Creditcoin provides access to these Third-Party Links & Ads only as a convenience to you, and does not review, approve, monitor, endorse, warrant, or make any representations with respect to Third-Party Links & Ads. Neither Creditcoin nor its partners endorse any of the opportunities that appear on these Websites, nor does Creditcoin and/or its partners make any recommendations regarding the appropriateness of particular opportunities for any Users. Each User must review and evaluate the opportunities in such User’s own discretion and determine the suitability of entering into any transaction. You use all Third-Party Links & Ads at your own risk, and should apply a suitable level of caution and discretion in doing so. When you click on any of the Third-Party Links & Ads, the applicable third party’s terms and policies apply, including the third party’s privacy and data gathering practices. You should make whatever investigation you feel necessary or appropriate before proceeding with any transaction in connection with such Third-Party Links & Ads. 2. **Release.**\ You hereby release and forever discharge Creditcoin (and our officers, employees, agents, successors, and assigns) from, and hereby waive and relinquish, each and every past, present and future dispute, claim, controversy, demand, right, obligation, liability, action and cause of action of every kind and nature (including personal injuries, death, and property damage), that has arisen or arises directly or indirectly out of, or that relates directly or indirectly to, the Services or the Wallet (including any or act or omission of any Third-Party Links & Ads). IF YOU ARE A CALIFORNIA RESIDENT, YOU HEREBY WAIVE CALIFORNIA CIVIL CODE SECTION 1542 IN CONNECTION WITH THE FOREGOING, WHICH STATES: “A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS WHICH THE CREDITOR DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE, WHICH IF KNOWN BY HIM OR HER MUST HAVE MATERIALLY AFFECTED HIS OR HER SETTLEMENT WITH THE DEBTOR.” ### 5. ACCURACY OF INFORMATION. We attempt to ensure that the information that we provide on these Websites are complete, accurate and current. Despite our efforts, the information on these Websites may occasionally be inaccurate, incomplete or out of date. We make no representation as to the completeness, accuracy or correctness of any information on these Websites. ### 6. DISCLAIMERS. THE SERVICES AND THE WALLET ARE PROVIDED ON AN “AS-IS” AND “AS AVAILABLE” BASIS, AND CREDITCOIN (AND OUR SUPPLIERS) EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES AND CONDITIONS OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ALL WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, QUIET ENJOYMENT, ACCURACY, OR NON-INFRINGEMENT. WE (AND OUR SUPPLIERS) MAKE NO WARRANTY THAT THE SERVICES OR THE WALLET WILL MEET YOUR REQUIREMENTS, WILL BE AVAILABLE ON AN UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE BASIS, OR WILL BE ACCURATE, RELIABLE, FREE OF VIRUSES OR OTHER HARMFUL CODE, COMPLETE, LEGAL, OR SAFE. IF APPLICABLE LAW REQUIRES ANY WARRANTIES WITH RESPECT TO THE SERVICES OR THE WALLET, ALL SUCH WARRANTIES ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF FIRST USE. IF YOU LOSE YOUR RECOVERY PHRASE AND/OR PASSKEYS OF YOUR WALLET, YOU WILL NOT BE ABLE TO ACCESS YOUR CRYPTOCURRENCY IN THE WALLET. YOU ACKNOWLEDGE THAT CREDITCOIN OÜ DOES NOT STORE AND IS NOT RESPONSIBLE IN ANY WAY FOR THE SECURITY OF YOUR RECOVERY PHRASE AND/OR PASSKEYS. YOU AGREE TO HOLD CREDITCOIN OÜ. AND ITS AFFILIATES HARMLESS FOR ANY LOSSES ARISING FROM YOU LOSING YOUR RECOVERY PHRASE AND/OR PASSKEYS. YOU AGREE THAT CREDITCOIN OÜ AND ITS AFFILIATES SHALL NOT BE LIABLE IN ANY WAY IF YOU LOSE YOUR RECOVERY PHRASE AND/OR PASSKEYS AND CANNOT ACCESS YOUR CRYPTOCURRENCY. CREDITCOIN DOES NOT ENDORSE ANY OTHER THIRD PARTY AND SHALL NOT BE RESPONSIBLE IN ANY WAY FOR ANY TRANSACTIONS YOU ENTER INTO WITH OTHER USERS. YOU AGREE THAT CREDITCOIN WILL NOT BE LIABLE FOR ANY LOSS OR DAMAGES OF ANY SORT INCURRED AS THE RESULT OF ANY INTERACTIONS BETWEEN YOU AND OTHER USERS. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. SOME JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU. ### 7. LIMITATION ON LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT SHALL CREDITCOIN BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOST PROFITS, LOST DATA, OR ANY INDIRECT, CONSEQUENTIAL, EXEMPLARY, INCIDENTAL, SPECIAL OR PUNITIVE DAMAGES ARISING FROM OR RELATING TO THESE TERMS OR YOUR USE OF, OR INABILITY TO USE, THE SERVICES OR THE WALLET, EVEN IF CREDITCOIN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ACCESS TO, AND USE OF, THE SERVICES OR THE WALLET IS AT YOUR OWN DISCRETION AND RISK, AND YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR DEVICE OR COMPUTER SYSTEM, OR LOSS OF DATA RESULTING THEREFROM. TO THE MAXIMUM EXTENT PERMITTED BY LAW, NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED HEREIN, OUR LIABILITY TO YOU FOR ANY DAMAGES ARISING FROM OR RELATED TO THIS AGREEMENT (FOR ANY CAUSE WHATSOEVER AND REGARDLESS OF THE FORM OF THE ACTION), WILL AT ALL TIMES BE LIMITED TO A MAXIMUM OF FIFTY US DOLLARS (U.S. $50). THE EXISTENCE OF MORE THAN ONE CLAIM WILL NOT ENLARGE THIS LIMIT. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU. ### 8. TERMS AND TERMINATION. Subject to this Section, these Terms will remain in full force and effect while you use the Services or the Wallet. We may suspend or terminate your rights to use the Services or the Wallet at any time for any reason at our sole discretion, including for any use of the Services or the Wallet in violation of these Terms. Upon termination of your rights under these Terms, your right to access and use the Services or the Wallet will terminate immediately. You understand that any termination of your right to use the services may involve deletion of your access to your API keys associated with your right to use the services from our live databases. Creditcoin will not have any liability whatsoever to you for any termination of your rights under these Terms, including for termination of your right to use the services. Even after your rights under these Terms are terminated, the following provisions of these Terms will remain in effect: Sections 2.2 through 2.6, and Sections 3, 4, 6 and 7. ### 9. GENERAL. 1. **Changes.**\ These Terms are subject to occasional revision, and if we make any substantial changes, we may notify you by sending you an e-mail to the last e-mail address you provided to us (if any), and/or by prominently posting notice of the changes on our Services. You are responsible for providing us with your most current e-mail address. In the event that the last e-mail address that you have provided us is not valid, or for any reason is not capable of delivering to you the notice described above, our dispatch of the e-mail containing such notice will nonetheless constitute effective notice of the changes described in the notice. Any changes to these Terms will be effective one (1) day following the earlier of our dispatch of an e-mail notice to you (if applicable) or one (1) day following our posting of notice of the changes on our Websites. These changes will be effective immediately for new users of our Services. Continued use of our Services following notice of such changes shall indicate your acknowledgement of such changes and agreement to be bound by the terms and conditions of such changes. 2. **Dispute Resolution.**\ Please read this Arbitration Agreement carefully. It is part of your contract with Creditcoin and affects your rights. It contains procedures for mandatory binding arbitration and a class action waiver. * **(a) Applicability of Arbitration Agreement.** All claims and disputes (excluding claims for injunctive or other equitable relief as set forth below) between Creditcoin and any User or Registered User that cannot be resolved informally or in small claims court shall be resolved by binding arbitration on an individual basis under the terms of this Arbitration Agreement. Unless otherwise agreed to, all arbitration proceedings shall be held in English. This Arbitration Agreement applies to you and Creditcoin, and to any subsidiaries, affiliates, agents, employees, predecessors in interest, successors, and assigns, as well as all authorized or unauthorized users or beneficiaries of services or goods provided under the Terms. * **(b) Notice Requirement and Informal Dispute Resolution.** Before either party may seek arbitration, the party must first send to the other party a written Notice of Dispute (“Notice”) describing the nature and basis of the claim or dispute, and the requested relief. Each party hereby irrevocably and unconditionally consents to service of process through personal service at their corporate headquarters, registered address, or primary address (for individuals or sole proprietors). Nothing in these Terms will affect the right of any party to serve process in any other manner permitted by Law. After the Notice is received, you and Creditcoin may attempt to resolve the claim or dispute informally. If you and Creditcoin do not resolve the claim or dispute within thirty (30) days after the Notice is received, either party may begin an arbitration proceeding. The amount of any settlement offer made by any party may not be disclosed to the arbitrator until after the arbitrator has determined the amount of the award, if any, to which either party is entitled. * **(c) Arbitration Rules.** Arbitration shall be initiated through the American Arbitration Association (“AAA”), an established alternative dispute resolution provider (“ADR Provider”) that offers arbitration as set forth in this section. If AAA is not available to arbitrate, the parties shall agree to select an alternative ADR Provider. The rules of the ADR Provider shall govern all aspects of the arbitration, including but not limited to the method of initiating and/or demanding arbitration, except to the extent such rules are in conflict with the Terms. The AAA Consumer Arbitration Rules (“Arbitration Rules”) governing the arbitration are available online at [www.adr.org](http://www.adr.org) or by calling the AAA at 1-800-778-7879. The arbitration shall be conducted by a single, neutral arbitrator. Any claims or disputes where the total amount of the award sought is less than Ten Thousand U.S. Dollars (US $10,000.00) may be resolved through binding non-appearance-based arbitration, at the option of the party seeking relief. For claims or disputes where the total amount of the award sought is Ten Thousand U.S. Dollars (US $10,000.00) or more, the right to a hearing will be determined by the Arbitration Rules. Any hearing will be held in a location within 100 miles of your residence, unless you reside outside of the United States, and unless the parties agree otherwise. If you reside outside of the U.S., the arbitrator shall give the parties reasonable notice of the date, time and place of any oral hearings. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. If the arbitrator grants you an award that is greater than the last settlement offer that Creditcoin made to you prior to the initiation of arbitration, Creditcoin will pay you the greater of the award or $2,500.00. Each party shall bear its own costs (including attorney’s fees) and disbursements arising out of the arbitration and shall pay an equal share of the fees and costs of the ADR Provider. * **(d) Additional Rules for Non-Appearance Based Arbitration.** If non-appearance based arbitration is elected, the arbitration shall be conducted by telephone, online and/or based solely on written submissions; the specific manner shall be chosen by the party initiating the arbitration. The arbitration shall not involve any personal appearance by the parties or witnesses unless otherwise agreed by the parties. * **(e) Time Limits.** If you or Creditcoin pursue arbitration, the arbitration action must be initiated and/or demanded within the statute of limitations (i.e., the legal deadline for filing a claim) and within any deadline imposed under the AAA Rules for the pertinent claim. * **(f) Authority of Arbitrator.** If arbitration is initiated, the arbitrator will decide the rights and liabilities, if any, of you and Creditcoin, and the dispute will not be consolidated with any other matters or joined with any other cases or parties. The arbitrator shall have the authority to grant motions dispositive of all or part of any claim. The arbitrator shall have the authority to award monetary damages, and to grant any non-monetary remedy or relief available to an individual under applicable law, the AAA Rules, and the Terms. The arbitrator shall issue a written award and statement of decision describing the essential findings and conclusions on which the award is based, including the calculation of any damages awarded. The arbitrator has the same authority to award relief on an individual basis that a judge in a court of law would have. The award of the arbitrator is final and binding upon you and Creditcoin. * **(g) Waiver of Jury Trial.** THE PARTIES HEREBY WAIVE THEIR CONSTITUTIONAL AND STATUTORY RIGHTS TO GO TO COURT AND HAVE A TRIAL IN FRONT OF A JUDGE OR A JURY, INSTEAD ELECTING THAT ALL CLAIMS AND DISPUTES SHALL BE RESOLVED BY ARBITRATION UNDER THIS ARBITRATION AGREEMENT. ARBITRATION PROCEDURES ARE TYPICALLY MORE LIMITED, MORE EFFICIENT AND LESS COSTLY THAN RULES APPLICABLE IN A COURT AND ARE SUBJECT TO VERY LIMITED REVIEW BY A COURT. IN THE EVENT ANY LITIGATION SHOULD ARISE BETWEEN YOU AND CREDITCOIN IN ANY STATE OR FEDERAL COURT IN A SUIT TO VACATE OR ENFORCE AN ARBITRATION AWARD OR OTHERWISE, YOU WAIVE ALL RIGHTS TO A JURY TRIAL, INSTEAD ELECTING THAT THE DISPUTE BE RESOLVED BY A JUDGE. * **(h) Waiver of Class or Consolidated Actions.** ALL CLAIMS AND DISPUTES WITHIN THE SCOPE OF THIS ARBITRATION AGREEMENT MUST BE ARBITRATED OR LITIGATED ON AN INDIVIDUAL BASIS AND NOT ON A CLASS BASIS, AND CLAIMS OF MORE THAN ONE USER CANNOT BE ARBITRATED OR LITIGATED JOINTLY OR CONSOLIDATED WITH THOSE OF ANY OTHER USER. * **(i) Confidentiality.** All aspects of the arbitration proceeding, including but not limited to the award of the arbitrator and compliance therewith, shall be strictly confidential. The parties agree to maintain confidentiality unless otherwise required by law. This paragraph shall not prevent a party from submitting to a court of law any information necessary to enforce this Agreement, to enforce an arbitration award, or to seek injunctive or equitable relief. * **(j) Severability.** If any part or parts of this Arbitration Agreement are found under the law to be invalid or unenforceable by a court of competent jurisdiction, then such specific part or parts shall be of no force and effect and shall be severed and the remainder of the Agreement shall continue in full force and effect. * **(k) Right to Waive.**\ Any or all of the rights and limitations set forth in this Arbitration Agreement may be waived by the party against whom the claim is asserted. Such waiver shall not waive or affect any other portion of this Arbitration Agreement. * **(l) Survival of Agreement.**\ This Arbitration Agreement will survive the termination of your relationship with Creditcoin. * **(m) Small Claims Court.**\ Notwithstanding the foregoing, either you or Creditcoin may bring an individual action in small claims court. * **(n) Emergency Equitable Relief.**\ Notwithstanding the foregoing, either party may seek emergency equitable relief before a state or federal court in order to maintain the status quo pending arbitration. A request for interim measures shall not be deemed a waiver of any other rights or obligations under this Arbitration Agreement. * **(o) Claims Not Subject to Arbitration.**\ Notwithstanding the foregoing, claims of defamation, violation of the Computer Fraud and Abuse Act, and infringement or misappropriation of the other party’s patent, copyright, trademark or trade secrets shall not be subject to this Arbitration Agreement. * **(p) Courts.**\ In any circumstances where the foregoing Arbitration Agreement permits the parties to litigate in court, the parties hereby agree to submit to the personal jurisdiction of the courts located within New York County, New York, for such purpose. 3. **Export.**\ The Services and the Wallet may be subject to U.S. export control laws and may be subject to export or import regulations in other countries. You agree not to export, reexport, or transfer, directly or indirectly, any U.S. technical data acquired from Creditcoin, or any products utilizing such data, in violation of the United States export laws or regulations. 4. **Disclosures.**\ Creditcoin is located at the address in Section 9.10. If you are a California resident, you may report complaints to the Complaint Assistance Unit of the Division of Consumer Product of the California Department of Consumer Affairs by contacting them in writing at 400 R Street, Sacramento, CA 95814, or by telephone at (800) 952-5210. 5. **Electronic Communications.**\ The communications between you and Creditcoin use electronic means, whether you use the Services or the Wallet or send us emails, or whether Creditcoin posts notices on the Websites or communicates with you via email. For contractual purposes, you (a) consent to receive communications from Creditcoin in an electronic form; and (b) agree that all terms and conditions, agreements, notices, disclosures, and other communications that Creditcoin provides to you electronically satisfy any legal requirement that such communications would satisfy if it were be in a hardcopy writing. The foregoing does not affect your non-waivable rights. Your consent will remain in effect until you withdraw it. 6. **Entire Terms.**\ These Terms constitute the entire agreement between you and us regarding the use of the Services or the Wallet. The section titles in these Terms are for convenience only and have no legal or contractual effect. The word “including” means “including without limitation.” If any provision of these Terms is, for any reason, held to be invalid or unenforceable, the other provisions of these Terms will be unimpaired and the invalid or unenforceable provision will be deemed modified so that it is valid and enforceable to the maximum extent permitted by law. You confirm that you are acting on your own behalf and not for the benefit of any other person. Your relationship to Creditcoin is that of an independent contractor, and neither party is an agent or partner of the other. These Terms, and your rights and obligations herein, may not be assigned, subcontracted, delegated, or otherwise transferred by you without Creditcoin ’s prior written consent, and any attempted assignment, subcontract, delegation, or transfer in violation of the foregoing will be null and void. Creditcoin may freely assign these Terms. The terms and conditions set forth in these Terms shall be binding upon assignees. 7. **Waiver.**\ A waiver by Creditcoin of any right or remedy under these Terms shall only be effective if it is in writing, executed by a duly authorized representative of Creditcoin and shall apply only to the circumstances for which it is given. Our failure to exercise or enforce any right or remedy under these Terms shall not operate as a waiver of such right or remedy, nor shall it prevent any future exercise or enforcement of such right or remedy. No single or partial exercise of any right or remedy shall preclude or restrict the further exercise of any such right or remedy or other rights or remedies. 8. **Governing Law and Jurisdiction.**\ These Terms and any dispute or claim arising out of or in connection with their subject matter or formation (including non-contractual disputes or claims) shall be governed by and construed in accordance with the law of Delaware. You agree that the courts of Delaware shall have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with the subject matter or formation (including non-contractual disputes or claims) of these Terms. If you are located outside of the United States (U.S.), your use or access the Services or the Wallet solely at your own risk and initiative. The Service is controlled and operated from facilities within the U.S. This Services is not intended to subject Creditcoin to non-U.S. jurisdiction or laws, except as otherwise expressly stated in this Agreement. The Service may not be appropriate or available for use in some jurisdictions. Creditcoin and its partners do not represent or warrant that the Services or the Wallet or any part thereof are appropriate or available for use in any particular jurisdiction other than the United States. In choosing to access the Services or the Wallet, you do so on your own initiative and at your own risk, and you are responsible for complying with all local laws, rules and regulations. SOME JURISDICTIONS HAVE CONSUMER PROTECTION AND OTHER LEGISLATION WHICH MAY APPLY TO THE SERVICES OR THE WALLET AND WHICH DO NOT ALLOW CERTAIN PROVISIONS SUCH AS LIMITATIONS OF LIABILITY AND EXCLUSION OF CERTAIN WARRANTIES, AMONG OTHERS. TO THE EXTENT THAT A LIMITATION, EXCLUSION, RESTRICTION OR OTHER PROVISION SET OUT BELOW IS SPECIFICALLY PROHIBITED BY APPLICABLE LAW, SUCH LIMITATION, EXCLUSION, RESTRICTION OR PROVISION MAY NOT APPLY TO YOU. 9. **Copyright/Trademark Information.**\ Copyright © 2024 Creditcoin OÜ All rights reserved. All trademarks, logos and service marks (“Marks”) displayed on the Websites are our property or the property of other third parties. You are not permitted to use these Marks without our prior written consent or the consent of such third party which may own the Marks. 10. **Contact Information :** \ Creditcoin OÜ\ ### 10. ASSOCIATED BRANDS. 1. **Cafe GM.**\ Cafe GM is a brand associated with Creditcoin OÜ. It is not a separate legal entity. Any services, products, or content provided under the Cafe GM brand are subject to these Terms. 2. **Spacecoin.** \ Spacecoin is a separate legal entity with its own website (). Creditcoin OÜ may provide links to the Spacecoin website. Your use of the Spacecoin website and any associated services is governed by Spacecoin's own terms of use and privacy policy. ### 11. DATA COLLECTION, USE, AND STORAGE. Creditcoin OÜ collects, uses, and stores user data in accordance with these Terms, our Privacy Policy, and applicable laws and regulations. By using our Services, you consent to our data practices as described in this section and our Privacy Policy. We may update our data practices from time to time, and your continued use of our Services after such changes constitutes acceptance of the updated practices. We may collect various types of data to provide and improve our Services. This includes personal information such as name, email address, and blockchain addresses; service usage data about your interactions with our Services; and device information about the hardware and software you use to access our Services. For our swap services, we specifically collect and process your email address and blockchain addresses for token transfers. This information is used solely for executing transactions, providing customer support, and communications related to the swap services. Regarding the Credit Wallet, and as stated above in Section 2.11 of this Agreement, the Wallet allows you to use biometric data, such as your fingerprint or face recognition, to unlock the Wallet and authorize transactions. You acknowledge and agree that any biometric data used for authentication is stored locally on your device and not collected, transmitted to, or stored by Creditcoin OÜ. You are solely responsible for the security and integrity of your biometric data and your device. You must not share your device or your biometric data with anyone or allow anyone to access the Wallet using your biometric data. You must notify us immediately if you suspect any unauthorized use of your biometric data or your device. We are not liable for any loss or damage resulting from your use of biometric data or your device. However, we may collect and store public blockchain addresses associated with your Credit Wallet, transaction histories, and token balances to provide and improve our Services. We use the collected data to provide, maintain, and improve our Services; process transactions and send notices about your transactions; resolve disputes and troubleshoot problems; prevent potentially prohibited or illegal activities; and enforce our Terms of Use. We may also use aggregated, anonymized data for analytical and statistical purposes. Creditcoin OÜ does not sell, rent, or share personal information with third parties except as described in these Terms and our Privacy Policy. We may share data with service providers and business partners who assist in providing our Services, law enforcement or regulatory agencies as required by law or to protect our rights, and other parties with your consent or at your direction. We implement reasonable security measures to protect against unauthorized access, alteration, disclosure, or destruction of personal information. However, no method of transmission over the Internet or electronic storage is 100% secure, and we cannot guarantee absolute security of your data. You may have certain rights regarding your personal information, including rights to access, correct, or delete your data. To exercise these rights or for any questions about our data practices, please contact us at . We retain personal information for as long as necessary to provide our Services and comply with legal obligations. You may request deletion of your account and associated personal information, subject to our legal and operational requirements. Please note that your information may be transferred to and processed in countries other than your country of residence. By using our Services, you consent to the transfer of information to countries that may have different data protection rules than your country.
# Privacy Policy ## Creditcoin OÜ Privacy Policy Last revised on: August 27, 2024 *** Thank you for choosing to be part of our community at Creditcoin OÜ. We are committed to protecting your personal information (also known as personally identifiable information or “PII”) and your right to privacy. If you have any questions or concerns about our Privacy Policy, or our practices with regards to your PII, please contact us at [team@creditcoin.org](emailto:team@Creditcoin.org). This Privacy Policy explains what you can expect from Creditcoin in protecting your PII and what we need from you to ensure such efforts succeed. This Privacy Policy applies to: (i) all information collected through our websites located at (the “Website(s)”), (ii) your access to and use of our API or Apps, (iii) and/or any related services, marketing, or events (collectively, the “Services”); and to the extent applicable, (iv) your access to and use of the Credit Wallet in connection with any biometric data – please also see the Creditcoin Terms, including Section 2 on biometric data: . The Creditcoin Terms are incorporated by reference into these Privacy Policy, and all capitalized terms (unless defined in this document) are defined in the Creditcoin Terms. **Please read this Privacy Policy carefully as it is legally binding when you access or use our Services, and will help you make informed decisions about sharing your PII with us. If you do not agree with our Privacy Policy as contained herein, do not use our Services. By accessing or using our Services, you agree to be bound by this Privacy Policy. This Privacy Policy may change from time to time (see Changes to Our Privacy Policy). Your continued use of our Services after we make changes is deemed to be acceptance of those changes, so please check back periodically for updates.** ## 1. WHAT INFORMATION DO WE COLLECT? We collect your PII directly from you when you provide it to us when utilizing the Services, automatically as you navigate through the Websites and when you participate in activities on the Websites, Apps, or when you otherwise contact us. The PII we collect may include (but is not limited to): * Email address * Public wallet address * Biometric data, such as your fingerprint(s), facial scan, or other physical or behavioral identifiers in connection with your use of the Services or Creditcoin’s Wallet. * Usage details, IP addresses, etc. * Blockchain-related information, blockchain identifiers, such as: blockchain addresses and public keys * Transaction information, transactions you make via our Services, including: names of recipients, amounts of transactions, time stamps. * Third-party wallet (“Third-Party Wallet”) information, such as: public wallet address, encrypted Wallet private keys (although private keys are not visible on to us), and token IDs that you own. (See Third-Party Wallet Extensions below). * Other PII that is deemed helpful in verifying whether you are eligible to register on our Services. * Other PII that is deemed helpful in ensuring our compliance with legal obligations under applicable anti-money laundering (AML) obligations, including but not limited to the U.S. Bank Secrecy Act (BSA) and/or the European Union’s Fourth AML Directive. * Other PII that is required by any court order, applicable law, administrative regulation or any order by a competent government agency. ## 2. HOW DO WE USE YOUR INFORMATION? We only use your PII when we are permitted to do so under applicable legislation. We always ensure that we have a lawful basis for any use of PII. Most commonly, we will use your PII: (1) to perform pursuant to a contract , (2) pursuant to our own legitimate interests, (3) to comply with legal obligations, and (4) pursuant to customer consent. We use the PII we collect or receive to: * **Provide Services to you.**\ We may use your PII to provide the Wallet Services and Browsing Services to you, such as your biometric data. We may use your PII in connection with, or during your use of our Services to facilitate interaction and/or collaboration with other users of our Services. * **Send administrative information to you.**\ We may use your PII to send you information about changes to our terms, conditions, and policies. * **Send marketing communications to you.**\ We may use your PII to send you marketing communications regarding our newsletters and other promotional materials. You may opt out of these communications at any time by emailing us at [team@creditcoin.org](emailto:team@Creditcoin.org). * **Request Feedback.** \ We may use your PII to request feedback and to contact you about your use of our Websites or Apps. * **Protect our Websites and Apps.** \ We may use your PII as part of our efforts to keep our Websites and Apps safe and secure (for example, for fraud monitoring and prevention). * **Enforce our terms.**\ We may use your PII to assist with enforcement of the Creditcoin Terms and this Privacy Policy and other agreements. * **Respond to legal requests and prevent harm.**\ If we receive a subpoena or other legal, regulatory or compliance request, we may need to inspect the information we hold to determine how to respond. * **Verify your identity.**\ We may use your PII to verify your identity, the nature and ownership of your business, source of funds, to facilitate the processing of funds, to evaluate the risk of doing business with you, or for other purposes related to the provision of the Services. ## 3. WHO WILL YOUR INFORMATION BE SHARED WITH? **Data Processors** We use carefully selected service providers (data processors) in processing your PII. We only use service providers that provide sufficient guarantees to implement appropriate technical and organizational security measures to protect your PII. Such data processors may include the following: email service providers, website analytics service providers, liquidity providers and data hosting service providers. Should you require more detailed information as regards the data processors we use, please contact us at [team@creditcoin.org](emailto:team@Creditcoin.org). **Third Parties**. In some circumstances, we share your PII with third parties who act as independent data controllers as regards to your PII. We only share and disclose your PII with the following third parties. We have categorized each party so that you may easily understand the purpose of our data collection and processing practices. * **Business Partners.** \ We may share or transfer your PII in connection with, or during your use of our Services for, facilitating interaction and/or collaboration with other users of our Services; including by not limited to third-party partners like Veriff for identity verification and certification services. * **Purchasers of Our Business.**\ We may share or transfer your PII to an acquirer, successor, or assignee/licensee in connection with, or during negotiations of, any merger, sale of company assets, financing, or acquisition of all or a portion of our business to another company. The legal basis for this is our legitimate interest to exercise our right to business. In such case, we ensure that your rights and conditions as a data subject shall not be harmed or affected. * **Law Enforcement.**\ We may share your PII in order to comply with our legal, compliance, regulatory, insurance policy and record-keeping obligations as well as to respond to mandatory legal or governmental requests or demands for information, enforce our agreements, policies, procedures and terms of use, and protect ourselves, our Users, or the general public from illegal activities. * **Parties Pursuant to Protecting Our Legal Rights** \ We may also need to share your PII with third parties in relation to our need to protect our legal rights (which may include attorneys and debt collection agencies). This is done under our own legitimate interest to protect our legal rights and ensure the performance of this Privacy Policy and any other agreements related to our Services. * **Parties Pursuant to Our Legal Obligations**\ We may need to share your PII with third persons in order to fulfill our legal obligations. Such third persons may include auditors, national regulators or other authorities. The legal basis for such sharing is to maintain compliance with our legal obligations and statutory requirements. ## 4. HOW LONG DO WE KEEP YOUR INFORMATION? To determine the appropriate retention period for PII, we consider the amount, nature and sensitivity of the PII, the potential risk of harm from unauthorized use of or disclosure of your PII, the purposes for which we process your PII and whether we can achieve those purposes through other means, and the applicable legal, regulatory, tax, accounting or other requirements. We will only keep your PII for as long as it is necessary for the purposes set out in this Privacy Policy, unless a longer retention period is required or permitted by law (such as tax, accounting, reporting, national and international AML or other legal requirements). When we have no ongoing legitimate business need to process PII, we will either delete or anonymize it, or, if this is not possible (for example, because the PII has been stored in backup archives), then we will securely store the PII and isolate it from any further processing until deletion is possible. Your PII will only be accessed internally on a need-to-know basis, and it will only be accessed or processed if absolutely necessary. We will constantly monitor and delete data that is no longer required by any relevant law or jurisdiction in which we operate. If your PII is processed for several different purposes, the longest retention period shall apply. ## 5. HOW DO WE KEEP YOUR INFORMATION SAFE? **Security.** Creditcoin strives to ensure that our systems are secure and that they meet industry standards. We seek to protect PII that is provided to Creditcoin by implementing physical and electronic safeguards, including measures designed to secure your PII from accidental loss and from unauthorized access, use, alteration, and disclosure. Creditcoin endeavors to engage third-party service providers that have security and confidentiality policies, if such third-party service providers have access to our PII. Despite our best efforts to protect the security of your PII, no security system is always effective and we cannot guarantee that our systems will be completely secure. Any transmission of PII is at your own risk. We are not responsible for circumvention of any privacy settings or security measures contained on the Websites. ## 6. DO WE COLLECT INFORMATION FROM MINORS? Persons under the age of 18 are not allowed to use the Websites or Apps and we do not knowingly collect PII from persons under 18 years of age. By using the Websites or Apps, you represent that you are at least 18. If we learn that we have collected PII about a person under the age of 18 years of age, we will deactivate the account and take reasonable measures to promptly delete such data from our records. If you become aware of any PII we have collected from a person under age 18, please contact us at [team@creditcoin.org](emailto:team@Creditcoin.org). ## 7. USE OF COOKIES Cookies are small files that a site or its service provider transfers to your computer’s hard drive through your web browser (if you permit it) that enables the site to recognize your browser and capture and remember certain information. Creditcoin uses cookies in order to provide better service, to facilitate our Users’ use of our Websites, to track usage of the Websites, to collect data and to address certain security issues. When you access our Websites, we send the cookies to your computer or phone. Your computer or phone stores the cookie in a file located inside your web browser. The cookies help Creditcoin keep track of your visits to our Websites and your activity on our Websites and to understand how you interact with us. We may link the information collected by cookies with other information we collect from you pursuant to this Privacy Policy and use the combined information as set forth herein. Similarly, the third parties who serve cookies on our Websites may link your name or email address to other information they collect, which may include past purchases made offline or online, or your online usage information. You can generally activate or later deactivate the use of cookies through a functionality built into your web browser. Please note that removing or deactivating cookies can impact your user experience on our Services, including limiting the functionality of certain features. If you want to learn more about cookies, or how to control, disable or delete them, please visit this site for detailed guidance. In addition, certain third-party advertising networks, including Google, permit users to opt out of or customize preferences associated with your internet browsing. To learn more about this feature from Google, [click here](https://adssettings.google.com/u/0/authenticated). Creditcoin also uses Google Analytics, which uses cookies and similar technologies to collect and analyze information about the use of the Websites and report on activities and trends. The following link explains how Google uses data when you use its partners’ websites and applications: . Your use of Creditcoin’s website is evidence of your consent to Creditcoin storing and accessing cookies and other information on your computer or phone and Creditcoin’s use of Google Analytics in connection with such activities. Please read the information at the link provided so you understand what you are consenting to. Should you wish to opt-out of Google’s practices, you may do so by downloading the Google Analytics opt-out browser add-on, available at . ## 8. CONTROLS FOR DO-NOT-TRACK FEATURES Most web browsers and some mobile operating systems and mobile applications include a Do-Not-Track (“DNT”) feature or setting you can activate to signal your privacy preference not to have data about your online browsing activities monitored and collected. No uniform technology standard for recognizing and implementing DNT signals has been finalized. As such, we do not currently respond to DNT browser signals or any other mechanism that automatically communicates your choice not to be tracked online. If a standard for online tracking is adopted that we must follow in the future, we will inform you about that practice in a revised version of this Privacy Policy. ## 9. THIRD-PARTY WALLET INFORMATION AND EXTENSIONS We collect Third-Party Wallet information in order to facilitate your use of the Services. Certain transactions conducted via our Services, will require you to connect a Third-Party Wallet to the Services. By using such Third-Party Wallet to conduct such transactions via the Services, you agree that your interactions with such Third-Party Wallets are governed by the privacy policy for the applicable Third-Party Wallet. We expressly disclaim any and all liability for actions arising from your use of Third-Party Wallets, including but without limitation, to actions relating to the use and/or disclosure of PII by such Third-Party Wallets. ## 10. PRIVACY RIGHTS WITH RESPECT TO YOUR PII Depending on the jurisdiction, you may have the right to access, correct, delete, or restrict the use of your PII covered by this Privacy Policy. Depending on the jurisdiction, you may also have the right to request that we refrain from processing your PII. Please bear in mind that if you choose to exercise such rights, this may affect our ability to provide Creditcoin services. For further inquiries about your PII, please contact us by sending an email to [team@Creditcoin.org](emailto:team@Creditcoin.org) and Creditcoin will make reasonable efforts to accommodate your request. However, we also reserve the right to impose certain restrictions and requirements on such requests, if allowed or required by applicable laws. Please also note that it may take some time to process your requests, consistent with applicable law across jurisdictions. ## 11. PRIVACY RIGHTS UNDER THE EUROPEAN GENERAL DATA PROTECTION REGULATION (“GDPR”) Residents of the European Economic Area (“EEA”) and Switzerland (“EEA Residents”) are entitled to make requests regarding the processing and storage of their PII. Specifically, if you are an EEA Resident, you may submit a request to us to take the following actions in relation to your PII that we hold: * **Opt-out.**\ You may request that we stop sending you direct marketing communications which you have previously consented to receive. We may continue to send you service-related and other non-marketing communications. * **Access.**\ You may request we provide you with information about our processing of your PII and give you access to your PII. * **Rectify.**\ You may request we update or correct inaccuracies in your PII. * **Erase.**\ You may request we erase your PII. * **Export.**\ You may request we transfer a machine-readable copy of your PII to you or a third party of your choice. * **Restrict.**\ You may request we restrict the processing of your PII. * **Object.**\ You may object to our reliance on our legitimate interests as the basis of our processing of your PII that impacts your rights. You may do this at any time by emailing [team@Creditcoin.org](emailto:team@Creditcoin.org). Note that we may refuse to grant your requests in whole or in part as permitted by applicable law. You have the right to complain to a data protection authority about our collection and use of your PII. For more information, please contact your local data protection authority. To find contact details, [click here](https://ec.europa.eu/justice/article-29/structure/data-protection-authorities/index_en.htm). ## 12. LEGAL BASIS FOR PROCESSING PII Our legal basis for collecting and using the PII described above will depend on the PII concerned and the specific context in which we collect it. However, we will normally collect PII from you only (i) where we need the PII to perform a contract with you; (ii) where the processing is in our legitimate interests and not overridden by your rights; or (iii) where we have your consent to do so. We have a legitimate interest in operating our Services and communicating with you as necessary to provide these Services, for example when responding to your queries, improving our Services, undertaking marketing, or for the purposes of detecting or preventing illegal activities. In some cases, we may also have a legal obligation to collect PII from you or may otherwise need the PII to protect your vital interests or those of another person. If we ask you to provide PII to comply with a legal requirement or to perform a contract with you, we will make this clear at the relevant time and advise you whether the provision of your PII is mandatory or not (as well as of the possible consequences if you do not provide your PII). ## 13. INTERNATIONAL TRANSFERS OF PII Your PII will be stored and processed in the United States and will be governed by applicable United States laws and regulations, as well as the rules outlined in this Privacy Policy. If you use the Services from outside the United States, you acknowledge that we will transfer your PII to, and store your PII in, the United States, which may have different data protection rules than in your country. PII may become accessible as permitted by law in the United States, including to law enforcement and/or national security authorities in the United States. Additionally, your PII may be transferred to, processed, and stored by our service providers in other countries. For instance, we may engage ID verification services located outside the United States, which may use non-US servers to store and process your PII. By submitting your PII, you consent to its transfer to and storage in both the United States and other countries designated by us, its exclusive governance by the law and regulations of the United States and any applicable state laws, and its use in accordance with the purposes for which it was originally collected and as set forth in this Privacy Policy. ## 14. NOTICE TO CALIFORNIA RESIDENTS – YOUR CALIFORNIA PRIVACY RIGHTS (AS PROVIDED BY CALIFORNIA CIVIL CODE SECTION 1798.83) CALIFORNIA RESIDENT WHO HAS PROVIDED PII TO A BUSINESS WITH WHOM HE/SHE HAS ESTABLISHED A BUSINESS RELATIONSHIP FOR PERSONAL, FAMILY, OR HOUSEHOLD PURPOSES (A “CALIFORNIA CUSTOMER”) MAY REQUEST INFORMATION ABOUT WHETHER THE BUSINESS HAS DISCLOSED PII TO ANY THIRD PARTIES FOR THE THIRD PARTIES’ DIRECT MARKETING PURPOSES. IN GENERAL, IF THE BUSINESS HAS MADE SUCH A DISCLOSURE OF PII, UPON RECEIPT OF A REQUEST BY A CALIFORNIA CUSTOMER, THE BUSINESS IS REQUIRED TO PROVIDE A LIST OF ALL THIRD PARTIES TO WHOM PII WAS DISCLOSED IN THE PRECEDING CALENDAR YEAR, AS WELL AS A LIST OF THE CATEGORIES OF PII THAT WERE DISCLOSED. CALIFORNIA CUSTOMERS MAY REQUEST FURTHER INFORMATION ABOUT OUR COMPLIANCE WITH THIS LAW BY E-MAILING [TEAM@CREDITCOIN.ORG](emailto:team@Creditcoin.org). PLEASE NOTE THAT WE ARE REQUIRED TO RESPOND TO ONE REQUEST PER CALIFORNIA CUSTOMER EACH YEAR AND WE ARE NOT REQUIRED TO RESPOND TO REQUESTS MADE BY MEANS OTHER THAN THROUGH THIS E-MAIL ADDRESS. ## 15. CHANGES TO OUR PRIVACY POLICY Creditcoin reserves the right to make changes to this Privacy Policy from time to time, and you are responsible for periodically checking this policy for any changes. If we make material changes to our Privacy Policy, our revised Privacy Policy will be promptly posted at , and it will either be prominently noted on our Websites that material changes have been made or we will notify our Users by email. The date of the most recent update to our Privacy Policy will be set forth in the header to the Privacy Policy. ## 16. HOW CAN YOU CONTACT US ABOUT THIS PRIVACY POLICY? If you have questions or concerns about our Privacy Policy practices, you may email us at [team@Creditcoin.org](emailto:team@Creditcoin.org). # How to Connect using Credit Wallet Before starting, make sure you have installed and created or imported a wallet on the Credit Wallet app (for more information visit : ). At the top rightmost of the page, click on WalletConnect.
Scan the QR code using any Wallet Connect supported App. We used our Credit Wallet for the steps below.
Once inside the Credit Wallet app, you will receive a request to connect your public wallet address. Click on "Connect" to grant this permission.
You can now verify that you have an active dApp connection at the bottom of your screen. You are now ready to use Credit Wallet to interact with Penguinswap.
# General This documentation aims at providing a guide for features included in our DEX product : Penguinswap. {% content-ref url="/pages/iNUGsw7bBPkRw0wUO3cH" %} [How to Connect using Credit Wallet](/dex) {% endcontent-ref %} {% content-ref url="/pages/YAB4C9bKZAPfmqTTwNoO" %} [What is an approval transaction](/dex/general/what-is-an-approval-transaction) {% endcontent-ref %} {% content-ref url="/pages/NcpWgf8t209b0W6ULJmN" %} [How to swap tokens](/dex/general/how-to-swap-tokens) {% endcontent-ref %} {% content-ref url="/pages/mH167pxJKhSxy0pApEcO" %} [How to change slippage](/dex/general/how-to-change-slippage) {% endcontent-ref %} {% content-ref url="/pages/Ma0filanrcRCaVNh5Phk" %} [What is price impact?](/dex/general/what-is-price-impact) {% endcontent-ref %} {% content-ref url="/pages/Q4phNuFiXiiSU2rxjNtk" %} [What are Penguinswap's fees?](/dex/general/what-are-penguinswaps-fees) {% endcontent-ref %} {% content-ref url="/pages/kVIfh8C1TA2vgZCekhYY" %} [What are token warnings?](/dex/general/what-are-token-warnings) {% endcontent-ref %} {% content-ref url="/pages/kVIfh8C1TA2vgZCekhYY" %} [What are token warnings?](/dex/general/what-are-token-warnings) {% endcontent-ref %} {% content-ref url="/pages/vxEVwEPiZHPuuIZwyl0p" %} [How to add liquidity](/dex/general/liquidity) {% endcontent-ref %} {% content-ref url="/pages/vKTdEJKxnXiBEmf0QUd6" %} [Claiming fees](/dex/general/claiming-fees) {% endcontent-ref %} # What is an approval transaction ## Transaction history signature request The first time you connect your wallet, you will be prompted to sign a message allowing you to view the transaction history for your specific wallet. This is done for security purposes and will not cost you any gas fees, nor does it allow Penguinswap to use any of your tokens.
Note: The approval is valid for almost a year, so practically speaking, it shouldn't be something that comes up too frequently outside of getting started. ## Token Approval Any token that you use for the first time on Penguinswap (and other dApps) will need to get approval via signature from your wallet. To do so, select the tokens you want to swap using our Penguinswap Web App.
Next, you will be asked to confirm your swap:
You will then be prompted to set a spending cap for the token. Please ensure to set a limit above the amount you wish to spend on your swap, accounting for some small fees. The approval amount in CreditWallet is set to "Unlimited". Then tap on approve.
Subsequently, you will then be able to proceed with the swap normally once that has been done. You should only have to do this once by token. Note that no approval is needed for Creditcoin's native currency, CTC—and that your token approval lasts until token limit is reached or until permission is revoked. # How to swap tokens Before beginning this part, make sure that you have CTC to pay for the swap gas fee. \ \ Click on Swap at the top of the page to initiate the process. \ Select the 2 token you want to swap.
Enter either the amount you want to swap from, or the amount you want to swap for.
You will now see the corresponding amount on the second token if you proceed with the swap. Click on "Swap" to proceed.
You will now see preview of the swap you are about to make. If you are comfortable with the output of the swap, you can now click "Swap" once more.
You can now confirm the transaction by tapping on "Submit" in your Credit Wallet.
Upon confirming the swap, you will get a "Swap pending" notice. It may take a few seconds before the confirmation is received for the transaction.
Once the transaction is confirmed on the blockchain, you will see : "Swap confirmed"
You should now see the swapped tokens in you wallet along with the transaction in the activity tab. # How to change slippage Price slippage refers to latency-induced price fluctuations, resulting from market dynamics between the moment in which you submit the transaction and the time which the swap is executed. \ \ By default, the cap on price slippage is set to 0.5% on Penguinswap. \ \ This means that with a slippage of 0.5%, you could receive up to 0.5% fewer tokens than expected on the preview swap screen depending on market conditions. \ \ Note that you can opt to change this value by clicking on the cog in the upper right-hand corner.
Then you may toggle from 'Auto' to 'Custom' to select a desired max slippage value.
The maximum slippage will now be reflected on the Swap screen.
# What is price impact? Price impact refers to the immediate effect your swap has on a token's price. Swapping a large amount relative to the liquidity available in the pool will result in a greater price impact. For example, if you attempt to buy 1,000 CTC in a CTC/USDC liquidity pool that holds only 5,000 CTC and 5,000 USDC, your trade will significantly move the market. This results in receiving fewer USDC per CTC compared to swapping a smaller amount, such as 10 CTC\ \ Price impact can be seen on Penguinswap on each swap as shown below:
# What are Penguinswap's fees? There are only 3 types of fees on PenguinSwap : * Operation fees * Pool fees * Network fees ### Operation Fees Right now the operation fees are set to 0% of Penguinswap:
### Pool Fees Pool fee~~s~~ are setup upon pool creation. On Penguinswap, there are 4 fee-tiers available upon pool creation: * 0.01% Best for very stable pairs * 0.05% Best for stable pairs * 0.3% Best for most pairs * 1% best for exotic pairs ### Network Fees The network fee represents the estimated cost required to send your swap transaction on the CTC network. It is independent of the amount swapped; however, more complex swaps (using multiple pools) will require more CTC to process. The gas fee token for the network is CTC (EVM). --- [Next Page](/llms-full.txt/1)