MoltenChain Proof-of-Stake(PoS) blockchain for the native MAGMA cryptocurrency. The MoltenChain source code is purely written in TypeScript. With extendability using smart contract written in Lua.
MoltenChain's Features
We have written in many functions into the core base of MoltenChain's source code.
Here is a list of MoltenChain's built in features.
5 second transaction time.
Quick fetch for bringing new nodes online quickly.
Mint and deployment of FTs, and NFTs.
Wallet functionality with atomic swapping.
Local and remote JSON as a DB function.
A smart contract mechanism for Lua scripting language.
Full compatibility with IPFS, webtorrent and H5P.
Light weight source code with quick deployment for easier to manage nodes and quick start for devs.
A built in Liquidity function.
Built in locking function for liquidity and tokens.
Custom address system with namespace style wallet addresses, example: lolcatz.magma or yourname.magma
Simple to use and easy to understand dev api.
When does MoltenChain launch?
Although there is not a launch date set in stone, right now the current projections are MoltenChain testnet will launch around July 2023.
With a potential for a mainnet coin pre-sale launch around October 2023.
How secure will MoltenChain be overall?
TypeScript uses the TypeScript compiler (tsc), which checks for errors and compiles TypeScript into JavaScript. Certain compiler options increase security, such as strict and noEmitOnError.
The former increases security by turning on a series of flags to force TypeScript to run in a stricter mode. For example, it turns on things such as noImplicitAny, strictNullChecks, and noImplicitThis, all of which protect your application from including unsafe constructs.
In addition, the option noEmitOnError prevents the tsc from creating the corresponding JavaScript file if there is an error within the code, increasing security by preventing errors from being compiled into JavaScript code.
While more code is written, you are generating more code to increase security. The extra code defines types and adds type checks and validation functions. Types define what input is allowed into an object; not having types can cause errors and potential security weaknesses. In TypeScript, the types are strings, numbers, and interfaces, which can help define the syntax of future type checks and input validation.
Writing extra code upfront to define types and ensure type safety can help save time by preventing developers from having to fix type errors later.
Fixing type errors in languages without static, strict types is difficult - you have to figure out where in the code the error is generating from, how to fix it, and determine if any other errors resulted from the fix, all without the help of the IDE or the language itself. While in a strict static typed language, it will prevent these issues entirely and report any additional errors during compilation.
Dynamic Typing is a security problem, because it only checks types at runtime. Therefore, any security issues are caught while the application is running and not while it is under development.
Static typing checks types at compile-time, which prevents type issues before they become vulnerabilities.
When you are trying to remediate the source of an error or weakness, it takes longer to edit code in dynamic typing than in static typing.
This is due to the expressive errors and compile-time type checks native to static typing. More expressive errors give more information about where the code's errors lie, such as the file and line number.
Checking types at compile time means that errors are found closer to the source, making it easier to return and fix than if the error was found during runtime.
TypeScript Security Win: TypeScript provides static typing, which checks types at compile-time, preventing issues before they become vulnerabilities, and giving more expressive errors to aid in the identification and resolution of errors.