I can also confirm the functionality on the Mac 
As Marco already wrote, one or the other package had to be added, then the creation and deployment worked smoothly.
Thanks for the quick update
3 Likes
Great news!
I canāt wait to see your solutions running on the KVM 
2 Likes
Hey @Duka @Nicollas
if we test the smart contracts and the transaction fails, the result code shows VMUserError but in the Raw Tx then VMOutOfGas.
Is this a problem on the part of our test contract or a problem of the VM as described in the Raw Tx?
VMUserError is the most generic error of the VM, in generic scenarios like this, the RawTX is your friend to tell exactly what happened.
In this case, it is in fact a out of gas error.
VMOutOfGas error is a problem with the test contract. Common cases include recursive functions, loops, large iterations, excessive storage read/write operations.
If you believe that your contract does not have a reason to do that, you can share the code with me and i will be glad to help
ok, great. thanks for the quick reply.
Iām still testing it, it doesnāt always occur.
But this is just a test contract anyway to familiarize myself a little 
Thanks a lot
1 Like
hey @Nicollas
We have now created our actual smart contract.
This also works as long as the player does not win! 
If he wins I will receive the OutOfGas message as before!
We donāt use any loops or anything like that to drive up the gas.
here is another transaction link (failed):
would you look over it again?
1 Like
Certainly!
Could you please share the source code with me?
sent via private messageā¦ Thanks
@Duka @Nicollas short question about the sdk and the required callValue which should be passed as dictionary <string,long>.
Does it take the key as the asset?
i.e. āKLVā : 100
I actually assumed that I have to use āassetā and āvalueā as keys and āKLVā and 100 as value!
But this is not possible with dictionary <string,long> or?
And with āKLVā : 100 I get the following error message:
APIException: Error when calling API : validation error: could not extract asset from callValue: bad_request
1 Like
Iām still investigating this on my end, and Iāll have an answer for you today. I was already able to reproduce the error.
Regarding the SDK, which one are you using? Could you provide the link? Iād be happy to look into it for you.
3 Likes
perfect, thanks
i use the Klever unity sdk in the current version 0.0.7
Hello Andreas,
Iāve completed my investigation.
The cause is simpleāyour random calculation is just too good! Hahaha.
Let me explain what I mean:
The default behavior of KleverChain (for any transaction, IDE or not) is to first simulate the transaction execution to calculate gas consumption. Then, it uses the estimated gas to execute everything.
Your highly sensitive random algorithm causes the behavior to change each time. During simulation, the contract behaves one way (Behavior X), but during actual execution, it behaves differently (Behavior Y).
Regarding your contract, here are some possible scenarios:
- User loses in simulation but wins in actual execution: Not enough gas is available to execute the unexpected transfer.
- User wins in simulation but loses in actual execution: The transaction succeeds, but some gas is left over since the transfer wasnāt executed.
- User has the same result in both simulation and actual execution: The transaction succeeds, but no gas is left over.
The issue here lies in the randomness, which generates unpredictable behaviors.
Can this be fixed in the code?
At the moment, I donāt see a reliable way to address this issue purely in the code. I experimented with less sensitive random generation, but the problem persistsāit just becomes rarer.
If you manage to create a predictable random generator (ensuring consistency between simulation and execution), thereās a high risk that an attacker could exploit this predictability. They could simulate transactions to identify only the ones where they win and then execute those selectively.
How can this issue be resolved?
The most reliable solution lies outside the blockchain, in your application layer.
My recommendation is to manually build the transaction and set a fixed gas limit for your contract execution. This way, you can account for a potential KDA transfer. If the transfer happens, great; if not, itās still fine. The fixed gas limit ensures stability regardless of the randomness in your contract.
Let me know if youād like further clarification or assistance with this.
3 Likes
About the SDK question:
Youāre right, our documentation currently doesnāt include an example for call values. Iāll take care of that.
Iāll confirm how to use it, update the documentation accordingly, and, of course, reply here with the details.
3 Likes
hey @Nicollas
is there anything new regarding the callValue in the sdk?
It is currently not possible to send a certain amount in KLV to the contract via the SmartContract function.
but this is necessary for our contract
Yes!
We released a new version of the SDK fixing the issue
great, will try it out tomorrow morning!
1 Like