DEV Community: Bravolakmedia

Why GoatFunded Futures is the GOAT of prop firms

Bravolakmedia — Mon, 20 Oct 2025 20:11:39 +0000

GoatFunded is simply the best when it comes to futures trading among all the prop firms. You don't create your account and start fretting about raising fund to start trading, their instant funded accounts is there for a new user, one of their super amazing features. You can skip evaluation with instant funding or prove consistency with EOD plans accessing up to $750000 fund to start your future tradings.
At GoatFunded, you can access premium platform access at no extra cost. All the tools that make your future trading easier is given to you hassle free. Our TradingView integration is top-notch giving you the opportunity to monitor your token pairs as prices rise or fall, you can easily set your stop loss and take profit at your convenient time.
There is a reward system that makes every trade and action a plus to your achievement based on points. There are also quick tasks that you can perform to earn more points ranging from following our social media handles to posting challenge or payout certificates on social media by tagging us. Your points are not just digits, they are redeemable to real asset.
GoatFunded also have affiliate program where a trader can also earn side income by referral. A simple sharing this trading platform with its numerous opportunities with friends and loved ones can still boost a user's earning.
These are just few of the benefits awaiting you when you decide to do your future tradings on GoatFunded. Why not click GoatFunded now and start your journey to make more profit by trading different crypto token pairs of your choice.

How to Become a Solana Developer: A Comprehensive Guide

Bravolakmedia — Mon, 18 Nov 2024 10:41:26 +0000

The Solana blockchain has gained prominence for its high-speed, low-cost transactions, making it a popular choice for building decentralized applications (dApps). As a developer, entering the Solana ecosystem can open up opportunities to work on cutting-edge Web3 projects. Here’s a step-by-step guide to becoming a Solana developer, including essential skills, tools, and resources.

1. **Understanding Blockchain Basics**
Before diving into Solana development, it’s crucial to understand blockchain fundamentals.
What is Blockchain? Blockchain is a decentralized and distributed ledger technology that records transactions across multiple computers in a secure, immutable, and transparent manner.
Features of Blockchain
Decentralization: Unlike traditional systems controlled by a central authority, blockchain operates on a peer-to-peer network where every participant (node) has a copy of the ledger.
Immutability: Once data is added to the blockchain, it cannot be altered or deleted. This ensures a tamper-proof record of transactions.
Transparency: All transactions are visible to participants in the network, ensuring trust and accountability.
Smart Contracts: Blockchain platforms often support programmable agreements (smart contracts) that execute automatically when predefined conditions are met.

Applications of Blockchain:
Finance: Enabling secure peer-to-peer payments (e.g., Bitcoin, Ethereum, Solana and others).
Supply Chain: Tracking goods from origin to destination.
Healthcare: Storing medical records securely.
Web3: Building decentralized applications (dApps) that don’t rely on a centralized server.

Why Solana? Solana stands out as one of the fastest and most scalable blockchain platforms. Here’s why it’s a preferred choice for developers:

Speed and Scalability Solana can process over 65,000 transactions per second (TPS), far exceeding traditional blockchains like Ethereum (~15 TPS). It achieves this through a unique consensus mechanism called Proof of History (PoH), which timestamps transactions before they are added to the blockchain.
Low Transaction Costs Solana’s transaction fees are incredibly low, averaging around $0.00025 per transaction, making it cost-effective for users and developers.
Developer-Friendly Ecosystem Tools like Solana CLI, Solana Web3.js, and Anchor Framework simplify development and deployment. The Solana ecosystem supports programming in Rust, a high-performance and memory-safe language.
Versatility Solana is suitable for a variety of applications, including: DeFi (Decentralized Finance): Platforms like Serum for trading. NFTs (Non-Fungible Tokens): Marketplaces like Magic Eden. Gaming and Web3 Applications: High-performance apps with real-time interactions.
Growing Community and Ecosystem Solana has a vibrant developer community, regular hackathons, and a rich ecosystem of tools and resources. It has attracted partnerships with major companies and initiatives, fostering innovation and adoption.
Energy Efficiency Compared to Proof of Work (PoW) blockchains like Bitcoin, Solana’s Proof of Stake (PoS) and Proof of History (PoH) mechanisms consume significantly less energy, making it an environmentally friendly option.

2. Learning Programming Languages
Solana development primarily uses Rust, but you can also use C, C++, or Anchor (a Rust-based framework) for smart contracts. Here’s how to get started:
Rust Programming
Rust is a systems programming language known for performance and memory safety.
Learn Rust via:
The Rust Book: The official guide to mastering Rust.
Interactive tutorials and exercises on YouTube.
JavaScript/TypeScript
The Solana ecosystem leverages JavaScript or TypeScript for interacting with dApps on the frontend.
Key skills:
Fetching blockchain data using Solana's libraries.
Using the Solana Web3.js library to connect to the network and interact with smart contracts.

3. Exploring the Solana Ecosystem
Key Concepts:
Programs: Solana’s version of smart contracts that is deployed to the blockchain.
Accounts: In Solana, an account is a fundamental data structure used to store information on the blockchain. Unlike other blockchains where accounts are primarily used to hold balances (e.g., Ethereum's wallets), accounts in Solana are more versatile and are used to store state, programs, and data associated with decentralized applications (dApps).
Transactions: Instructions for executing programs on-chain.
Development Tools:
Solana CLI: Command-line tool for deploying programs, creating wallets, and interacting with the network.
Anchor Framework: A developer-friendly framework for building and deploying Solana programs. It simplifies program structure and testing.
Solana Explorer: A blockchain explorer for monitoring transactions and accounts.
Phantom Wallet: A popular Solana wallet for interacting with dApps.

4. Setting Up Your Development Environment
Install Solana CLI:
Follow the instructions in the solanalabs.
Install Rust:
Use rustup to install Rust: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh.
Install Anchor:
Use cargo install --git https://github.com/coral-xyz/anchor anchor-cli to set up Anchor.
Set Up a Local Solana Cluster:
Use the Solana CLI to start a local development network: solana-test-validator.

5. Building Your First Solana dApp
Step 1: Create a Wallet
Generate a wallet using the Solana CLI:
solana-keygen new --outfile ~/my-solana-wallet.json

Step 2: Fund the Wallet
Request airdropped tokens on the devnet:
solana airdrop 2
The code above is for airdropping two Solana tokens on devnet.

Step 3: Write a Smart Contract
Create a basic "Hello World" program using Anchor.
Step 4: Deploy the Program
Build and deploy your program to the devnet:
anchor deploy
Step 5: Interact with the Program
Use the Solana Web3.js library in your frontend to interact with your program.
6. Join the Solana Community
Networking and collaboration are key to staying updated and improving your skills:
Discord & Forums: Join the Solana Discord and forums to connect with developers.
Hackathons: Participate in Solana-hosted hackathons to learn and showcase your skills.
Open-Source Projects: Contribute to projects on GitHub to gain hands-on experience.

The Complete Guide To Full Stack Development On BSV Blockchain with React, sCrypt, Typescript and Panda.

Bravolakmedia — Fri, 21 Jun 2024 14:56:38 +0000

PROJECT OVERVIEW.

This project utilize the following tools
Node JS: Node.js is an open-source and cross-platform JavaScript runtime environment. It is a popular tool for almost any kind of project!
Node.js runs the V8 JavaScript engine, the core of Google Chrome, outside of the browser. This allows Node.js to be very performant.
A Node.js app runs in a single process, without creating a new thread for every request. Node.js provides a set of asynchronous I/O primitives in its standard library that prevent JavaScript code from blocking and generally, libraries in Node.js are written using non-blocking paradigms, making blocking behavior the exception rather than the norm.

React: The client FrontEnd Framework

The sCrypt-CLI Tool: The sCrypt CLI tool is used to easily create, compile and publish sCrypt projects. The CLI provides best practice project scaffolding including dependencies such as sCrypt, a test framework (Mocha), code auto-formatting (Prettier), linting (ES Lint), & more.

TypeScript: We chose TypeScript as the host language because it provides an easy, familiar language (JavaScript), but with type safety, making it easy to get started writing safe smart contracts. There is no need to learn a new programming language or tools if you are already familiar with TypeScript/JavaScript. If you're new to TypeScript, check out this helpful introductory video.

Yours Wallet: Yours Wallet formerly called Panda Wallet is an open-source digital wallet for BSV and 1Sat Ordinals that enables access to decentralized applications developed on Bitcoin SV.

This guide specifically looks into how to create a Full Stack Hello World React dApp and integrate it with a smart contract Hello World as an example. It goes further to describe how to wrap your dApp with Yours Wallet integration in case you want to create a dApp with live Wallet integration. It covers basic installations, setting up of development environment, writing smart contracts with sCrypt, integration with Yours wallet, building FrontEnd with React and TypeScript, integrating smart contract with the FrontEnd and testing the dApp.

The project shows the basics of building a react dApp that integrates with contract writing with sCrypt on BSV blockchain.

BASIC INSTALLATIONS.

Install Node.js (require version >=16) and NPM on your machine by following the instructions over here.
Install Git.
NOTE
On Mac computers with Apple silicon like M1/M2, make sure Rosetta is installed. If not, it can be installed with the following command.
softwareupdate --install-rosetta --agree-to-license

Install sCrypt-cli globally to your machine by running the code below: npm install -g scrypt-cli
You can start playing with react since Node JS has been installed. The npm has been installed together which is a package manager for react. To learn more about react installation, check here.
TypeScript comes preconfigured with Create React App, so you don't need to install it separately. In case you need to, TypeScript can be installed through three installation routes depending on how you intend to use it: an npm module, a NuGet package or a Visual Studio Extension. Since we are using Node.js, we will use npm version. If you are using MSBuild in your project, you want the NuGet package or Visual Studio extension. Run the code below: npm install -g typescript To learn more about typescript installation, check here.
Create your Yours Wallet formerly called Panda wallet. You can get its chrome extension here.

SETTING UP DEVELOPMENT ENVIRONMENT

Make sure you have Node.js and npm installed on your system. You can run the code below to check:

node --version
V20.11.0
npm --version
10.4.0

You will get output similar to the above if your Node.js and npm has been installed. Note that you need Node.Js version 16 and above. Check the installation guide links in case your Node.js is not properly installed.

CREATE YOUR BACKEND.

It is a good practice to always create a backend for a dApp project. The proper build and deployment of a backend gives better functionalities and directions on what the features of the backend that the frontend can better interact with. It can also give a clue on how to design the frontend.

Create a new smart contract project “hello world” by running the following command in your visual studio code editor or on linux:

npx scrypt-cli project helloworld.

This will create the smart contract project “hello world” in HELLOWORLD directory on the local machine.
cd helloworld

This allowed us to migrate into the project directory hello world where we have the smart contract file.
npm install
This command installs the necessary dependencies we need for the smart contract in the project directory.
The resulting project will contain a sample smart contract src/contracts/helloworld.ts, along with all the scaffolding. Let's modify it to the following code:

import {
   assert,
   ByteString,
   method,
   prop,
   sha256,
   Sha256,
   SmartContract,
} from 'scrypt-ts'


export class Helloworld extends SmartContract {
   @prop()
   hash: Sha256


   constructor(hash: Sha256) {
       super(...arguments)
       this.hash = hash
   }


   @method()
   public unlock(message: ByteString) {
       assert(sha256(message) == this.hash, 'Hash does not match')
   }
}

The Helloworld contract stores the sha256 hash of a message in the contract property hash. Only a message which hashes to the value set in this.hash will unlock the contract.
A smart contract extends SmartContract base class, it has @prop decorator which marks the helloworld contract property and @method decorator which marks the contract’s method that can be public or non-public.

Compile the smart contract by running the command below:

npx scrypt-cli compile
This command will generate a contract artifact file at artifacts\helloworld.json.
In order to monitor for real time error detection you can run the following code:
npx scrypt-cli compile --watch

3:35:32 PM - Starting compilation in watch mode...


3:36:01 PM - Found 0 errors. Watching for file changes.

The message above is a similar message you will get in your terminal, meaning that auto compilation is working.

Deploy your contract: Before deploying your contract, you need to generate a Bitcoin key by running the command below:

npm run genprivkey
then follow the instructions to fund the key.
**Next, start deploying and calling the contract:

To deploy a smart contract, simply call its deploy method.
To call a smart contract, call one of its public method.** We need to overwrite “deploy.ts” in the root of the project with the following code to deploy and call the Helloworld contract as shown below:

import { Helloworld } from './src/contracts/helloworld'
import { getDefaultSigner } from './tests/utils/txHelper'
import { toByteString, sha256 } from 'scrypt-ts'


;(async () => {
   // set network env
   process.env.NETWORK = 'testnet'


   const message = toByteString('hello world', true)


   await Helloworld.loadArtifact()
   const instance = new Helloworld(sha256(message))


   // connect to a signer
   await instance.connect(getDefaultSigner())


   // deploy the contract and lock up 42 satoshis in it
   const deployTx = await instance.deploy(42)
   console.log('Helloworld contract deployed: ', deployTx.id)


   // contract call
   const { tx: callTx } = await instance.methods.unlock(message)
   console.log('Helloworld contract `unlock` called: ', callTx.id)
})()

Run the following command to deploy the smart contract:
npx ts-node deploy.ts
You will see an output like this

You can check this deployed contract on chain at https://test.whatsonchain.com/tx/e39961a0f783cf4da7e24c7b9e0f3490e2444ef87d7c3b96fde6e732392f6184

CREATE YOUR FRONTEND.

Create a react app named hello. Note that we are creating our frontend as "hello" not "helloworld" to prevent conflict in files like package.json, node_modules and src files. Run the following code:

npx create-react-app hello --template typescript
We will do most work under the src directory.
Run the init command of the CLI to add sCrypt support in your project.
cd hello
npx scrypt-cli init
This will install all the dependencies and configures the contract development environment in our react dApp. But you need to run
git add .
git commit -m “Your commit message”
git push
To commit your changes to master or main if you are working in git remote repository before you can run “npx scrypt-cli init”
A successful initialization will give you “src/contracts/hello.ts” file in your react app as shown below:

Load and Compile the smart contract in the dApp. Copy and paste “helloworld.ts” from the backend helloworld into the “src/contracts/hello.ts” in the front end “hello” directory. We will now compile the contract by running the following command: npx scrypt-cli compile A successful compilation will generate “artifacts/hello.json” file as shown below:

We will now load the artifact file directly in the index.tsx file as shown below

import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import App from "./App";
import reportWebVitals from "./reportWebVitals";
import { Helloworld } from './contracts/helloworld'; //loading artifact //file
import artifact from '../artifacts/helloworld.json';
Helloworld.loadArtifact(artifact);
const message = toByteString('hello world', true)  // creating instance //from contract class.
const instance = new Helloworld(sha256(message))


const root = ReactDOM.createRoot(
 document.getElementById("root") as HTMLElement
);
root.render(
 <React.StrictMode>
   <App />
 </React.StrictMode>
);


// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

Just like that we are done integrating our smart contract with the front end. We can now go further to customize the React dApp e.g by styling.

INTEGRATE YOURS WALLET

Follow this link to integrate Yours Wallet formerly known as Panda Wallet.
Request access to the wallet, by using the requestAuth method below:

const signer = new PandaSigner(provider);

// request authentication
const { isAuthenticated, error } = await signer.requestAuth();
if (!isAuthenticated) {
 // something went wrong, throw an Error with `error` message
 throw new Error(error);
}


// authenticated
// you can show user's default address
const userAddress = await signer.getDefaultAddress();
// ...

Now you can connect the wallet to the contract instance as before using the code below:

await instance.connect(signer);

The sample code use in this write up can be found in the repository and the whole write up is a basic guide for creating a complete dApp on BSV blockchain using sCrypt-cli.

REFERENCES.

Official sCrypt Documentation https://docs.scrypt.io.
Introduction To Node.JS https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
sCrypt CLI Tools For Creating and Managing Scrypt Projects https://github.com/sCrypt-Inc/scrypt-cli
TypeScript https://www.typescriptlang.org/
Getting Started Installing Git, https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

SOLANA VALIDATORS AND FEE ECONOMICS.

Bravolakmedia — Thu, 20 Jun 2024 15:22:59 +0000

The Meaning of Validators and Fee Economics in Cryptocurrency Systems.

The two terms validators and fee economics are used in the concept of Proof-of-Stake (PoS) in cryptocurrency systems or blockchain networks. Solana validators are associated with the Proof-of-Stake (PoS) and Proof-of-History (PoH) as a consensus mechanism in the Solana ecosystem. Solana validators are nodes or computers that validate transactions and create new blocks on the Solana blockchain. The Solana fee economics is the way transaction fees are achieved and distributed in the Solana blockchain.
The Roles and Significance of Validators in The Solana Ecosystem.
Solana validators are responsible for running the Solana protocols and creating new blocks on the blockchain after validating credible transactions. The Solana validators give the blockchain a decentralization feature and they are vital to the Solana’s blockchain scalability. Solana validators also secure the ecosystem by executing programs that keep track of all the accounts on Solana clusters as independent entities making it difficult for attackers to alter the clusters.
Solana validator's requirements are not too much, there is no mandatory amount of SOL to be staked to become a validator. A validator can only take part in consensus by having a voting account with 0.02685864 SOL as a rent-exempt reserve and sending a vote transaction of about 1.1 SOL in value for each block he agrees with. The minimum hardware requirements to become a Solana validator are given below.
Basic Hardware and Software Requirements for A Solana Validator.

CPU

12 cores / 24 threads, or more
2.8GHz base clock speed or faster.
SHA extension instruction support
AMD Gen 3 or newer.
Intel Ice Lake or newer.
AVX2 instruction support (to use official release binaries, self-compile otherwise)
Support for AVX512f is helpful.

RAM

256GB or more
Error Correction Code (ECC) memory is suggested.
A motherboard with 512 GB capacity is suggested.

DISK

PCIe Gen3 x4 NVME SSD, or better.
Accounts: 500GB, or larger. High TBW (Total Bytes Written)
Ledger: 1TB or larger. High TBW suggested
OS: (Optional) 500GB, or larger. SATA OK
The OS may be installed on the ledger disk, though testing has shown better performance with the ledger on its disk.
Accounts and ledger can be stored on the same disk, however, due to high IOPS, this is not recommended.
The Samsung 970 and 980 Pro series SSDs are popular with the validator community.

GPUs

Not necessary at this time.
Solana operators in the validator community do not use GPUs currently.

The software requirement for Solana validators is Ubuntu 20.04 (recommended). For more information on the Solana validator's requirements check docs.solanalabs and watch the YouTube video Spotlight: Solana validators and hardware requirements. Validators earn rewards for their services as a transaction fee or with newly minted tokens.

Challenges Faced by Validators on Solana and Potential Solutions.

Solana validators are facing challenges ranging from high hardware and bandwidth requirements to network congestion and latency, centralization, censorship and slashing risks as well as volatility and uncertainty of rewards. According to Rob Behnke, steep hardware requirements are hindering running a Solana validation node. This is why Solana has only 2,364 validators compared to 440,263 validators on Ethereum as of February 2023. The solution to this is getting more validators without compromising the security, fast speed and low transaction cost that the network is known for.
Network outages have become a norm in the Solana ecosystem. The blockchain experienced 14 network outages in 2022, there was one outage in 2023 on February 25 and one outage was recorded in February 2024. According to Rob Behnke, Solana outages are caused by the inability of Solana validators to handle high transaction loads during peak periods looking at it on a high level. There are not enough validators to spread the workload which eventually leads to network collapse. The tendency for bots to spam the Solana blockchain is high due to its all-time very cheap transaction cost. On the side of the network engineers, bugs have been identified as the root cause of Solana outages. For instance, the cause of the February 5, 2023 outage was traced back to several services on the network running custom block-forwarding software that inadvertently transmitted a huge amount of data, equivalent to several orders of magnitude larger than a normal block. The network’s de-duplication logic was unable to cope with this, overwhelming the Turbine protocol and significantly degrading the network. Solana blockchain core engineers have been implementing and rolling out different network upgrades to solve the outage problem. They have implemented QUIC, fee markets and stake-weighted Quality of Service (QoS) to address the problem. The engineers claimed that QUIC will replace all the UDP-based networking protocols and will be better at enforcing the constraints in the Turbine for a more stable network.
The centralization challenge for the Solana validators arises from the need to increase the hardware requirement for increasing the validator's capability to handle more transactions efficiently. The more stringent the hardware requirements, the higher the cost of running a Solana validator node and the less the number of validators. This will cause centralization rather than decentralization of the Solana blockchain. The best solution is to increase the fees for the congested dApps and retain low fees for normal transactions. This approach retains the decentralization feature of the Solana blockchain, its low cost and prevents bot attacks that cause network outages.

The Structure and Distribution of Fees within the Solana Network and Their Role in Validator Economics.

Solana has two fee structures the transaction fees and the state fees. The state fee is subdivided into a base fee and a priority fee. The base fee is fixed at 0.000005 SOL at 5000 lamports per signature. A priority fee is usually indicated in the transaction and denominated in microlamports per CU. Transaction fees are paid at the onset of transaction execution and failure to do so renders a transaction invalid and not executed. Half of the transaction fees are kept as an incentive to the leader-validator for including the transaction in the blocks and the remaining half is burned. This design is aimed at retaining leader incentives to include several transactions within its slot time. It provides an inflation-limiting mechanism that prevents tax evasion attacks. The design also reduces the incentive to the censors giving room to detect a malicious censor leader. For instance, in the case of a PoH fork with a malicious censor leader, the total fees destroyed will be less compared to that of an honest fork.
Solana charges a state fee called a rent exemption fee to create a new state. The rent exemption fee is 6.96 SOL per MB and it is assigned to a newly created validator account. Solana transaction fees are set by the network cluster based on the historical throughput and it can be adjusted based on the historical gas usage.
The roles of the transaction fees are many in the validator economics. They provide unit compensation to the validator network for resources used to process the state transaction. They introduce real cost to transactions and therefore reduce network spamming. They open avenues for a transaction market to incentivize validators to accept and process transactions. They introduced a protocol-captured minimum fee per transaction which provides a potential long-term economic stability of the Solana network.
Comparative Analysis of Fee Economics Between Solana and Other Major Blockchains.
The three major blockchains that can be compared on a fee economics level are Solana, Polygon and Ethereum. The other blockchains are behind these three. Using the metrics of transaction fees and gas price, Ethereum has a notorious high gas price according to the Blockchain Council. According to the council, Ethereum gas prices and fees usually reach hundreds of dollars per transaction during peak periods and it frustrates smaller transactions. Polygon unlike Ethereum has lower gas prices and transaction fees which is linked to its Proof of Stake consensus algorithms that reduce energy consumption and cost on the network.
In comparison to both Ethereum and Polygon, Solana blockchain stands out with its unique consensus mechanism which combines both Proof of Stake and Proof of History. According to the Blockchain Council, Solana has extremely low transaction fees, charging a few cents per transaction. The network has high throughput, an efficient consensus algorithm, and quick and inexpensive transaction fees. The gas price on the three networks is shown in the table below. Polygon gas price is paid in MATIC while Solana gas price is 0.0001 SOL all converted to their present dollar equivalent at the time of writing.

Gas Price on Ethereum, Polygon and Solana Blockchains.
Blockchain Network : Gas Price ($)
Ethereum: Several Hundred during peak periods
Polygon: 0.097
Solana: 0.01

The Impact of Fee Economics on Network Performance, User Experience and Validator Incentives.

Transaction fee is mandatory to get a transaction executed but other factors determine whether a transaction will be executed and added to a block. A validator may lag in block processing, there may be a discrepancy within an RPC pool and the loss of a UDP network packet may lead to transaction drop-off. The loss of a UDP network packet may occur during the peak periods when validators have more transactions than they can handle until the blockhash expires. When a transaction’s recent blockhash is retrieved from an updated segment and later submitted to a slower segment it may lead to discrepancy within an RPC pool. A transaction’s block may end in the minority fork as a result of its validator block processing lagging. Such a block ends up being dropped off.

Consensus on Solana blockchain. (Source: Helius.dev)
In another view, there is evidence that priority fees influence block inclusion on a macro scale but not perfect. Helius RPC data shows that transactions with priority fees have more chances of block inclusion and the higher the priority fees the greater the chance of block inclusion. This is shown in the graphs below, True is the transactions with the priority fee while the y-axis shows the percentage of transactions.

True = transactions with priority fees, y-axis = Percentage of transactions.
Effect of priority fee on block inclusion. (Source: Helius.dev)

Effect of priority fee on block inclusion. (Source: [Helius.dev](https://www.helius.dev/blog/solana-fees-in-theory-and-practice))
The second graph also shows that transactions with priority fees also land quickly.

Solana Priority Fee: (Source: Helius.dev)

According to Ryan Chern, Solana priority fees experienced an increase in average on January 21, 2024, caused by the mockJUP airdrop has the real JUP airdrop was around the corner. It increases the demand for blockspace and affects users' transaction time and transactions’ land rate. As shown above, the Solana RPC method (getRecentPrioritizationFees) assists developers in determining the priority fees to assign for a transaction. Helius also offers a Priority Fees API that allows additional calculations to determine the best priority fees for a transaction.
It can be stated that Solana validators' incentives come from transaction fees as discussed above and from a protocol-based reward. A protocol-based reward is realized from inflationary issuances from a protocol-defined inflation schedule. Solana inflation design was defined at 8% SOL emissions and reduced by 15% every year. It was activated on February 10th, 2021 with a payment of 213841 SOL according to the Chorus One blog quoting the Solana validator dashboard.

Solana validators started to receive rewards from inflation on February 10, 2021.
Solana inflation models consider 400ms block time, the present average is about 650ms. A longer block time will result in smaller rewards to validators when the number of epochs (specified consensus operation time) per year is small as shown in the chart below.

Solana block times over the 35 days ending August 9, 2022.

The Potential for Negative Commission Rates in Scenarios where Network and Maximum Extractable Value (MEV) Fees Become Sufficiently High.

Maximum Extractable Value (MEV) is the profit that miners or validators can extract through the ordering and execution of transactions strategically within a block. Miners or validators therefore determine the order of transaction especially in front-running or arbitrage where such transaction may offer profit. During periods of network congestion users may compete by paying high prices to have their transactions quickly processed. A validator can try to extract more value through MEV opportunities. Negative commission rates come in when validators are willing to pay users by lowering the commission rates even to a negative value to attract users to delegate with them. Negative commission rate is more supported MEV is prevalent and profitable or when the validator is after maximizing profit.
On the Solana network validators complete the transaction not miners. These validators are grouped in clusters to vote on the validity of a transaction while each validator acts as a leader to avoid corrupt practices in the validation process. This makes only some MEV possible on Solana. According to the Chorus One blog, from July 16 to July 26, 2022, Orca and Raydium recorded 68 MEV with a lower bound of $20,775.
Analysis of The Long-Term Economic Viability of Validators as Solana’s Inflation Approaches Its Terminal Value.

Example of proposed inflation schedule graph on Solana. (Source: Solana doc)
Solana's inflation schedule is based on the initial inflation rate of 8%, disinflation rate of -15% and long-time inflation rate of 1.5% according to the Solana documentation. Solana has a decreasing inflation rate that will approach its terminal value over time, the time when the Solana network’s token supply will be stabilized. The rate at which new tokens are minted will reduce with a reduction in the validator’s incentive. The reason is that the validator’s reward comes from transaction fees and staking rewards while staking rewards include the new token mints and transaction fees distributed among validators based on their participation in consensus and the amount staked.
The economic viability of a Solana validator depends on its ability to generate income that is above its operational cost. As inflation approaches its terminal value on Solana, the reward for a validator depends more on the transaction fees as the block rewards decrease. This is where Solana's low cost will assist the validators to be economically viable. For individual validators, validators must offer competitive staking rewards and additional services to attract and retain more users staking with them.

Potential Models or Innovations That Could Support Validator Sustainability under Low Inflation Conditions.

The sustainability of validators under low inflation periods requires alternative revenue apart from rewards from blocks. One of the major potential models for the sustainability of the validator under low inflation conditions on Solana is the implementation of a fee-burn mechanism. The mechanism aims at creating deflationary pressure on native tokens on Solana. It should be recalled that half of the transaction fee is burnt hence permanently removed from the ecosystem. This has an impact on increasing the value of the native tokens from which validators will earn more incentives in the long run.
Validators need to add additional services to attract more users to stake with them. For instance, a validator may add analytic tools or API access to their service. More users will stake their tokens with them to access these value-added services. Validators can also collaborate with projects in the ecosystem by offering integrations or services that will enhance the overall Solana network utility.
There is room for validators to participate in DeFi protocol integrations. Here they can offer services like liquidity providing, asset staking or governance roles. This gives them opportunities to increase their profitability. They can also issue collateralized stable coins and leverage their staked assets.
Validators can also participate in community incentive programs to increase overall network usage and service awareness. They can participate in grants, token distributions, sponsorships and other reward programs that drive active network usage and engagements. A very good example of this is this write-up sponsored by Cogent Crypto. Cogent Crypto is a distinguished validator on the Solana network. They have an annual percentage yield (APY) of 7.74%, a cluster average APY of 7.43% and 1,538,862 delegated SOL. You can contact Cogent Crypto to learn more about them.

The Role of Transaction Fees, Staking and Other Economic Mechanisms in Ensuring Ongoing Validator Incentives.

Transactions on Solana are finalized by validators who put them into blocks by consensus mechanism hence the ongoing incentives for Solana validators help in maintaining the network’s security, stability and decentralization. To maintain the ongoing Solana validators incentives transaction fees, staking and other mechanisms such as block rewards key instruments. It has been established in the sections above that transaction fees are one of the primary sources of revenue for the Solana validators and one of the major sources of revenue as the Solana inflation rate approaches its terminal value.
Solana validators need a reserve of 0.02685864 SOL and to stake SOL tokens to participate in the consensus mechanism. The staking is a collateral that serves as a security deposit to enhance the interest of the validator in the overall Solana network security. The staking also allows the validators to earn staking rewards in the form of newly minted tokens and transaction fees.

Block rewards are another mechanism that ensures Solana validator's incentives. These block rewards consist of newly minted tokens and transaction fees earned by validators for validating and adding new blocks to the blockchain. It can be categorically stated that transaction fees, staking and other mechanisms that ensure the ongoing Solana validators incentives strengthen the relationship between the users, the validators and the network itself. They aid in security enhancement, decentralization and the stability of the Solana ecosystem.

References.

Solana Validator Economics-A Primer, https://www.helius.dev/blog/solana-validator-economics-a-primer
How to become a Solana Validator, https://medium.com/@Cogent_Crypto/how-to-become-a-validator-on-solana-9dc4288107b7
Official Solana Documentation, https://docs.solanalabs.com
Spotlight: Solana Validator and Hardware Requirements by @nickyfrosty, https://youtu.be/PoVAJvGIdsw?si=if35lg3oyrMTqErv
Solana Fees In Theory and Practice, https://www.helius.dev/blog/solana-fees-in-theory-and-practice
What Problems Are We Facing In Solana? A Deep Dive with SolanaFm, https://solanafm.medium.com
Solana Security Overview by Rob Behnke, https://www.halborn.com
Network Performance, https://solana.com/news/network-performance-report-july-2023
Solana Fees, Part 1 https://www.gate.io
Solana Vs Polygon Vs Ethereum- The Ultimate Comparison, https://www.blockchain-council.org
Solana Fees In Theory and Practice by Ryan Chern, https://www.helius.dev
Exploring Validator Economics on Solana, https://chorus.one
What is MEV and how does Solana solve its MEV issues, https://chainstack.com
Proposed Inflation Schedule, https://solana.com

How To Write Smart Contract With Scrypt.

Bravolakmedia — Wed, 29 May 2024 14:18:45 +0000

WHAT IS A SMART CONTRACT

A smart contract is a self-executing contract that automatically enforces the rules and terms of an agreement between parties. It is a computer program that runs on a blockchain network and can facilitate, verify, or enforce the negotiation or performance of a contract. A smart contract is like a written agreement, but instead of being on paper and handled by a person, it's a piece of computer code on a blockchain.

How Smart Contract Works.

Digital Agreement: A smart contract is a digital agreement written in code. It has all the terms and conditions of the agreement clearly stated.
Automatic Execution: Once the smart contract is on the blockchain, it automatically enforces the terms. No one can change it or cheat.
No Middleman Needed: Unlike the written agreement where you need a trusted third party to ensure fairness, the smart contract itself ensures fairness by automatically carrying out the agreement based on the pre-set rules.
Security and Trust: The blockchain technology behind the smart contract ensures security. It’s decentralized, meaning it’s not controlled by any single person or organization, making it almost impossible to tamper with. So, in essence, a smart contract is a self-executing contract where the terms are directly written into lines of code. The code and the agreements it contains exist across a distributed, decentralized blockchain network. This ensures that the contract is transparent, secure, and executed exactly as agreed without the need for intermediaries.

How do Bitcoin Smart Contracts work?

Smart contracts on Bitcoin are based on the UTXO model, which is very different from an account model like Ethereum used.

A Bitcoin transaction

Each bitcoin transaction consists of some inputs and outputs. A single bitcoin is divisible into 100,000,000 satoshis, similar to how a dollar is divisible into 100 cents or pennies.

An output contains:
a. The amount of bitcoins (satoshis) it contains.
b. bytecodes (the locking script).
While an input contains:
a. A reference to the previous transaction output.
b. bytecodes (the unlocking script).

UTXO model

An Unspent Transaction Output (UTXO) is an output not consumed in any transaction yet. The low-level bytecode/opcode is called Bitcoin Script, which is interpreted by the Bitcoin Virtual Machine (BVM).

In the example above, we have two transactions, each having one input (in green) and one output (in red). And the transaction on the right spends the one on the left. The locking script can be regarded as a boolean function f that specifies conditions to spend the bitcoins in the UTXO, acting as a lock (thus the name "locking"). The unlocking script in turns provides the function arguments that makes f evaluates to true, i.e., the "key" (also called witness) needed to unlock. Only when the “key” in an input matches previous output’s “lock”, it can spend bitcoins contained in the output.

In a regular Bitcoin payment to a Bitcoin address, the locking script is Pay To Pubkey Hash (P2PKH). It checks the spender has the right private key corresponding to the address so she can produce a valid signature in the unlocking script. The expressive Script enables the locking script to specify arbitrarily more complex spending conditions than simple P2PKH, i.e., Bitcoin smart contracts.

Components of A Smart Contract Written On Scrypt.

In case you are new to Scrypt you can follow the previous article on scrypt syntax and data types here.
A smart contract is a class that extends the SmartContract base class. It has the following components:

1. Properties

A smart contract can have two kinds of properties:

a. With @prop decorator: these properties are only allowed to have types specified below and they shall only be initialized in the constructor.
b. Without @prop decorator: these properties are regular TypeScript properties without any special requirement, meaning they can use any types. Accessing these properties is prohibited in methods decorated with the @method decorator.

2. @prop decorator

This decorator is used to mark any property that intends to be stored on chain. It takes a boolean parameter. By default, it is set to false, meaning the property cannot be changed after the contract is deployed.
If the value is true, the property is a so-called stateful property and its value can be updated in subsequent contract calls.

// good, `a` is stored on chain, and it's **readonly** after the contract is deployed
@prop()
readonly a: bigint

// valid, but not good enough, `a` cannot be changed after the contract is deployed
@prop()
a: bigint

// good, `b` is stored on chain, and its value can be updated in subsequent contract calls
@prop(true)
b: bigint

// invalid, `b` is a stateful property that cannot be readonly
@prop(true)
readonly b: bigint

// good
@prop()
static c: bigint = 1n

// invalid, static property must be initialized when declared
@prop()
static c: bigint

// invalid, stateful property cannot be static
@prop(true)
static c: bigint = 1n

// good, `UINT_MAX` is a compile-time constant (CTC), and doesn't need to be typed explicitly
static readonly UINT_MAX = 0xffffffffn

// valid, but not good enough, `@prop()` is not necessary for a CTC
@prop()
static readonly UINT_MAX = 0xffffffffn

// invalid
@prop(true)
static readonly UINT_MAX = 0xffffffffn

3. Constructor

A smart contract must have an explicit constructor() if it has at least one @prop that is not static. The super method must be called in the constructor and all the arguments of the constructor should be passed to super in the same order as they are passed into the constructor. For example,

class A extends SmartContract {
  readonly p0: bigint

  @prop()
  readonly p1: bigint

  @prop()
  readonly p2: boolean

  constructor(p0: bigint, p1: bigint, p2: boolean) {
    super(...arguments) // same as super(p0, p1, p2)
    this.p0 = p0
    this.p1 = p1
    this.p2 = p2
  }
}

arguments is an array containing the values of the arguments passed to that function. ... is the spread syntax.

4. Methods

Like properties, a smart contract can also have two kinds of methods:
a. With @method decorator: these methods can only call methods also decorated by @method or functions specified below. Also, only the properties decorated by @prop can be accessed.

b. Without @method decorator: these methods are just regular TypeScript class methods.

a. @method decorator
This decorator is used to mark any method that intends to run on chain. It takes a sighash flag as a parameter.

Public `@methods`

Each contract must have at least one public @method. It is denoted with the public modifier and does not return any value. It is visible outside the contract and acts as the main method into the contract (like main in C and Java).
A public @method can be called from an external transaction. The call succeeds if it runs to completion without violating any conditions in assert(). An example is shown below.

@method()
public unlock(x: bigint, y: bigint) {
  assert(x + y == this.sum, 'incorrect sum')
  assert(x - y == this.diff, 'incorrect diff')
}

Ending rule
A public @method method must end with assert() in all reachable code paths. A detailed example is shown below.

class PublicMethodDemo extends SmartContract {

  @method()
  public foo() {
    // valid, last statement is `assert()` statement
    assert(true);
  }

  @method()
  public foo() {
    // valid, `console.log` calls will be ignored when verifying the last `assert()` statement
    assert(true); //
    console.log();
    console.log();
  }

  @method()
  public foo() {
    // valid, last statement is `for` statement
    for (let index = 0; index < 3; index++) {
        assert(true);
    }
  }

  @method()
  public foo(z: bigint) {
    // valid, last statement is `if-else` statement
    if(z > 3n) {
        assert(true)
    } else {
        assert(true)
    }
  }

  @method()
  public foo() {
    // invalid, the last statement of every public method should be an `assert()` statement
  }

  @method()
  public foo() {
    assert(true);
    return 1n;  // invalid, because a public method cannot return any value
  }

  @method()
  public foo() {
    // invalid, the last statement in the `for` statement body doesn't end with `assert()`
    for (let index = 0; index < 3; index++) {
        assert(true);
        z + 3n;
    }
  }

  @method()
  public foo() {
    // invalid, because each conditional branch does not end with `assert()`
    if(z > 3n) {
      assert(true)
    } else {

    }
  }

  @method()
  public foo() {
    // invalid, because each conditional branch does not end with `assert()`
    if(z > 3n) {
      assert(true)
    }
  }
}

Non-public `@methods`

Without a public modifier, a @method is internal and cannot be directly called from an external transaction.

@method()
xyDiff(): bigint {
  return this.x - this.y
}

// static method
@method()
static add(a: bigint, b: bigint): bigint {
  return a + b;
}

NOTE
Recursion is disallowed. A @method, whether public or not, cannot call itself either directly in its own body, nor indirectly call another method that transitively calls itself. A more detailed example is shown below.

class MethodsDemo extends SmartContract {
  @prop()
  readonly x: bigint;
  @prop()
  readonly y: bigint;

  constructor(x: bigint, y: bigint) {
    super(...arguments);
    this.x = x;
    this.y = y;
  }

  // good, non-public static method without access `@prop` properties
  @method()
  static add(a: bigint, b: bigint): bigint {
    return a + b;
  }

  // good, non-public method
  @method()
  xyDiff(): bigint {
    return this.x - this.y
  }

  // good, public method
  @method()
  public checkSum(z: bigint) {
    // good, call `sum` with the class name
    assert(z == MethodsDemo.add(this.x, this.y), 'check sum failed');
  }

  // good, another public method
  @method()
  public sub(z: bigint) {
    // good, call `xyDiff` with the class instance
    assert(z == this.xyDiff(), 'sub check failed');
  }

  // valid but bad, public static method
  @method()
  public static alwaysPass() {
    assert(true)
  }
}

A SIMPLE SUMMATION SMART CONTRACT

A smart contract is a class that extends the SmartContract base class. A simple example is shown below.

import { SmartContract, method, prop, assert } from "scrypt-ts"

class Equations extends SmartContract {

  @prop()
  sum: bigint

  @prop()
  diff: bigint

  constructor(sum: bigint, diff: bigint) {
    super(...arguments)
    this.sum = sum
    this.diff = diff
  }

  @method()
  public unlock(x: bigint, y: bigint) {
    assert(x + y == this.sum, 'incorrect sum')
    assert(x - y == this.diff, 'incorrect diff')
  }

}

The smart contract above adds up two unknown variables, x and y.
Class members decorated with @prop and @method will end up on the blockchain and thus must be a strict subset of TypeScript. Everywhere decorated with them can be regarded in the on-chain context. Members decorated with neither are regular TypeScript and are kept off chain. The significant benefit of sCrypt is that both on-chain and off-chain code are written in the same language: TypeScript.
For further reading on how to write smart contracts on scrypt you can visit the scrypt doc.

INTRODUCTION TO SCRYPT SYNTAX AND DATA TYPES.

Bravolakmedia — Thu, 23 May 2024 17:11:25 +0000

sCrypt is a subset of TypeScript used for writing smart contract on BSV blockchain. It is said to be an embedded Domain Specific Language (eDSL), simply put, it is a language within another language which is TypeScript. The choice of TypeScript as the host language for sCrypt fulfills two of the aims of writing bitcoin smart contracts. It is a familiar JavaScript programming language with type safety features. Thus to use it for bitcoin smart contract, a programmer do not need to learn new programming language. This article focuses on introduction to sCrypt, sCrypt syntax and data types. It aims at introducing newcomers into the sCrypt syntax and data types which are essentials for writing smart contracts and building decentralized applications (dApps) on BSV blockchain.

INTRODUCTION TO SCRYPT.

sCrypt is a high-level programming language that is specified for writing smart contracts on BSV blockchain. It is designed with high emphasis on reliability and security for developers use within the BSV ecosystem. It utilizes the inherent Bitcoin protocol i.e script verification. This feature alone give smart contracts written on sCrypt high level of integrity. sCrypt language is compiled into Bitcoin Script which result in assembly-like scripts that can be used as a locking scripts while building transactions on BSV blockchain.

Bitcoin uses a scripting system for transaction. Script is a simple series of instructions. These instructions are in sequential order and stack-based. Data is pushed onto the stack and opcodes are used to perform operations on items found on the stack. To learn more about bitcoin scripts you can check here.

Key Features Of SCRYPT.

sCrypt has some key features which gives it more benefits over other languages that are used for writing smart contracts. Some of the features and benefits offered by sCrypt are stated below.

Security and Reliability: sCrypt leverage on inherent security protocol of the Bitcoin by building on top of the Bitcoin scripts. As such it minimizes the risk of vulnerabilities and exploits.
Script Compatibility: sCrypt is completely compatible with Bitcoin Scripts, thus it enables easy integration of smart contracts written with sCrypt into the existing Bitcoin infrastructure. Bitcoin Script codes can also be translated into sCrypt code.
Syntax Resemblance: sCrypt syntax resembles that of the familiar programming languages like Python and JavaScript. It also has programming constructs like variables, functions, loops and conditionals. The syntax and structure resemblance in sCrypt reduces learning curves for developers that are familiar with programming languages like JavaScript and Python.
Deterministic Execution: sCrypt enforces predetermined execution of smart contracts which is essential for consensus and BSV blockchain integrity maintenance. This enhances the reliability and trustworthiness of smart contracts on BSV.
Scalability and Performance: sCrypt has lightweight and efficient architecture that minimizes resources consumption. It enables the creation of complex smart contracts with high level of performance and scalability.
Tools and Development Environment: sCrypt offers a comprehensive suite of developers tools and resources to support developers throughout the smart contract development life cycle. The tools include integrated development environments (IDEs), testing frameworks and documentation. The tools help to simplify development, code review and debugging process.
BASIC SYNTAX OF sCrypt.

sCrypt has basic syntax elements like variables, functions, conditionals and loops just like other programming languages.

Variables: Data is store in variables and the variable can be declared using the key word var const or let Examples of variable declarations is shown below

let a: bigint = 1n // n-suffix means the constant will be compiled as a bigint
a = BigInt(1) // Can also be defined with the BigInt() wrapper instead
var b: boolean = false
const N: number = 3

As shown above, variables are declared using the keyword, followed by the variable name and the variable can be initialized with a value. Using the keyword let we initialize the variable named ‘a’ with value of 1 which is a big integer. The variable named ‘b’ is initialized to be false, it is a boolean type. Lastly the variable named ’N’ is initialized to be 3, it a number.

Functions: Functions are blocks of code that performs a specific task and can be reused in a smart contract. Functions are declared using the function keyword, followed by the function’s name, parameters and the function’s body inside a curly bracket as shown below;

function add(int a, int b) {
    return a + b;
}

The function above is an addition function to add two integers ‘a’ and ‘b’ and return the sum of the two. The name of the function is ‘add’ , with parameters (int a) and (int b). The body of the function contain the return statement of the function.

Note that while writing smart contract for BSV blockchain using sCrypt, some functions are built-in-functions that may be a bit varied from the format above as shown in the example below.

// None of the below functions need an explicit import, as they're built into scrypt-ts itself.

let h = sha256(utf8ToByteString("hello"))
assert(
  h == toByteString("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824")
)

As shown above assert is a built-in function in sCrypt, it throws error only if the conditions passed to it is false. If all the conditions passed to assert is true, a contract call will be successful. The condition passed to assert in the code snippet above is h == toByteString(“2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824”).

Conditionals: Conditionals are used to execute different blocks of code according to defined conditions. Conditional include if else and else if statements as shown below;

if (x > 0) {
    // Code block to execute if x is greater than 0
} else if (x == 0) {
    // Code block to execute if x is equal to 0
} else {
    // Code block to execute if x is less than 0
}

Loops: Loops are used to execute a block of code continuously as long as a specified condition is true. Bitcoin Script does not provide looping constructs natively for security reasons, to prevent DoS attacks. All loops must be bounded at compile time. If there is a need to loop inside @method, the following format must be strictly used:


for(let i = 0; i < maxLoopCount; i++) {
  ...
}

As shown above, the initial value must be zero, the operator used must be < then initial value increments i++ . maxLoopCount must be a compile-time constant. Loop like break and continue are currently not allowed currently.

Comments: Comments are used to add explanatory notes within a code but the comments are ignored by the compiler. Single-line comments start with //, and multi-line comments are enclosed between /* and */. Examples are shown below;


// This is a single-line comment

/*
This is a multi-line comment
that spans multiple lines
*/

DATA TYPES IN sCrypt.

In the traditional programming language, we are conversant with the data types integer, boolean, string and array. Integers used the keyword int and are used to represent positive or negative whole numbers. Booleans used the keyword bool and are used to represent true or false values. String used the keyword string and are used to represent text data. These data type are present in sCrypt with some additional ones and some modifications. sCrypt data types can be classified as basic types, number type, array types, user defined type and domain type.

Basic Data Types: Examples of basic data types are boolean, bigint (big integer) and string. While writing smart contracts with sCrypt, boolean and bigint are allowed to be used in @props and @methods along with their wrapper types Boolean and BigInt . A string literal is not allowed to be used directly without being converted into a ByteString. Examples of these data types in use is given below;

@method()
public example(x: bigint, y: ByteString, z: boolean) {

    assert(x == 5n)

    assert(z)

    // Strings must by converted to ByteString before being used
    // in a smart contract:
    assert(y == utf8ToByteString("hello world!"))

    // We can also parse hex strings:
    assert(x == unpack(toByteString('05')))

    // Vice versa, we can turn integers into ByteStrings:
    assert(pack(x) == toByteString('05'))

    // Little-endian signed-magnitude representation is being used:
    assert(pack(-x) == toByteString('85'))
    assert(pack(-x * 1000n) == toByteString('8893'))

}

As shown above, strings must be converted to ByteString before being used in a smart contract like the case for the string “hello world”. Integers can be turned into ByteString and from ByteString back to integer.

Number Type: The number type is not allowed in @props and @method.

In some special cases, parameters of type number must be passed. In this case, we can use Number() function to convert bigint to number. Example of this is shown below;


// Array indexes:
let arr: FixedArray<bigint, 3> = [1n, 3n, 3n]
let index: bigint = 2n
let item = arr[Number(idx)]

// ByteString operations:
let size: bigint = 3n
let b: ByteString = reverseBytes(toByteString("001122"), Number(size))
let end: bigint = 1n
b.slice(0, Number(end))

In the examples above Number() is used to convert bigint in array indexes to number arr[Number(idx)]. It is also used to convert bigint in ByteString operations to number, Number(size) and Number(end).

Note that, number type can also be converted to bigint as shown below;

let x: bigint = BigInt(10)

Array Types: The common array types in TypeScript like T[] or Array are not allowed to be used in @props and @methods. An array must be declared as type of FixedArray, whose LENGTH must be a compile-time-constant value as shown below:

let aaa: FixedArray<bigint, 3> = [1n, 3n, 3n]

const N = 2
let aab: FixedArray<bigint, N> = [1n, 2n]

// 2-dimensional array
let abb: FixedArray<FixedArray<bigint, 2>, 3> = [
  [1n, 3n],
  [1n, 3n],
  [1n, 3n],
]

// Fill:
let zeroArr = fill(0n, 3) // = [0n, 0n, 0n]
const M = 3 // Length must be a compile time constant
let falseArr = fill(false, M)

User Defined Type: Users can be define customized data types using type or interface, made of basic types.

type ST = {
a: bigint
b: boolean
}

interface ST1 {
x: ST
y: ByteString
}

Domain Types: There are several domain data types specific to the Bitcoin context, used to further improve type safety.

let pubKey = PubKey(
  toByteString("02a2ef6eb12d3076dbdc98241920f75ac88b664656400aa390a0b236ea1eb6ec0b")
)

let pkh = Addr(pubKey2Addr(pubKey))

let h = Sha256(sha256(utf8ToByteString("hello")))

// Will fail as passed data is not a SHA256 hash:
//let h2 = Sha256(utf8ToByteString('ffaabb'))
These data types provide the foundation for storing and manipulating data within sCrypt smart contracts. The basic syntax elements provide the foundation for writing smart contracts in sCrypt. Good knowledge and usage of both data types and sCrypt syntax will help developers to create clear, concise, and maintainable smart contracts on the BSV blockchain. For further reading visit the sCrypt documentation and look toward our next article.