jonjove

I don't believe this has been resolved yet. Since this issue was opened many new operations have been added, notably in the upcoming Protocol 14. Is there any plan to...

@paulbellamy and I have been investigating the “right” way to solve this problem. At this point we have reached the conclusion that it is impossible for the effects to satisfy...

A prototype operation can be found here https://github.com/stellar/rs-stellar-xdr/blob/main/xdr/next/Stellar-transaction.x#L69 with the additional restriction that if you use this it must be the only operation in the transaction (not the only kind...

This is caused by the additional `Frame::HostFunction` that is generated by `Host::invoke_function`. The x86-test builds don't go through this call path because it was designed for usage from stellar-core. It...

Tangentially related to https://github.com/stellar/rs-soroban-env/issues/150 since removing `Frame::HostFunction` would resolve that issue.

Backlog it, it's purely about code quality and is not observable to users.

Not really, there are just some places where a clone was made but you could have just moved. For example, https://github.com/stellar/soroban-token-contract/blob/44127bca3ee1dcf3d8107db6fa60077e7ec3dff8/src/metadata.rs#L14-L17 I've also wondered about making everything `Copy`, and think...

This is already done in the built-in token contract but is not done in the example token contract.

Just updated this in a variety of ways: - Changed the `sigs` parameter from `Map` to `Map` - Changed the `payload` return value to `Map` (ignore the weird name, it's...

Added the missing pieces described above and fixed a couple of bugs. A wallet or other downstream system would use this as follows: 1. Wallet receives request to call `Contract::f(x,...