layerx-labs/dappkit

A framework to build web3 dapps with javascript/typescript

dappkit's Issues

Emit event on network parameter change

Abstract

NetworkV2.sol is the contract for the BEPRO network and controls Bounties, PRs, TVL and some fees.

Goal

When a network parameter change happens via the changeNetworkParameter function, an event should be emitted telling what parameter changed and what’s its new value.

Deliverable

To achieve this, change changeNetworkParameter function on contracts/bepro/NetworkV2.sol:232 to emit a new event called NetworkParamChanged with values uint256 param, uint256 newvalue, uin256 oldvalue

Add new tests under test/models/network-v2.spec.ts that account for this change, adding a new it that expects an event to be caught on the logs when a network parameter has changed.

NOTE

This bounty could be complex, since the NetworkV2.sol contract is at its size limit.

1

1

[BUG] Erc721Standard - Deploy a NFT

Describe the bug

I try to implement the Erc721Standard documented in https://docs.dappkit.dev/start-building/how-to-guides/create-an-erc721
And I have an error occuring in the mint function part. I think it something from the framework. Maybe something that I didn't defined or is missing.

Reproduction

Take the code example provided from the documentation.
I used the code below for testing different approaches and I have the same result from the code of the documentation.

Context: I try to create an NFT and send it to one user address. I test this on localy (with ganache) and on Goerli, and have the same result.

async function createEventTickets() {

    let userAddress = "0x0xxx";
    let privateKey = process.env.PRIVATE_KEY;

    /* Deploying your NFT */
    const deployer = new Erc721Standard({
        web3Host: "http://127.0.0.1:7545",
        privateKey: privateKey
    });

    await deployer.connection.start();
    // await deployer.connection.connect();
    await deployer.loadAbi();

    let receipt;

    receipt = await deployer.deployJsonAbi('My NFT Name', '$MyNftSymbol');
    console.log('deployed!', receipt);

    /* Using your NFT after deployment */
    const myNFT = new Erc721Standard({
        web3Host: "http://127.0.0.1:7545",
        privateKey: privateKey
    }, receipt.contractAddress);

    await myNFT.connection.start();
    await myNFT.loadAbi();
    await myNFT.loadContract();

    console.log("Before mint !")

    receipt = await myNFT.mint('0x0xxx', 1);
    console.log('Minted!', receipt);

}

Expected behavior

Create and mint a NFT.

Logs, screenshots

/home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-abi/lib/index.js:254
        if (param.length % 2 === 1) {
                  ^
TypeError: Cannot read property 'length' of undefined
    at ABICoder.formatParam (/home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-abi/lib/index.js:254:19)
    at /home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-abi/lib/index.js:99:22
    at Array.map (<anonymous>)
    at ABICoder.encodeParameters (/home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-abi/lib/index.js:93:21)
    at /home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-contract/lib/index.js:463:20
    at Array.map (<anonymous>)
    at Object._encodeMethodABI (/home/rere/Documents/Project/ETHPorto/contract/node_modules/web3-eth-contract/lib/index.js:462:8)
    at Erc721Standard.<anonymous> (/home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/base/model.js:97:72)
    at Generator.next (<anonymous>)
    at /home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/base/model.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/base/model.js:4:12)
    at Erc721Standard.sendTx (/home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/base/model.js:95:16)
    at Erc721Standard.<anonymous> (/home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/models/erc721-standard.js:39:25)
    at Generator.next (<anonymous>)
    at /home/rere/Documents/Project/ETHPorto/contract/node_modules/@taikai/dappkit/dist/src/models/erc721-standard.js:8:71

versions, packages, etc

node version: v16.0.0

Additional context

ERC-4626 Tokenized Vault Standard

In order for @taikai/dappkit to support ERC4626 you will need to either update openzepplins

version on package.json or import the code from the latest openzepplin branch, from then a TypeScript proxy is needed and finally end-2-end tests for the implementation.

Optionally, You can use @taikai/dappkit-launchpad to help you on the conversion from solidity to dappkit classes.

Deliverables:

• contracts/ERC4626.sol
• src/models/erc4626.ts
• test/models/erc4626.spec.ts

You can find tutorials on how to create new models and integration tests inside the how-to/contributing folder

ERC721Marketplace | reentrance

Describe the bug

I think I found a vulnerability on ERC721Marketplace.sol
I think reentrance could be possible if you use isNativeTransaction to buy ERC721, the contract requires that the Token wasn't sold yet, but it only modifies its state after all things are done.
If you create a reentrance contract, it could call multiple times and send native tokens to nft owner.

Reproduction

Logs, screenshots

versions, packages, etc

Additional context

1

1

Create Leverage Trading Platform up to 10x

Create a leverage trading platform where users can leverage trade BTC, and ETH up to 10x. User can leverage trade using USDT or Bepro tokens

11

1

Test

asdasd

Emit event on network parameter change

Abstract

NetworkV2.sol is the contract for the BEPRO network and controls Bounties, PRs, TVL and some fees.

Goal

When a network parameter change happens via the changeNetworkParameter function, an event should be emitted telling what parameter changed and what’s its new value.

Deliverable

To achieve this, change changeNetworkParameter function on contracts/bepro/NetworkV2.sol:232 to emit a new event called NetworkParamChanged with values uint256 param, uint256 newvalue, uin256 oldvalue

Add new tests under test/models/network-v2.spec.ts that account for this change, adding a new it that expects an event to be caught on the logs when a network parameter has changed.

NOTE

This bounty could be complex, since the NetworkV2.sol contract is at its size limit.

test 1

Some notification EOAs are tagging scammers on chain about scam contracts they deploy. This bot should monitor these notification EOAs and emit an alert on the scam contract/ EOA associated with the to address the scam notifier sends messages to. An example EOA is the 0xcd5496ef9d7fb6657c9f1a4a1753f645994fbfa9 (scamwarning.eth). An example message is: https://etherscan.io/tx/0xe5b57fd6c5b8376ce2fb1ace5688dd719db977c8e658dd582dedc5ede19687bd.

However, the above address is just an example and more notification EOAs may exist on mainnet as well as different chains. The bot should automatically update the list of notification EOAs by performing an analysis based on other notifications. E.g. if scamwarning.eth notifies contracts 1-10 and another EOA notifies a subset of the same contracts, it is likely another notification EOA. The bot should automatically perform this analysis and grow the notification EOAs it monitors.

The bot should emit three types of alerts as per the following condition:

A suspicious alert in case one of the notification EOAs sends a message to an EOA with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-EOA

  • Description: “{scammer_eoa} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_eoa - the address of the scammer EOA

    • scammer_contracts - a comma separated list of all the contracts the EOA created

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A suspicious alert in case one of the notification EOAs sends a message to an contract with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-CONTRACT

  • Description: “{scammer_contract} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_contract - the scammer contract

    • scammer_eoa - the address of the deployer EOA

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A info alert in case the bot identifies a new notification EOAs it will now monitor

The bot should emit the following alert:

• NEW-SCAM-NOTIFIER

  • Description: “New scam notifier identified {notifier_eoa} {notifier_name}”

  • Severity is always set to "info"

  • Type is always set to "info"

  • Metadata

    • ‘similar_notifier_eoa’ - the address of the notifier that it is similar to (as in flags similar contracts/EOAs)

    • ‘similar_notifier_name’ - a human readable name/ ENS name of the notifier that it is similar to (as in flags similar contracts/EOAs)

  • ‘union_flagged’ - comma separated list of addresses both have flagged

  • notifier_eoa - the address of the notifier

  • notifier_name - a human readable name/ ENS name of the notifier

Test

asdasd

11

1

Emit event on network parameter change

Abstract

NetworkV2.sol is the contract for the BEPRO network and controls Bounties, PRs, TVL and some fees.

Goal

When a network parameter change happens via the changeNetworkParameter function, an event should be emitted telling what parameter changed and what’s its new value.

Deliverable

To achieve this, change changeNetworkParameter function on contracts/bepro/NetworkV2.sol:232 to emit a new event called NetworkParamChanged with values uint256 param, uint256 newvalue, uin256 oldvalue

Add new tests under test/models/network-v2.spec.ts that account for this change, adding a new it that expects an event to be caught on the logs when a network parameter has changed.

NOTE

This bounty could be complex, since the NetworkV2.sol contract is at its size limit.

test 1

Some notification EOAs are tagging scammers on chain about scam contracts they deploy. This bot should monitor these notification EOAs and emit an alert on the scam contract/ EOA associated with the to address the scam notifier sends messages to. An example EOA is the 0xcd5496ef9d7fb6657c9f1a4a1753f645994fbfa9 (scamwarning.eth). An example message is: https://etherscan.io/tx/0xe5b57fd6c5b8376ce2fb1ace5688dd719db977c8e658dd582dedc5ede19687bd.

However, the above address is just an example and more notification EOAs may exist on mainnet as well as different chains. The bot should automatically update the list of notification EOAs by performing an analysis based on other notifications. E.g. if scamwarning.eth notifies contracts 1-10 and another EOA notifies a subset of the same contracts, it is likely another notification EOA. The bot should automatically perform this analysis and grow the notification EOAs it monitors.

The bot should emit three types of alerts as per the following condition:

A suspicious alert in case one of the notification EOAs sends a message to an EOA with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-EOA

  • Description: “{scammer_eoa} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_eoa - the address of the scammer EOA

    • scammer_contracts - a comma separated list of all the contracts the EOA created

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A suspicious alert in case one of the notification EOAs sends a message to an contract with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-CONTRACT

  • Description: “{scammer_contract} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_contract - the scammer contract

    • scammer_eoa - the address of the deployer EOA

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A info alert in case the bot identifies a new notification EOAs it will now monitor

The bot should emit the following alert:

• NEW-SCAM-NOTIFIER

  • Description: “New scam notifier identified {notifier_eoa} {notifier_name}”

  • Severity is always set to "info"

  • Type is always set to "info"

  • Metadata

    • ‘similar_notifier_eoa’ - the address of the notifier that it is similar to (as in flags similar contracts/EOAs)

    • ‘similar_notifier_name’ - a human readable name/ ENS name of the notifier that it is similar to (as in flags similar contracts/EOAs)

  • ‘union_flagged’ - comma separated list of addresses both have flagged

  • notifier_eoa - the address of the notifier

  • notifier_name - a human readable name/ ENS name of the notifier

1

1

11

1

1

1

Change maximum Percentage of fee Charged on a Network Creation

The NetworkRegistry contract acts as a registry and controller for NetworkV2 , Networks can only be assigned to a Registry if a certain amount of certain token is locked onto the contract; Currently it has a hardcoded value for Network Creation of 10 and it should be, instead, 99;

To achieve this bounty, change contracts/bepro/NetworkRegistry.sol:28 value to be equal to 99% and add tests that account for this change by adding another it test to test/models/network-registry.spec.ts that tests the change to 99%

apply decodeLog logic on transaction receipt

Abstract

As a @taikai/dappkit user, I would like to have the transaction-receipt decoded with the existing contract abi.

Goal

change the needed functions on @taikai/dappkit to return a decoded log when a transaction receipt is received.

Deliverable

• Change the transactionHandler() function at transaction-handler.ts to receive an ABI
• Change the sendUnsignedTx to pass the current this.contract.abi to the transactionHandler() call
• Change transactionHandler() function to account for logs and decode them with the provided abi

ViCi Web3Conect

https://github.com/taikai/dappkit/blob/72463a5266fe15dd75e5b78e4af78dcd4d635fb5/src/base/web3-connection.ts#L11

apply decodeLog logic on transaction receipt

Abstract

As a @taikai/dappkit user, I would like to have the transaction-receipt decoded with the existing contract abi.

Goal

change the needed functions on @taikai/dappkit to return a decoded log when a transaction receipt is received.

Deliverable

• Change the transactionHandler() function at transaction-handler.ts to receive an ABI
• Change the sendUnsignedTx to pass the current this.contract.abi to the transactionHandler() call
• Change transactionHandler() function to account for logs and decode them with the provided abi

test 1

Some notification EOAs are tagging scammers on chain about scam contracts they deploy. This bot should monitor these notification EOAs and emit an alert on the scam contract/ EOA associated with the to address the scam notifier sends messages to. An example EOA is the 0xcd5496ef9d7fb6657c9f1a4a1753f645994fbfa9 (scamwarning.eth). An example message is: https://etherscan.io/tx/0xe5b57fd6c5b8376ce2fb1ace5688dd719db977c8e658dd582dedc5ede19687bd.

However, the above address is just an example and more notification EOAs may exist on mainnet as well as different chains. The bot should automatically update the list of notification EOAs by performing an analysis based on other notifications. E.g. if scamwarning.eth notifies contracts 1-10 and another EOA notifies a subset of the same contracts, it is likely another notification EOA. The bot should automatically perform this analysis and grow the notification EOAs it monitors.

The bot should emit three types of alerts as per the following condition:

A suspicious alert in case one of the notification EOAs sends a message to an EOA with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-EOA

  • Description: “{scammer_eoa} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_eoa - the address of the scammer EOA

    • scammer_contracts - a comma separated list of all the contracts the EOA created

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A suspicious alert in case one of the notification EOAs sends a message to an contract with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-CONTRACT

  • Description: “{scammer_contract} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_contract - the scammer contract

    • scammer_eoa - the address of the deployer EOA

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A info alert in case the bot identifies a new notification EOAs it will now monitor

The bot should emit the following alert:

• NEW-SCAM-NOTIFIER

  • Description: “New scam notifier identified {notifier_eoa} {notifier_name}”

  • Severity is always set to "info"

  • Type is always set to "info"

  • Metadata

    • ‘similar_notifier_eoa’ - the address of the notifier that it is similar to (as in flags similar contracts/EOAs)

    • ‘similar_notifier_name’ - a human readable name/ ENS name of the notifier that it is similar to (as in flags similar contracts/EOAs)

  • ‘union_flagged’ - comma separated list of addresses both have flagged

  • notifier_eoa - the address of the notifier

  • notifier_name - a human readable name/ ENS name of the notifier

update

.

test 1

Some notification EOAs are tagging scammers on chain about scam contracts they deploy. This bot should monitor these notification EOAs and emit an alert on the scam contract/ EOA associated with the to address the scam notifier sends messages to. An example EOA is the 0xcd5496ef9d7fb6657c9f1a4a1753f645994fbfa9 (scamwarning.eth). An example message is: https://etherscan.io/tx/0xe5b57fd6c5b8376ce2fb1ace5688dd719db977c8e658dd582dedc5ede19687bd.

However, the above address is just an example and more notification EOAs may exist on mainnet as well as different chains. The bot should automatically update the list of notification EOAs by performing an analysis based on other notifications. E.g. if scamwarning.eth notifies contracts 1-10 and another EOA notifies a subset of the same contracts, it is likely another notification EOA. The bot should automatically perform this analysis and grow the notification EOAs it monitors.

The bot should emit three types of alerts as per the following condition:

A suspicious alert in case one of the notification EOAs sends a message to an EOA with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-EOA

  • Description: “{scammer_eoa} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_eoa - the address of the scammer EOA

    • scammer_contracts - a comma separated list of all the contracts the EOA created

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A suspicious alert in case one of the notification EOAs sends a message to an contract with a scam warning

The bot should emit the following alert:

• SCAM-NOTIFIER-CONTRACT

  • Description: “{scammer_contract} was flagged as a scam by {notifier_eoa} {notifier_name}”

  • Severity is always set to "high"

  • Type is always set to "suspicious"

  • Metadata

    • scammer_contract - the scammer contract

    • scammer_eoa - the address of the deployer EOA

    • notifier_eoa - the address of the notifier

    • notifier_name - a human readable name/ ENS name of the notifier

The bot should set the label for the EOA as well as any contract the EOA creates:

'entityType': EntityType.Address,

             'label': "scam",

             'confidence': 0.7

A info alert in case the bot identifies a new notification EOAs it will now monitor

The bot should emit the following alert:

• NEW-SCAM-NOTIFIER

  • Description: “New scam notifier identified {notifier_eoa} {notifier_name}”

  • Severity is always set to "info"

  • Type is always set to "info"

  • Metadata

    • ‘similar_notifier_eoa’ - the address of the notifier that it is similar to (as in flags similar contracts/EOAs)

    • ‘similar_notifier_name’ - a human readable name/ ENS name of the notifier that it is similar to (as in flags similar contracts/EOAs)

  • ‘union_flagged’ - comma separated list of addresses both have flagged

  • notifier_eoa - the address of the notifier

  • notifier_name - a human readable name/ ENS name of the notifier

apply decodeLog logic on transaction receipt

Abstract

As a @taikai/dappkit user, I would like to have the transaction-receipt decoded with the existing contract abi.

Goal

change the needed functions on @taikai/dappkit to return a decoded log when a transaction receipt is received.

Deliverable

• Change the transactionHandler() function at transaction-handler.ts to receive an ABI
• Change the sendUnsignedTx to pass the current this.contract.abi to the transactionHandler() call
• Change transactionHandler() function to account for logs and decode them with the provided abi

this is a test

.

apply decodeLog logic on transaction receipt

Abstract

As a @taikai/dappkit user, I would like to have the transaction-receipt decoded with the existing contract abi.

Goal

change the needed functions on @taikai/dappkit to return a decoded log when a transaction receipt is received.

Deliverable

• Change the transactionHandler() function at transaction-handler.ts to receive an ABI
• Change the sendUnsignedTx to pass the current this.contract.abi to the transactionHandler() call
• Change transactionHandler() function to account for logs and decode them with the provided abi