# Quickstart
Please note, the document is not final and never will be :)
| For Developers | For Users |
| --------------------------------------------------------------------- | ----------------------------------------------------------- |
| [What is PoSa consensus ?](/overview/consensus-posa) | [Network Endpoints](/building-on-bahamut/network-endpoints) |
| [Deploy Smart Contracts](/building-on-bahamut/deploy-smart-contracts) | [About $FTN](/building-on-bahamut/about-usdftn) |
| [Deploy a Token](/building-on-bahamut/deploy-a-token) | [Explorer](/building-on-bahamut/explorer) |
| [Deploy an NFT](/building-on-bahamut/deploy-an-nft) | |
| | |
# Introduction
**Welcome to Bahamut !**\
\
This guide aims to introduce you to the Bahamut blockchain ecosystem. Whether you're new to blockchain development or experienced with Ethereum, this resource will orient you to building on Bahamut's EVM-compatible network.\
\
**Bahamut** is an EVM-based, layer 1, public blockchain solution that aims to transform how distributed networks approach block rewards among network participants by adding a crucial parameter to the algorithm - **activity**. The activity parameter is represented by the amount of gas used by a validator's smart contract, and this amount is taken into consideration when distributing the chance to become a block proposer and earn rewards. Bahamut’s novelty consensus – **Proof of Stake and Activity (PoSA)**.
**PoSA** is a variation of PoS (Proof of Stake), which adds a new parameter called **activity**. This activity is represented by the total amount of gas spent by a validator-deployed smart contract, and it is taken into account when determining the chances of becoming a validator in the next epoch. Put simply, the more activity a validator has, the higher their chances of becoming a validator in the future, and the greater the rewards they can earn.
# Features
**EVM Compatible**\
\
Bahamut is EVM compatible. Deploy and run your dApps on Bahamut with your favorite tooling for Ethereum.
**Fast Finality**
The average block time of Bahamut is 10 seconds. A typical transaction can be included in a block in less than 6 seconds. And this block is finalized if more than half of all validators add their blocks after it.
**Low Cost**
Gas fee is paid with $FTN.
**Safe and Secure**
Each block is validated by trusted validators with their identities and $FTN as stakes.
# Consensus PoSa
**PoSA** is a novel consensus algorithm that blends the strengths of PoS with an additional activity factor. The **activity** factor is calculated based on the usage of the smart contracts deployed on the network. In simple terms, the more a smart contract is used, the more impact it will have in the consensus process. This creates an incentive for contract developers to create high-quality, highly-used contracts, as they will have more impact in the network.
**How Does PoSa Work?**
In **PoSa**, validators (i.e., nodes that validate transactions and blocks) must first stake a fixed amount of tokens, which is **8192** for all validators, to participate in the **consensus** process. This stake serves as collateral, ensuring that validators act in an honest manner. However, in **PoSa**, the ranking of a validator is determined not only by the size of their stake but also by the activity of their smart contracts.
The **activity** of a smart contract is the sum of all gas used by users when interacting with the contract. The more gas a contract uses, the more active it is considered to be. This activity is then combined with the validator's stake to determine their rank.
The advantage of this approach is two-fold. Firstly, it provides an **incentive** for developers to create high quality, highly used contracts, which helps to maintain the overall health and security of the network. Secondly, it helps to **decentralize** the network, as validators with high quality, high usability contracts will have a greater influence in the consensus process.
It's important to note that even validators without activity are still important to the network, as they play a role in maintaining its **security and stability**.
# Overview
If you're familiar with Ethereum development, transitioning to Bahamut is seamless. Switch to Bahamut's RPC and leverage tools like Truffle, Remix, and Web3js that you're already accustomed to. Deploy decentralized applications to Bahamut's Testnet or Mainnet for real-world use.\
\
**Wallets**
To interact with Bahamut, an Ethereum-based wallet is necessary due to its EVM foundation. Consider setting up wallets like Metamask or Arkane for seamless interaction. Further details on wallets and their significance are available in our wallet documentation.\
\
**Smart Contracts**
Explore a variety of services supporting testing, compiling, debugging, and deploying decentralized applications on the Bahamut network. Services such as thirdweb, Alchemy, Chainstack, QuickNode, Remix, Truffle, Hardhat, and Replit are supported.\
\
**Connecting to Bahamut**
Connect to Bahamut using MetaMask or directly through Arkane, enabling an RPC connection.\
\
**Public POS RPC Endpoints Directory**
Access a list of public endpoints for Bahamut's PoSA network in the RPC providers section. For blockchain information retrieval, utilizing the Alchemy SDK is recommended.\
\
**Discover resources to initiate dApp development on Bahamut:**
* Full Stack dApp: Tutorial Series
* Web3.js
* Ethers.js
* thirdweb
* Remix
* Truffle
* Metamask
* Arkane
* Develop a dApp using Fauna, Bahamut, and React
**Already Have a dApp?**
If you possess an existing dApp and seek more recognition from the network in the form of rewards, leverage Bahamut to:
* Effortlessly migrate from EVM-based chains
* Utilize Bahamut as a layer that will recognize your contribution and provide increased rewards via the PoSA consensus algorithm.
# Network Endpoints
This index guide contains network details for the Bahamut Mainnet and Bahamut Testnet and lists their associated RPC and node endpoints.\
\
**Bahamut Mainnet**\
\
The native token of the Bahamut Mainnet is $FTN and is used for gas.
| Properties | Network Details |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| Network Name | Bahamut Mainnet |
| ChainID | 5165 |
| Gas Token | FTN |
| Faucet | |
| RPC Endpoint |
|
| Web Socket Endpoint | wss\://ws1.bahamut.io, wss\://ws2.bahamut.io |
| Explorer | |
# Deploy Smart Contracts
This tutorial will teach you how to create, compile and deploy a smart contract on the Bahamut using Hardhat and Remix. \
\
[Hardhat](https://hardhat.org) is a development environment for DApp. It consists of different components for editing, compiling, debugging, and deploying your smart contracts and dApps.\
\
[Remix](https://remix.run/) is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience.
# Using Hardhat
#### What you will do[](https://wiki.polygon.technology/docs/develop/hardhat#what-you-will-do)
* Set up Hardhat
* Create a simple smart contract
* Compile contract
* Test contract
* Deploy contract
#### Pre-requisites[](https://docs.bnbchain.org/docs/hardhat-new#pre-requisites)
#### There are a few technical requirements before we start, as listed below:
* #### [Node.js v10+ LTS and npm](https://nodejs.org/en/) (comes with Node)
* #### [Git](https://git-scm.com/)
Once we have those installed, you need to create an npm project by going to an empty folder, running npm init --yes, and following its instructions to install Hardhat. Once your project is ready, you should run the following:
`npm install --save-dev hardhat`
To create your Hardhat project, run `npx hardhat` in your project folder. Let’s create the sample project and follow these steps to try out a sample task and compile, test, and deploy the sample contract.\
# Create a project
In your project folder, run npx hardhat to create a sample project. \
\
Choose to create typescript or javascript projects. Then you should create an .env file in the root to store your private key (wallet from which you need to deploy contracts). After that you need to add the Bahamut API key to the .env file for verifying the contract.
**Configure Hardhat**
Go to hardhat.config.js file. Add created API key and account PrivateKey to config file like this\`
`module.exports = {`
`defaultNetwork: "bahamut",`
`networks: {`
`sahara: {`
`url: "https://rpc1.bahamut.io",`
`accounts: [process.env.PRIVATE_KEY],`
`}`
`},`
`};`
\
# Compiling the contract
First of all you need to install hardhat-toolbox locally\`
`npm install --save-dev @nomicfoundation/hardhat-toolbox`
And then run to compile\`
`npx hardhat compile`
**Deploying the contract**
Run this command for contract deployment\`
`npx hardhat run scripts/deploy.js --network testnet`
If you want to deploy your smart contract to Bahamut Mainnet, at the Deploying stage, you need to use mainnet instead of testnet after --network.
After running the deployment script you will have a contract address and you can interact with the contract using that address.
# Using Remix
#### This tutorial will show you how to compile and deploy a smart contract using Remix.
### What you will do
* #### Create a file on Remix
* #### Upload or code the smart contract to the IDE
* #### Compile the smart contract
* #### Connect the application to chain via Metamask
* #### Deploy the smart contract
#### To start building a smart contract, click on New File and name it as HelloWorld.sol.
# Writing a Smart Contract
// SPDX-License-Identifier: MIT
// Specifies that the source code is for a version
// of Solidity greater than 0.8.15
pragma solidity ^0.8.15;
`contract HelloWorld {`
`// A publicly accessible function that takes a string as a parameter`
`` // and echoes the `message` ``
`function echo(string memory message) public pure returns (string memory) {`
`return message;`
`}`
`}`
# Compiling the contract
**Compile smart contract**
1. Switch to the Compiler tab
2. Select compiler version
3. Now, compile HelloWorld.sol
4. After successful compilation, it will show a green tick mark on the Compiler tab button
**Deploy Smart Contract**
In both Testnet and Mainnet, you do the below to deploy your smart contract using Remix.
1. Navigate to the Deployment tab
2. Select Injected Provider Metamask in the Environment dropdown, and your contract
3. Accept the Connect request received in MetaMask. You can also manually launch MetaMask if the popup doesn't open by default.
4. In MetaMask, once a transaction is deployed, you will receive another MetaMask pop-up that requires you to confirm the transaction. You just need to confirm the transaction.
# Deploy a Token
A BHRC20 token contract keeps track of fungible tokens: any token is exactly equal to any other token; no tokens have special rights or behavior associated with them. This makes BHRC20 tokens useful for things like a medium of exchange currency, voting rights, staking, and more. As we know, both OpenZeppelin and ConsenSys maintain the standard library of BHRC contract classes. Simply put, BHRC20 is nothing more than a class with methods and members that run the logic of what we usually call cryptocurrency. However, it has a broader meaning because it also has applications in other use cases. Let's move on to learning how to create and deploy an BHRC20 token with the OpenZepplin library.\
\
**Pre-requisites**
* Install Metamask
* Configure Bahamut Mainnet on Metamask
* Get mainnet token
Compile and Deploy BHRC20 Token. Open Remix IDE then create a new Token.sol contract and copy the below contract code to Token.sol.
// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.9;
`import "@openzeppelin/contracts/token/ERC20/ERC20.sol";`
`contract BHRC20Token is ERC20 {`
`constructor(uint256 totalSupply) ERC20("DemoToken", "DET") {`
`// create totalSupply of tokens for the deployer`
`_mint(msg.sender, totalSupply);`
`}`
`}`
**Compile the contract**
* Switch to the compile page
* Select proper compiler
* Select BHRC20Token(Token.sol) contract
* And then click Compile Token.sol
**Deploy the contract**
* Click the button to switch to deploy button
* Select Injected Provider-MetaMask
* Select BHRC20Token-Token.sol
* Fill in many tokens you want to mint and click Deploy button
Click Confirm button to sign and broadcast the transaction to chain.
**Add custom token to MetaMask**
1. Copy the deployed contract address
2. Click Import Tokens
3. Paste the contract address to the Token contract address
4. And the Token symbol and Token decimal will auto tilled by MetaMask
5. Finally, Click the Add custom token
6. Click the Import tokens button
When you reopen the MetaMask next time, you will see the token and amount.
# Deploy an NFT
We will build a BHRC721 contract based on the Openzeppelin contracts. Let's install Openzeppelin contracts for our project\`
`npm install @openzeppelin/contracts`
We can import the BHRC721 contract from Openzeppelin by the following import statement.
import "openzeppelin-contracts/contracts/token/BHRC721/BHRC721.sol";
**Pre-requisites**
1. Install Metamask
2. Configure Bahamut Mainnet on Metamask
3. Get mainnet token
**Compile and Deploy BHRC-721 Token**
Open Remix IDE then create a new MyNFT.sol contract and copy the below contract code to MyNFT.sol.
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;
import "openzeppelin-contracts/contracts/token/ERC721/ERC721.sol";
import "openzeppelin-contracts/contracts/access/Ownable.sol";
`contract MyNFT is ERC721, Ownable{`
`string private _URIBase;`
`constructor(string memory name_, string memory symbol_) ERC721(name_, symbol_) {`
`_transferOwnership(msg.sender);`
`}`
`function mint(address to, uint256 tokenId) public onlyOwner {`
`_safeMint(to, tokenId);`
`}`
`function setBaseURI(string memory baseURI_) public onlyOwner {`
`_URIBase = baseURI_;`
`}`
`function _baseURI() internal view override returns (string memory) {`
`return _URIBase;`
`}`
`}`
Deployment process is the same as mentioned in BHRC-20 token deployment. If everything goes well, we will see the address of the deployed contract and the transaction hash for the deployment. Then we can mint NFT.
**Add Metadata**
Our minted NFT has no metadata associated with it. Without metadata, an NFT token is nothing but a token with an ID. Our smart contract implements the BHRC721 meta extension, and it has the following method for getting the metadata URI of an NFT token:
function tokenURI(uint256 \_tokenId) external view returns (string);
Prepare Metadata
The metadata of an NFT token is presented in a JSON file. Here is an example:
{
"description": "My NFT",
"image": "your image url",
"name": "your token name",
"attributes": \[
{
"trait\_type": "xxxx",
"value": "yyyy"
},
{
"trait\_type": "xxxxx",
"value": yyyyy
}
]
}
1. Name is the name of this item(i.e, this NFT token), because each NFT token may have a different name.
2. Image is the link to the image of this NFT token.
3. Description is a short description of this NFT token.
4. Attributes is a list of attributes that this NFT token has.
Apart from the commonly used fields in the above example, some other fields are also supported in the metadata JSON file.
You should create one metadata JSON for each of your NFT tokens. Let's assume you are hosting all the metadata JSON files on the host of my-nft-metadata.com , and the metadata JSON of each NFT token should have the following format:
If you upload all your metadata JSON files to IPFS, you should add the whole directory that includes all the JSON files. Then, all the JSON files can be visited with the same base URI.
After uploading all the metadata JSON files somewhere and hosting them with the same base URI, we can set the base URI of the contract.
This standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as BHRC721 require deployment of separate contracts per token type. The BHRC721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the BHRC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.
**Compile and Deploy BHRC-1155 Token**
Open Remix IDE then create a new GameItems.sol contract and copy the below contract code to GameItems.sol.
// contracts/GameItems.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
contract GameItems is ERC1155 {
uint256 public constant GOLD = 0;
uint256 public constant SILVER = 1;
uint256 public constant THORS\_HAMMER = 2;
constructor() public ERC1155("") {
\_mint(msg.sender, GOLD, 10\*\*18, "");
\_mint(msg.sender, SILVER, 10\*\*27, "");<
# Explorer
**Mainnet Explorer**
*
**Testnet Explorer**
*
# Bridge
**Ethereum to Bahamut Bridge**
Access the [bridge here](https://bridge.fasttoken.com/).
The Ethereum to Bahamut bridge offers a secure and trustless one-way transaction channel between the Ethereum network and Bahamut blockchain. This bridge facilitates the seamless transfer of FTN from Ethereum to Bahamut, providing users with a reliable method to expand their token operations across the Bahamut network.
**Key Features of the Bridge**
* Trustless Interoperability: The one-way bridge ensures secure FTN transfers between Ethereum and Bahamut without exposure to third-party risks or market liquidity limitations.
* Availability: The bridge can support a large amount of liquidity when it comes to FTN, and has a clean user interface to make it easy and safe for each FTN bridge transfer.
* Functionality: The bridge ensures near-instant and cost-effective token transfers.
**Token Transfer Mechanism**
* Circulating Supply Preservation: Tokens crossing the bridge from Ethereum to Bahamut do not alter the circulating supply. The process involves burning the tokens upon departure from Ethereum and minting an equivalent amount (1:1) on the Bahamut blockchain on the same address.
# About $FTN
FTN, the native cryptocurrency of the Bahamut blockchain, serves as the primary unit of value within the ecosystem. Similar to how Ether (ETH) functions within Ethereum, FTN has multiple utilities and plays various roles within the Bahamut network.
**Fundamental Usage**
FTN serves as the essential currency for various transactions and operations within the Bahamut network. Specifically:
* Transaction Fees: FTN is the mandatory form of payment for transaction fees on the Bahamut network. Any action performed on the blockchain, such as smart contract execution or data storage, necessitates payment in FTN.
* Consensus and Validation: FTN is crucial for validating and proposing blocks on Bahamut's Mainnet, emphasizing its role in securing the network.
**Utility Beyond Transactions**
Beyond its primary function as a means of value transfer, FTN serves various purposes:
* DeFi Collateral: Similar to Ether's role in Ethereum's DeFi lending markets, FTN can serve as primary collateral within Bahamut's decentralized finance (DeFi) ecosystem.
* NFT Marketplaces: FTN may function as a unit of account within Non-Fungible Token (NFT) marketplaces on Bahamut, facilitating the exchange and valuation of digital assets.
* Service Payment: Individuals can earn FTN for providing services or selling goods within the Bahamut ecosystem, emphasizing its broader economic use.
**FTN and Network Resources**
Just as Ether regulates computing power allocation within Ethereum, FTN plays a crucial role in Bahamut's resource allocation. The finite nature of the shared computing resources on Bahamut necessitates a mechanism to fairly distribute resources among decentralized applications (dApps).
* Pricing Mechanism: FTN supports a pricing mechanism, governing the allocation of Bahamut's computing power. Users must pay FTN as gas fees for transaction execution based on the required computing resources and network demand.
* Balancing Network Usage: This mechanism prevents network abuse by ensuring that even if a dApp attempts to consume excessive resources through malicious or inefficient transactions, the execution would halt once the allocated FTN is depleted, restoring normal network operations.
**FTN vs. Bahamut**
It's essential to differentiate between Bahamut, the blockchain network, and FTN, its native cryptocurrency. While Bahamut hosts various functionalities and dApps, FTN acts as the primary unit of value and governance within this ecosystem.
# Hardware & System Req.
**System Requirements for Bahamut Nodes**
The system requirements outlined below apply to both the Sentry node and the Validator node within the Bahamut blockchain network.
Minimum System Requirements:
* RAM: 32 GB
* CPU: 8-core
* Storage: 2.5 TB SSD
**Note**: Minimum requirements enable node operation but may not ensure long-term compatibility with evolving network demands.
\
**For Amazon Web Services (AWS):**
* Sentry Equivalent: c5.2xlarge instance
* Validator Equivalent: c5.4xlarge instance (with unlimited credits selected)
Recommended System Requirements:
* RAM: 64 GB
* CPU: 16-core
* Storage: 5 TB SSD
* Bandwidth: 1 Gbit/s
**Note**: Recommended requirements ensure future-proof node operation, accommodating network advancements without constraints.\
\
**For Amazon Web Services (AWS):**
* Recommended Instance: m5d.4xlarge instance
**For OVH:**
* Recommended Instance: infra-3
**Network Data Transfer:**
* Expect 3-5 TB of data transferred per month as part of network operations.
**Note**: Always run the Sentry and Validator nodes on separate machines for optimal performance and network stability.
# Run a Full Node
# Hardware & System Req.
# Run a Validator Node
# Stake your validator
# Monitor validator performance
# Become a validator
Follow these steps to install and configure your setup to become a validator on the Bahamut network.
# Step 1: Install the Required Files
To become a validator, you need three core components:
1. Execution Layer: Syncs with the network, stores blockchain history, and manages interactions.
2. Consensus Layer: Supports the Proof of Stake and Activity (PoSA) consensus mechanism.
Validator Client: Handles validator duties and network participation.
**Install Using Pre-Built Binaries**
1. Clone the[ FastexLabs binaries repository](https://github.com/fastexlabs/binaries).
2. Follow the instructions in the[ README file](https://github.com/fastexlabs/binaries/blob/master/README.md).
Run the following commands in your terminal:
`cd binaries`
`chmod +x bahamut`
`./bahamut install`
`./bahamut validator install`
**Build from Source**
Currently, there are no open-source repositories available for building from source.
# Step 2: Run the Node
Start your validator client with the following command:
bash
`./bahamut start --network sahara`
# Step 3: Set Up Your Wallet
1. Ensure your wallet holds 8,192 FTN for staking.
If you don’t have a wallet, download the [YoWallet](https://www.yowallet.io/) and fund it with the required amount.
# Step 4: Generate Validator Keys
To generate a BLS key pair for your validator duties:
1. Download the
2. Follow the instructions here:
Keep your mnemonic phrase and keystore files safe—these are critical for managing your validator.
# Step 5: Import Validator Keys and Launch the Validator Client
After generating your keys, import them into the validator client.
1. Import the keystore files you generated:
`./bahamut validator import --validator-keys-dir=... --network=sahara`
2. Launch Validator Client
`./bahamut validator start -n=sahara`
# Step 6: Submit Deposit Data
Broadcast your deposit data to activate your validator:
* Use the deposit contract address (details to be provided).
Alternatively, upload the deposit\_data-\[timestamp].json file to the Bahamut Launchpad.
# Step 7: Set Withdrawal Credentials (BLS to Execution)
This step is optional, as withdrawal credentials can already be set during the deposit data generation process. If you’ve included an execution address in your initial deposit data, no further action is required, and your validator is ready to receive income.
If your validator is currently using BLS withdrawal credentials (Type 0, 0x00), you’ll need to perform a BLS to Execution transition to update the withdrawal credentials to an execution address (Type 1, 0x01). This transition is not done by sending a new deposit but through a specific API call made to your consensus client.
\
How to Perform the BLS to Execution Transition
1. Generate the BLS to Execution Message:\
Use the bls-to-execution command in the GoDepositCLI tool to create and sign the transition message. This message is required to update the withdrawal credentials.
2. Broadcast the Message Manually:\
Use your terminal to make the API call to your consensus client and broadcast the signed message. Here’s the command:\
\
`curl -X POST -H 'Accept: application/json' /eth/v1/beacon/pool/bls_to_execution_changes \`
`--data ''`
\
Finalize the Transition:\
Once the message is broadcasted, your withdrawal credentials will be updated, allowing income to be sent directly to your execution address.
#### Exiting the Validator (Optional)
If you decide to stop validating, follow the validator client’s exit procedure to safely withdraw your funds.
# Validator Checklist
This checklist is your guide to understanding the role of a validator and preparing for it step-by-step.
### Before You Start
Before starting the validator setup, ensure you're prepared with the right hardware, software, and knowledge.
#### Hardware Requirements
* Storage:
* * You’ll need \~1TB for Mainnet execution chain data. Total disk space for all clients is around 1TB.
* Prefer SSD storage to handle the required read/write speeds efficiently.
* Plan for additional space for maintenance and updates.
* CPU and RAM:
* * Use Bahamut's recommended hardware specs as a reference for your setup. It is preferable to use a quad-core (or dual-core hyperthreaded) CPU. At least 16 GB of RAM, 32GB is recommended
#### Internet Requirements
* A reliable, 24/7 connection is crucial to keep your node in sync and ready to validate.
* Ensure your internet bandwidth is not capped or throttled.
#### Important Notes
Avoid overly complex setups.
* Brief offline periods result in small penalties but can be easily recovered by staying online longer.
* Complicated backup systems might add unnecessary costs and risks.
Syncing your execution client can take several days, so plan accordingly.
Warning: Redundant backup validators can cause slashing, leading to serious penalties and ejection from the network.
### During Setup
Use this section to track your progress while setting up your validator.
#### Initial Setup
* Set up your chosen hardware and operating system.
#### Node Security
* Secure the root account.
* Set up a firewall.
* Forward the necessary ports for your Execution Client (EL) and Consensus Client (CL):
* * EL Port: 30303 TCP/UDP
* CL Ports: 13000 TCP, 12000 UDP
#### Time Synchronization
For Ubuntu 20.04:
1. Run: timedatectl
2. * Confirm NTP Service is active and your time settings (Local, Time zone, Universal) are correct.
3. If NTP isn’t active:
4. * Run: sudo timedatectl set-ntp on
* If you encounter issues, install chrony or ntp.
I verified that my server time matches the wall clock.
#### Execution Client Configuration
Install and sync your Execution Client following these instructions
.
All stakers must operate an execution client alongside a consensus client.
☑ I've installed and synced my execution client (this can take several days).
**Node Setup Tutorial**
Follow the Node Setup Tutorial to run a node on Bahamut.
Warning: Running your validator in multiple places will cause a slashable event and lead to ejection from the network.
#### JWT Authentication
Configuring JWT Authentication for HTTP Connections
To authenticate the HTTP connection between your beacon node and execution node, use a[ JWT token](https://jwt.io/).
Generate the token using this method:
1. OpenSSL:
openssl rand -hex 32 | tr -d "\n" > "jwt.hex"
Ensure the generated jwt.hex file is stored in your Bahamut directory:
📂Bahamut
┣ 📂consensus
┣ 📂execution
┣ 📄jwt.hex
Grant appropriate permissions for file access.
☑ I've set up a shared JWT secret and made it available to both my execution client, and my consensus client (beacon node)
#### Setting Addresses
Withdrawal Address:
* Set this when generating your validator keys to unlock rewards.
* If not set before depositing, update your keys with a BLSToExecutionChange message.
☑ I provided an Bahamut address when creating my deposit\_data\.json file. This is where I want my validator rewards and withdrawals to be sent.
☑ If I didn’t set a withdrawal address before depositing, I’ve updated it by submitting a BLSToExecutionChange message signed with my BLS withdrawal keys.
Fee Recipient Address:
* Assign an Bahamut address in your consensus client settings to receive transaction fee rewards.
See Fee Recipient Docs
☑ I provided an Bahamut address to my validator for receiving my fee rewards.
#### Consensus Layer Validator Client (VC)
Setting up your validator client is essential for participating in the network:
☑ I imported my keystore(s) into my validator client.
☑ I ensured my keystore(s) are stored only on one validator machine to avoid any potential conflicts or slashing risks.
☑ I started running my validator client and confirmed it is functioning correctly.
#### Consensus Layer Validator Client (VC)
Setting up your validator client is essential for participating in the network:
* I imported my keystore(s) into my validator client.
* I ensured my keystore(s) are stored only on one validator machine to avoid any potential conflicts or slashing risks.
* I started running my validator client and confirmed it is functioning correctly.
#### Deposit Data
This step is where you inform the network about your validator participation by generating and broadcasting your deposit data.
1. Download the necessary tools from this[ repository](https://github.com/VIWET/GoDepositCLI).
2. Follow the[ instructions](https://github.com/VIWET/GoDepositCLI/blob/develop/README.md) to generate deposit data with your new keys.
3. Launch your validator client to finalize the process.
4. Make a transaction via your selected wallet to broadcast your deposit data to a network.
### After Depositing
After setting up your validator, there are additional steps you can take to secure your funds and optimize your node:
#### Advanced System Architecture
* Consider using a trusted VPN to hide your IP address and protect your validator’s identity from being exposed to the network.
#### Graffiti
* Add a personal touch to your validator's proposed blocks using the graffiti flag. You can customize this with any text under 32 bytes.
☑ I’ve set my graffiti flag to personalize my validator's contributions.
# Staking Withdrawals
Here’s everything you need to know about the withdrawal process.
**Updating Withdrawal Credentials**
To enable withdrawals, you’ll need to update your validator account’s credentials from BLS (Type 0, 0x00) to execution (Type 1, 0x01). This change ensures your validator can send funds to an execution layer address.
Your withdrawal credentials are separate from your fee recipient address, which collects transaction fees from proposed blocks.
While they can be the same address, they must be set independently.
How to Update:
* Use tools like the Staking Deposit CLI to generate the key change message.
* This process requires your seed phrase and is best performed offline on an air-gapped machine.
After broadcasting the update, your validator will permanently switch to execution withdrawal credentials and become eligible for payouts.
**BLS to Execution Change (BTEC) Queue**
When updating credentials, your message joins the BLS to Execution Change (BTEC) queue. Each block processes up to 16 BTEC messages. If there’s a high volume of requests, a queue forms, and your message will be included in subsequent blocks.
Once updated, your validator is permanently enabled for withdrawals, making you eligible for reward payouts during the next balance sweep.
**Excess Balance Withdrawals (Partial Withdrawals)**
Validators earn rewards up to a maximum effective balance of 8,192 FTN. Any balance above this limit is automatically withdrawn to your Bahamut address.
Excess rewards are automatically withdrawn when your balance exceeds 8,192 FTN, while the remaining 8,192 FTN stays locked and staked. You cannot manually request specific withdrawal amounts.
Automatic withdrawals ensure your excess rewards are sent to your withdrawal address without impacting your validator’s status.
**Full Withdrawals: Exiting Staking**
A full withdrawal occurs when you stop staking entirely and exit your validator. This process involves two key steps:
1. Update Withdrawal Credentials:
Ensure your withdrawal credentials are set to an execution address (Type 1, 0x01).
2. Voluntary Exit:
Signal your intent to exit staking by signing and broadcasting a voluntary exit message using your validator keys. This unlocks your remaining balance, which will then be fully withdrawn to your designated withdrawal address.
Command to Exit:
./bahamut validator exit --public-keys=... --network=sahara
Important Notes:
Once a validator has fully exited and withdrawn its balance, any additional deposits made to the validator will automatically be sent to the withdrawal address during the next balance sweep.
If you didn’t set a withdrawal address when creating your deposit data, you can still set it later. However, this requires an additional step:
1. Create new deposit data that includes the withdrawal address.
2. Make a new deposit of at least 256 FTN to the deposit contract.
After this process, the withdrawal address will be updated, and the 256 FTN will be returned to your withdrawal address, minus a small amount to cover gas fees.
To re-stake, a new validator must be created and activated.
# Difference on Bahamut Staking vs. Lolik
#### Bahamut Staking vs. Pooled Staking
Staking on Bahamut gives you two options: home staking or pooled staking. Both help secure the network, but they work differently and suit different needs.
#### Home Staking on Bahamut
Home staking is the most independent and rewarding way to stake. You run your own validator, keep full control of your FTN, and earn the highest rewards. This option is ideal if you:
* Have 8,192 FTN per validator.
* Are comfortable setting up and managing hardware.
* Want to contribute to the network’s security and decentralization directly
It takes effort. You need to maintain your validator 24/7 and handle any technical issues. But if you’re up for the challenge, it’s the most rewarding choice.
#### Pooled Staking
Pooled staking makes staking more accessible by allowing you to stake any amount of FTN, even if you don’t have enough for a full validator. It’s called "pooled staking" because your stake is combined with others to activate validators. Services like Lolik currently provide pooled staking, but in the future, other services may also offer this option.
With pooled staking, you get liquid staking tokens (stFTN) that represent your stake and can be used in DeFi. This option is great if you:
* Don’t have enough FTN for a validator.
* Don’t want to manage hardware or software.
* Prefer a simpler way to earn rewards.
Keep in mind, with Lolik, you’re trusting a third party to manage your stake, which means less control than home staking.
#### Which Should You Choose?
If you want full control, higher rewards, and don’t mind the effort, home staking is for you.
If you want a simple, flexible option and have less FTN, go with pooled staking on [Lolik.com](http://lolik.com).
Both options are great for helping secure Bahamut and earning rewards. Choose the one that fits your style!
# Wallet
To be updated ..
# Supported Wallet
# Tutorial on how to set up wallet
# Network Configuration
To be updated ..
# Configure Value
# Tutorial on how to config Bahamut network in Metamask
# Bridge Assets
To be updated ..
# Bridge assets from others chains
# Bahamut Bridge
# Bridge assets form Exchange
# General FAQs
To be updated ..
# $FTN and Staking FAQs
To be updated ..
# Validator FAQs
To be updated ..
# Contact Officials
# Disclaimers
Please note that **all projects and dApp applications running on the Bahamut Blockchain are independently developed by third-party developers.**
**Bahamut Blockchain is an entirely open-source and open community**, which means everyone and all project parties can participate. All opportunities and risks also exist at the same time. You need to identify and prevent risks carefully. This is also the charm of the DeFi world.
# Risk Statement
Bahamut Blockchain operates as a decentralized public chain, allowing global developers to deploy applications. Users can read, send, and trade on Bahamut. Due to its decentralized nature, we emphasize the risks associated with third-party dApps:
* Prior to engaging with any platform, wallet, or third-party dApp, it is crucial to conduct thorough research independently.
* Your participation or use of dApps on Bahamut through trading platforms or wallets is at your discretion; we do not endorse or recommend specific actions.
* We do not undertake the auditing of any third-party dApp and make no commitments or guarantees regarding the validity, accuracy, reliability, quality, stability, integrity, or timeliness of their technology and information.
* You are solely responsible for the consequences of using any third-party dApp services.
* Ensure that third-party dApp services comply with the laws, regulations, and policies of your jurisdiction; we do not provide evaluations and advise strict adherence to local laws.
* Any issues arising from the usage of third-party dApps, such as legal matters, contractual liabilities, and economic losses, are the responsibility of both you and the third-party dApp; Bahamut is not liable for such issues.
* We do not endorse or encourage the use of any third-party dApp services.