baking-bad / bcd Goto Github PK

Description

Building an array of array of NAT (only tested with NAT) yields an error when executing the operation.

Steps to reproduce

• https://better-call.dev/mainnet/KT1Djz5ix2yEGmV7PMq3GYq17TvMMkd1anT2/interact?entrypoint=update_cycles
• click on + ADD on the update_cycles parameter builder
• click on + ADD in the popin
• click on OK
• it should have built the following parameter: [[ 0 ]]
• execute the operation

It yields the following error: List.FromJSONSchema map[string]interface {}: invalid type

When an operation changes values in the storage, BCD shows the previous value followed by the new value. Because the numbers are often very big, it is hard to see how much the value changed. It would be great if the diff could be displayed and the numbers could be formatted.

Eg. add a diff:

tez_pool: 2312622041 => 2313022041 (-400000)

The same would also be helpful for timestamps, showing how many days/hours/minutes a value changed.

It would also be helpful if numbers would have a delimiter, eg. a ('). So then it would look like:

tez_pool: 2'312'622'041 => 2'313'022'041 (-400'000)

Those 2 changes would make reading the storage diffs a lot easier.

When interacting with a function on a contract and signing the tx with Temple wallet (in firefox) i recently always get a
"Failed to send operations. cannot use 'in' operator to search for "prim" in "{"int":"0"}" in Temple wallet for all interactions across dfferent contracts

for example:

https://better-call.dev/hangzhou2net/KT18pA1mwpefkE2obC6d2jcQbQH9MaRQCRTZ/interact?entrypoint=default
this is the tx data from the temple wallet screen before sending the (failed) tx.

[
  {
    "destination": "KT18pA1mwpefkE2obC6d2jcQbQH9MaRQCRTZ",
    "kind": "transaction",
    "amount": 1,
    "parameters": {
      "entrypoint": "default",
      "value": "{\"int\":\"0\"}"
    }
  }
]

1. BCD shows "confirm network change" every time I try to interact with the rollupnet (most likely due to the "custom" alias)
2. BCD shows wrong link to the operation after deployment/interaction (see screenshot)
   

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/wallets/polygon-web-wallet/web-wallet-v2-guide.md

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/network-details/technical-requirements.md

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/network-details/technical-requirements.md

When a response is received from the wallet (success or abort), the "Request sent to wallet" toast is not dismissed.

The reason for this is most likely because the success/fail handlers were overwritten, which means the toast is never dismissed.

There are 2 ways to solve this:

1. You invoke the default handler in your handler, there is an example for this on this page: https://docs.walletbeacon.io/advanced/ui-elements

const dAppClient = new DAppClient({
  name: "Beacon Docs",
  eventHandlers: {
    [BeaconEvent.PAIR_INIT]: {
      // Every BeaconEvent can be overriden by passing a handler here.
      // The default will not be executed anymore. To keep the default,
      // you will have to call it again.
      handler: async (
        data: any,
        eventCallback?: any[] | undefined
      ): Promise<void> => {
        await defaultEventCallbacks.PAIR_INIT(data); // Add this if you want to keep the default behaviour.
        console.log("syncInfo", data, eventCallback);
      },
    },
  },
});

2. Instead of overwriting some events, you can leave the default events and subscribe to the events, which will not overwrite the default handlers: https://docs.walletbeacon.io/guides/subscribe-to-event

Hello,

First of all, I've been using your tool for not a very long time, and I'm very new to michelson, so this might not be an issue, but seems to me to be one.

Here is the problem:

I have a smartcontract deployed with the following entrypoint (updateOwner):

...
              (or (or (unit %unfreeze) (address %updateOwner))
...

When trying to interact with it using your tool, the tezos-client command generated is :

transfer 0 from tz1SPqTmARUfadFFBxRBTxZ76PVKjG6hzDj5 to KT1XP98t844HEaaSqZn9VMfJbA1vfd9Rwk5V --entrypoint 'updateOwner' --arg 'tz2ChZdsfpwgsKdx95SxgoCJWrFcpewA9BoQ'

When trying to run it using the client, this is the error message I get:

Invalid primitive: 1: tz2ChZdsfpwgsKdx95SxgoCJWrFcpewA9BoQ
Primitive tz2ChZdsfpwgsKdx95SxgoCJWrFcpewA9BoQ has invalid case.

Looking a bit at the previous output I got using other entrypoint, I tried to replace the commend with (encaspulating the --arg address in "):

transfer 0 from tz1SPqTmARUfadFFBxRBTxZ76PVKjG6hzDj5 to KT1XP98t844HEaaSqZn9VMfJbA1vfd9Rwk5V --entrypoint 'updateOwner' --arg '"tz2ChZdsfpwgsKdx95SxgoCJWrFcpewA9BoQ"'

And this one seems to work.

So, maybe you have forgotten to add the " in this usecase ?

Here is a link to the smartcontract I'm using, if it can help:

https://better-call.dev/carthagenet/KT1XP98t844HEaaSqZn9VMfJbA1vfd9Rwk5V/operations

anyway, thank you for your tool, it's saving me a lot of time.

Best regards

Just recently introduced in 32e78c3 src/components/schema/schemaForm/SchemaForm.vue line 177, that validation does not allow any more to enter a 0 in a nat type field.

But in some deployed smart contracts that would be needed, eg here (a youves contract):

where the dst_token_id is 0 (the token's ID is 0, the first one). But it can't be entered anymore.

I see plenty of other contracts using nat type fields for IDs, which can also be 0 in some cases (eg tokenIDs in FA2 tokens).

Best regards!

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/network-details/full-node-deployment.md

We often have situations while testing out contracts where we need to give token approvals. Eg. if we deploy a swap contract, we have to give the contract permissions to access the uUSD token.

This is possible using BCD at the moment, but it requires manual work because you have to open the uUSD contract and give the approval there.

It would be great if that process could be automated and there would be a checkbox or dropdown that would automatically give and remove token approvals.

We got a report from our user that his wallet balance is shown as zero after upgrade to Florence:
https://gitlab.com/camlcase-dev/dexter-frontend/-/issues/6

We traced it to zero balance in Better-call.dev

It does not apply to all wallets, not sure why.

Internal call stack doesn't follow DFS order like shown in this example.

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/wallets/polygon-web-wallet/web-wallet-v2-guide.md

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/network-details/technical-requirements.md

#486

If you only use the dark theme you can add the following to your ublock filters:

! 2021-01-04 https://better-call.dev
better-call.dev##body:style(background-color: #2d2d2d)

repro

1. https://better-call.dev/delphinet/KT1Ewcq3ZLKQ2gDP1QTkWYxe7DiKYFKqtX5E/code
2. press home & end buttons

An actual fix has to be done in the source itself to work with the white theme etc.

Better-call-dev uses string literals instead of bytes for bls12 values, causing the operation to fail.

Example contract

Produces:

{
  "prim": "Pair",
  "args": [
    {
      "string": "000000000000000000000000000000000000000000000000000000000000001"
    },
    {
      "string": "000000000000000000000000000000000000000000000000000000000000001"
    }
  ]
}

But should produce:

{
  "prim": "Pair",
  "args": [
    {
      "bytes": "000000000000000000000000000000000000000000000000000000000000001"
    },
    {
      "bytes": "000000000000000000000000000000000000000000000000000000000000001"
    }
  ]
}

lvaccaro/BitcoinBlockExplorer@fae3e03

https://github.com/maticnetwork/matic-docs/blob/master/docs/develop/network-details/technical-requirements.md

I just wanted to warn you about a current version of node-ipc containing https://github.com/RIAEvangelist/peacenotwar. You should probably pin your dependencies. It was classified as 9.8/10 severity by snyk.

You can read more about it here:
https://github.com/RIAEvangelist/node-ipc/issues/233
https://security.snyk.io/vuln/SNYK-JS-NODEIPC-2426370

Values of some types (e. g. timestamp, address) have two formats: "optimized" and "readable". It's documented here. Usually this distinction doesn't matter as the protocol code will convert to optimized by itself in most cases. However, if you do PUSH address inside smart contract code the difference will matter. It can be demonstrated by these two contracts:

• https://you.better-call.dev/carthagenet/KT1Smis81iJPURNe9GqoKfDVk2Z3Pxg18w6k/operations
• https://you.better-call.dev/carthagenet/KT1A1ffB22vRm5TSnUK7er9qLyyAWcKfonSp/operations

If you open their code, you won't see any difference. However, as the person who originated these contracts I know that one of them pushes an address in "optimized" format while the other one pushes it in "readable" format. If you look at the "Paid storage diff" values you will see the difference: 117 vs 131.

From the standpoint of a regular user it's very confusing to see that two smart contracts have identical code and initial storage (the storage type is unit) but different storage size. I think it's more correct to display constants in the same format as they were present in origination operations.

One may say that it's a bug in Tezos. I tend to agree, here is a relevant issue in tezos/tezos: https://gitlab.com/tezos/tezos/-/issues/843

Check out Bitcoin https://www.coingecko.com/coins/bitcoin

Issue:

When using Kukai Wallet with a contract that is on testnet, it doesn't work because it will open the mainnet deployment of Kukai. The testnet version of Kukai is located under a different URL.

Solution:

When instantiating the BeaconWallet client, you can pass in a preferredNetwork property. If this property is set, the correct URL of Kukai is selected. This is the only place where the preferredNetwork property is used, everything else stays the same.

The reason we had to do this is because the pairing alert is shown before the requestPermission is invoked, so we do not know which network the request will be on at the time of rendering the pairing alert.

There is an example here: https://docs.walletbeacon.io/guides/network#testnet

When going to "interact" and executing any contract call, a permission request is always sent before the actual request.

Steps to reproduce:

1. Open any contract (eg. https://better-call.dev/florencenet/KT1H3rsBQnMHfKKCKWVqqLg6k6eRDuFZ3NT6/interact?entrypoint=balance_of)
2. Go to "Interact", click "Execute" and "Wallet".
3. Select any wallet (eg. Spire)
4. Spire will pop up with a permission request. Accept it.
5. Operation request is sent to Spire. Cancel it.
6. Click "Execute" again and select "Spire".
7. Spire now pops up and shows the Permission Request again, which is not necessary. BCD can send the Operation Request directly in case permissions have been given earlier.

There is an example how you can check if permissions were already given and an active account is set: https://docs.walletbeacon.io/getting-started/simple-example