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
4 Likes
Great news!
I canât wait to see your solutions running on the KVM 
3 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?
1 Like
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
1 Like
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
2 Likes
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?
2 Likes
Certainly!
Could you please share the source code with me?
1 Like
sent via private message⌠Thanks
1 Like
@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
2 Likes
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.
4 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
Hey. Was there any update? Im getting error: thread âmainâ panicked at framework/meta/src/cargo_toml_contents.rs:27:53:
failed to open Cargo.toml file: Os { code: 2, kind: NotFound, message: âNo such file or directoryâ }
But the cargo.toml exists in meta, also its added to members in root cargo inside klever-vm-sdk folder.
Am i missing something?
2 Likes
I set up a new contract last night and got exactly the same error message as Bill. The other contract a few days ago worked perfectly.
2 Likes
Sooo.
I create a new âEmpty Contractâ and name it: âTESTSWAPâ. All uppercase.
This is what the empty contract looks like. The uppercase has become a lowercase.rs.
Then I try to build the empty contract.
Error:
main.rs TESTSWAP is in lowercase.
I change it in UPPERCASE and build the contract again.
Now i get an error in lib.rs
Its auto generated. I can change it but its useless.
Solution: Create an empty contract and use ONLY LOWERCASE. 
1 Like