Siddharth Suresh
Siddharth Suresh
Resolves https://github.com/stellar/quickstart/issues/547 An example of the failure that this can result in can be seen here - https://github.com/sisuresh/docker-stellar-core-horizon/pull/1.
https://github.com/stellar/quickstart/blob/974fb36f9df9bf0f0600367cdcc6ec7e5d4fb453/start#L509 can fail due to bad values being set, but supervisor just catches the error and continues. We should fail on startup here.
After we remove BigInt from the examples, we should make sure the arithmetic is safe.
Related issue - https://github.com/stellar/rs-soroban-env/issues/634. During the hackathon, a couple users ran into issues where their contract hit an error in the token example, but the error didn't propagate up, making...
We should make the data model in examples more efficient. Related conversation in the liquidity pool example for more information - https://github.com/stellar/soroban-examples/pull/206#discussion_r1101928600.
Some contracts like timelock and the fuzzing example validate for negative values, and instead rely on the token implementation to fail. The problem is that the token interface accepts negative...
For example, core uses ecdsa 0.16.7, and env used 0.16.8. This was fine until the secp256 change, when soroban-env-host took a direct dependency on the ecdsa crate (among others that...
The bulk load path ignores the invariants enforced on regular loads. For example, a trustline for the issuer cannot exist, so it cannot be loaded, but core still allows you...
At the moment, `get-settings-upgrade-txs` gives you three transactions to submit - upload wasm tx, create contract tx, and invocation tx. If the contract has already been deployed in the past,...
https://github.com/stellar/quickstart/issues/456#issuecomment-1562996616 Looks like we've only seen this once so far.