Limitation of Function

Explain limitations, functions that are compatible with the contract that can be used with the SDK.

Because in the SDK system, a special address is created to be used to send transactions to the Bitkub Chain, so msg.sender and tx.origin are not the same as sending transactions normally that the user sends with Metamask, so there will be some function changes. Function so that it can be used with the SDK system.

1. Functions that do not need to be changed for use with the SDK system.

a. Functions with modifiers are for access control and are not intended to function as a user with msg.sender or tx.origin

If such a function can add a special address that the SDK system can create so that it can be called, then the function does not need to be changed to make it work with the SDK system.

For example: function executeTask() public onlyAllowedAddresses

The above function has a modifier onlyAllowedAddresses , it checks if msg.sender is in the list of Allowed Addresses . In this case, we can add a special address from the SDK so that the SDK can call this function.

Incidentally, the example of 1.a represents a function that can only be called by the SDK system. But it does not include functions that the SDK system can call to work instead of as a User, but for the SDK system to call a function, the User must be the commander with the User's Bitkub Next Access Token.

b. Function that can be called by anyone

If a function is expected to be called by any address, it can also be called by a special address of the SDK system. Therefore, there is no need to change.

For example: function updatePool(uint256 _pid) public

The aforementioned function is a function from MasterChef. It is intended to update the pool. Anyone can call that function to update the pool.

2. Functions that need to be changed for use with the SDK system

a. Function that will be called by the function purpose instead of user changes required

The Function mentioned above can be divided into two methods.

i. Function changes to comply with 1.a by adding a Modifier for Access Control and receiving an Input that can be used to indicate the User who wants to work instead, such as a Wallet Address.

For example: function executeTask(address _bitkubNext) public onlyAllowedAddresses

The above function is similar to 1.a, but the above function also accepts Bitkub Next User's Wallet Address to specify the User who wants to transact instead.

ii. Changing the function to be similar to 1.b by adding an input for confirmation that the user's consent has already been performed instead of working, such as Ethereum Sign Message, but because Bitkub Next User cannot create a signature for authentication, a signature that can be able to use it, it must be a signature that was created with an external tool such as Metamask. Such a system may verify the user's identity with Bitkub Next but uses the user's personal wallet address for transactions on the Bitkub Chain. The advantages of such a system are Proposing a system where users do not need to pay for gas and send transactions by themselves but instead use the SDK system to send transactions.

For example: function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external

The above function comes from PancakeSwap's Contract Pancake Pair or PancakeSwap's Contract LP Token. This function works the same as the ERC20 Approve, but the address that calls the above function can be anyone. v r and s are Ethereum Sign Messages generated from ethers.js and Metamask, so the SDK system can call the function User if there is an Ethereum Sign Message from User.

The above Ethereum Sign Message will come from the Wallet Address from Metamask, but running the SDK system still requires the Bitkub NEXT User Access Token as before.