Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SIP-5] Minimum S-Fuel Balance for Consistent Usage (Auto S-Fuel Top Up) #102

Open
TheGreatAxios opened this issue Mar 23, 2022 · 0 comments

Comments

@TheGreatAxios
Copy link

[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
    }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant