KUB Docs
  • Introduction to KUB
  • Connect to KUB
  • KUB PoS
    • Increase block gas limit to 90M
    • Update GasPrice Instruction
    • Incident from chaophaya hardfork
    • Overview
    • Considerations
    • Validator Node
      • Node Requirements
      • Run Validator Node
      • Validator Staking
      • StakeManager Contract
      • ValidatorShare Contract
      • Slashing
    • Run Full Node
    • Run Archive Node
    • Chaindata Snapshot
    • Migration PoSA to PoS
    • Delegator
      • How to delegate
      • How to claim reward
      • How to unstake
  • Developer Center
    • ✨Getting Started
    • 🏆Project Tiers
    • 👨‍💻Connect Bitkub NEXT to register as a new user
    • ✔️Verify your identity via Bitkub NEXT (KYC or KYB)
    • 💰Subscribe to the KUB Developer Package
    • 🗳️Submit your project
      • 📗Create submit project
      • 📘Manage your project
        • Submit project
        • Create a new project version
        • Status of project version
      • 📙Manage project information
  • KUB SDK
    • NEXT SDK
      • NEXT SDK Code Cookbook
      • KUB SDK Compatible Smart Contract
        • Example Smart Contract for Testing
        • Example KUB SDK Compatible KAP20 Smart Contract
        • Example KUB SDK Compatible KAP721 Smart Contract
  • KUB Playground
    • Quick Start Guide on KUB Playground
  • KUB Layer 2
  • KUB Scan
  • RPC Service
    • JSON-RPC Endpoint
  • IPFS Service
    • IPFS Guideline
  • FAQ
  • Glossary
  • Reference and Service
    • KUB Whitepaper Version 3.3
    • Technical Paper Version 3.2
    • KUB Explorer
    • KUB Faucet
    • KUB Oracle
    • KUB Bridge
    • KKUB OTP
Powered by GitBook
On this page
  • 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
  • b. Function that can be called by anyone
  • 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

Was this helpful?

  1. Guide for implementing a smart contract

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.

For example: function executeTask(address _bitkubNext) public onlyAllowedAddresses

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.

Last updated 1 year ago

Was this helpful?

i. Function changes to comply with 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.

The above function is similar to , 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 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.

1.a
1.a
1.b