It's says Skake.

I went through several information (website, repos), but was not able to understand:

• is the scale-network independent of Eth1/2 network?
• what is the current status (betanet, testnet, mainnet) ?
• what is the roadmap?

skalenetwork/skale-manager#239

[SIP-4] SKALE S-Fuel Attainment via Gas Station

The Problem(s)

The current problems that exist regarding the initial attainment of S-Fuel is twofold: one for the developer and one for the users.

The Developers

 - Existing solutions include Proof-of-Work (PoW) and Custom Faucets
 - Proof-of-Work (PoW)
    - The Proof of Work solution provided by SKALE is strong, however, comes with its own difficulties whether it be the implementation into the build of a platform, or with the time complexity required. 
    - Custom Faucet
       - Implementing a Faucet itself is not that difficult, however, faucets generally can only be called by an external signer which does not necessarily solve this problem directly

The Users

 - Regardless of PoW or Faucet usage, users generally have to copy and paste an address or click on a button in order to attain S-Fuel which is counter intuitive to many platforms that are trying to abstract the blockchain parts away from users. Additionally, it may become painful for users if they are utilizing more than one SKALE dApp and have to consistently claim S-Fuel on multiple networks.

The Solution

The solution that I am proposing is similar to the Gas Station Network found on Ethereum. This solution would be auto-deployed on each SKALE chain. From here a simple script/function can be written that automatically signs a transaction on the client, sends it to the Gas Station which then forwards it on to a SKALE chain S-Fuel faucet which completes by sending S-Fuel to the original sender. This process contains three parts:

1. Gas Station
2. Faucet
3. Client Script

By connecting the three pieces together, this would result in developers just adding the script to their initial onboarding and then immediately upon using the dApp the user can interact with the application.

Alternatives

The only alternative currently being is a faucet that doesn't require signing. To my current knowledge, a read-only (call) function cannot be used to make a function that can utilize the payable/transfer functionality in Ethereum. However, with SKALE V2 it may be possible to utilize an Oracle to run this external call.

Additional Context

• Either the Gas Station or the Faucet should contain a whitelist that way S-Fuel can only be claimed by a user one time to avoid too much S-Fuel being allocated which would be a security vulnerability
• A solution like this could give developers building dApps using other languages: Java, Dart, Ruby, etc. that have Web3 tie-ins the ability to easily integrate with SKALE without having to rely on JavaScript as the client tie-in could be ported very quickly to other languages

Address and ABIs distribution

Description

Each set of smart contracts (i.e. skale-manager, IMA) exists in multiple instances and versions on multiple networks (Ethereum mainnet, Rinkeby or Kovan) and serve different needs (production, testnets, hackathons and others). It creates a problem of providing addresses of these smart contracts. Currently it's solved by the skale-network repo which contains files with desired addresses.

Address Solution

• npm package to provide an interface for javascript and typescript applications
• pypi package to provide an interface for python applications
• modify deployment scripts in all smart contracts repos to register addresses in the system right after deployment

Addresses will be provided in hierarchical logic structure application-name -> instance-name -> smart-contract-name -> address.

For example: ima -> eth-amsterdam -> DepositBoxERC20.

Example in code:

> import { ima } from "@skalenetwork/abis";

> ima.DepositBoxERC20.address // ethereum mainnet by default
'0x2a42Ccca55FdE8a9CA2D7f3C66fcddE99B4baB90'

> ima.eth_amsterdam.DepositBoxERC20.address
'0x3Fc377c4322f9d448996c3faBe1150213A434bC1'

Because IMA is deployed on many chains it requires additional level to specify SKALE chain.

Example:

> import { ima } from "@skalenetwork/abis";

> ima.eth_amsterdam.fit-solitude.MessageProxyForSchain.address
'0xd2AAa00100000000000000000000000000000000'

ABIs solution

1. resolve address of a desired smart contract
2. make rpc call to request smart contract version
3. download corresponding ABI from github releases

Steps to be done:

• add version for all smart contracts
• automatically publish ABI for all smart contracts repos to github releases
• modify packages

Example:

> import { ima } from "@skalenetwork/abis";

> ima.version // ethereum mainnet by default
'1.9.0'

> ima.DepositBoxERC20.abi
[ ... ]

[SIP-6] S2S Automatic S-Fuel Allocation

The Problem(s)

NOTE** Due to V2 not being out yet this is not an official issue, more of planning for the future.

The assumed issue will be that User A wants to send NFT from dApp W on S-Chain X to dApp Y on S-Chain Z.
User A has S-Fuel on S-Chain X, but none on S-Chain Z. When user A transfers the NFT and then wants to perform an action he is restricted by a lack of S-Fuel.

The Solution

This solution is relatively straightforward. Provide an additional check on S2S movement that will automatically send S-Fuel to the address of the receiver on the receiving S-Chain in order to facilitate automatic usage of dApps and increase the ability and desire of users to move between chains without thinking about the pain points.

With a limited lack of S2S knowledge currently, my initial thought process is to have a parameter passed with the transfer automatically which is the users current balance of S-Fuel on the transfer they are moving from and then the chain receiving mints them the corresponding S-Fuel on the new chain.

Hello:
I want to bridge some BTCBAM tokens from its native network ‘BTCBAM’ to Ethereum (ERC20) network, so I can get some wrapped BTCBAM tokens.
I know its contract address on BSC is: 0x79abC799ae4B749C01e07a60c8687A49D128eA1C
Someone has provide the following URL for bridging the navite ‘BTCBAM’ token to Ethereum (ERC20) network. The URL is:
https://0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7.art/
I think maybe this is a unisawp or skale-network, but I am not sure.
However, the issue is: I can never connect automatically when I launch my MetaMask wallet, the web page always asks me to input private key or 12-words paraphrases.
I don't think a good bridge will ask users to input private key or paraphrases, as from my personal experience, this will result in loss of all funds in the MetaMask wallet.
My question is: if this URL is some kind of Unisawp or Skale-network bridge, then someone should fix the bug, as it always ask users to input private key or paraphrases.
By the way, I also need some advice on how to use Uniswap or Skale-network to bridge tokens as what I want to do.
Please advise,
Thanks,

[SIP-5] SKALE S-Fuel Solidity Contract & Modifier

The Problem(s)

The current problem is that in order to continuously have S-Fuel to interact with dApps users need to utilize the specific dApp functionality to claim S-Fuel. This results in the potential failure of a call due to a lack of S-Fuel, or the need for additional button clicks in order to attain the S-Fuel.

Additionally, it requires the S-Fuel to be allocated by the developer manually in order to maintain the needed balance to provide it to users.

The Solution

The solution that I am proposing is a specific S-Fuel contract (this could be tied in with SIP-4) that is the default allocation location of S-Fuel. This contract would also have utilities that call it within another contract. The process for this is as follows:

1. Upon SKALE chain deployment, Smart Contract SFaucet is deployed.
2. The SKALE Config utilizes the pre-deployed address to allocate Y amount of S-Fuel to faucet.
3. A SFuel utility contract is utilized by the developer to add a modifier (if possible) or a a minimum a function that can be used in other functions.
4. Modifier/Function will check msg.sender or _msgSender() balance of S-Fuel depending on contract build and if under X minimum set in utility, call SFaucet contract in order to top up user balance automatically.

Alternatives

One alternative which is currently outside the direct scope of solidity, but is potential possible with an Oracle is a cron-job that runs this check and tops up user balances on a consistent balance based on a user whitelist for the dApp. This still may result in users not having enough S-Fuel at any given time and should be considered Plan B.

Additional Context

• The modifier/function will only need to be called on certain functions.
  • Functions that may want this include popular functions like in-game actions or expensive functions that use high amounts of S-Fuel (EX: Uploading a multi-chunk file to SKALE File Storage)
  • If a modifier, it must be extended by a contract (NOT a library)

Example Code

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

import "@openzeppelin/contracts/access/Ownable.sol";

contract SFaucet is Ownable {

    mapping(address => uint256) sFuelBalance;

    // Configurable By S-Chain Owner
    uint256 public DEFAULT_CLAIM = 100000;

    //** NOTE *//
    // Recieve and Fallback may not be necessary
    receive() external payable {}

    fallback() external payable {}

    //** END NOTE *//

    function claim() external {
        payable(_msgSender()).transfer(DEFAULT_CLAIM);
    }

    function updateDefaultClaimAmount(uint256 amount) external onlyOwner {
        DEFAULT_CLAIM = amount;
    }
}

contract SFaucetUtils {

    address sFaucetAddress = 0x0000000000000000000000000000000000000000;
    uint256 MIN_AMOUNT = 100000;

    modifier checkSFuel {
        if (msg.sender.balance < MIN_AMOUNT) {
            SFaucet _faucet = SFaucet(payable(sFaucetAddress));
            _faucet.claim();
        }
        _;
    }
}

contract ExampleContract is SFaucetUtils {


    function doSomething() external checkSFuel {
        // Function Here
    }
}

Naming Convention for Public Chain Listings

When a chain is created for a dApp, Hub, etc; the listing on popular projects such as ChainList.org should be done by the project owners.

The listing/data provided for an integration is required by the platform. However, the actual name utilized by each SKALE chain could potentially match a given format to provide better visibility of chains across the ecosystem.

For example, we can have all chains named: | SKALE.

Examples could include:

Calypso -> Calypso NFT Hub | SKALE
Europa Hub -> Europa Hub SKALE Chain
General Chain Name -> SKALE | General Chain Name

This way when searches are made on these platforms for "SKALE"; all listed chains show up.

While the above would not be a requirement it is merely a suggestion to aid network wide visibility for all participating dApps and community members.