Not able to make a payout to KT1 address

[JigneshVasoya3292]

Describe the bug TRD fails to transfer reward amounts to KT1 address.

To Reproduce Steps to reproduce the behavior:

1. Delegate smart contract balance to a bakery (KT1 address) You can use http://smartpy.io/dev to deploy a smart contarct with delegate address with enough XTZ balance
2. Configure TRD with required configuration.
3. It's expected to make a payout to KT1 address but it fails with gas_fee_exhaustion error

Even with the higher fees, tx fails.

Expected behavior TRD should be able to make payout to all KT1 and tz1 addresses.

Screenshots If applicable, add screenshots to help explain your problem.

Environment

• Source Code Build or Docker : Source code

• Attached configuration : fee.ini : fee.txt config.yaml : tz1QgArbnGonQgZXqY3bLFwC93BUCicodfPX.txt app.log : app.log Failed tx : https://carthage.tzkt.io/op9CESrq6LLuypXojPwoPSk3ZiVp6cdB9yg8pGLJTTuXGPxsdnJ

• Chain mainnet, zeronet, alphanet : carthagenet (alphanet)

• actual command used : python3 src/main.py -N ALPHANET -C 316 -V

• Operating system / system specification : Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic

Additional context Add any other context about the problem here.

[utdrmac]

Getting "Operation Does Not Exist" https://carthage.tzkt.io/op9CESrq6LLuypXojPwoPSk3ZiVp6cdB9yg8pGLJTTuXGPxsdnJ I see in your app.log that your txn fee and storage fee are defaults. Have you attempted to increase these? Gas is only about executing the code. But as you store more information inside the contract, you need to allocate more storage and pay higher fee for the increase in bytes.

[JigneshVasoya3292]

Yes, I have tried with increased fees as well. I think the problem is on the contract end. It has multiple entrypoints and hence calling default entrypoint is failing.

[utdrmac]

@JigneshVasoya3292 Yes, this is essentially a "known issue" with contracts. See this conversation regarding the native multisig contract. Unless the contract's default entrypoint allows for transfers in, then it won't work. Have you tried transferring to this KT1 using the command-line client? Does that work?

I don't think this is something TRD would support unless a standard is created. TRD can't possibly account for different entrypoints by smart contracts.

[amzid]

I tried to transfer to the contract using the tezos client and it does not work either without specifying an entry point (https://carthage.tzkt.io/KT1BcHbiYhrew8jsWBc6w69QoKNYZtcNXY69/entrypoints). A work around would be to add a contracts map to the baking config where the desired entry point can be specified?

[utdrmac]

@amzid Doing a map would put 100% responsibility/burden on the baker. Imagine a bakery with 50 KT1s, all with different entry points. It would take a lot of time and effort for the baker to investigate each KT1 and figure out which entry point needs to be mapped.

I don't think this is something that needs to be done within TRD. Much like the issue with the multisig, in my opinion, it is the contract itself that needs to be modified to accept incoming txn on the default/empty entrypoint.

[jdsika]

I would say that giving the possibility to have such a map and note the concerns in the docu is the way to go in order to overcome this issue. We should leave a blocking issue explaining the todo and problem with multiple entry points.