pushing changes

Cargo.toml

@@ -26,6 +26,9 @@ members = [
   "contracts/liquidity_book/lb_staking",
   "contracts/liquidity_book/tests",
 
+  "contracts/galactic_pools/pools/native",
+
+
   # Staking
   #"contracts/basic_staking",
   #"contracts/snip20_derivative",

contracts/galactic_pools/exp/.editorconfig

@@ -0,0 +1,11 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.rs]
+indent_size = 4

contracts/galactic_pools/exp/.gitignore

@@ -0,0 +1,17 @@
+# Build results
+/target
+Cargo.lock
+contract.wasm*
+
+# Cargo+Git helper file (https://github.com/rust-lang/cargo/blob/0.44.1/src/cargo/sources/git/utils.rs#L320-L327)
+.cargo-ok
+
+# Text file backups
+**/*.rs.bk
+
+# macOS
+.DS_Store
+
+# IDEs
+*.iml
+.idea

contracts/galactic_pools/exp/Cargo.toml

@@ -0,0 +1,55 @@
+[package]
+name = "experience_contract"
+version = "1.0.0"
+authors = ["Lumi - Trivium","Haseeb Saeed"]
+edition = "2021"
+
+exclude = [
+  # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication.
+  "contract.wasm",
+  "hash.txt",
+]
+
+# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
+
+[lib]
+crate-type = ["cdylib", "rlib"]
+
+[profile.release]
+opt-level = 3
+debug = false
+rpath = false
+lto = true
+debug-assertions = false
+codegen-units = 1
+panic = 'abort'
+incremental = false
+overflow-checks = true
+
+[features]
+default = []
+# for quicker tests, cargo test --lib
+# for more explicit tests, cargo test --features=backtraces
+#backtraces = ["cosmwasm-std/backtraces"]
+#debug-print = ["cosmwasm-std/debug-print"]
+
+[dependencies]
+snafu = { version = "0.6.3" }
+serde = { version = "1.0.103", default-features = false, features = ["derive"] }
+schemars = "0.8.8"
+shade-protocol = { version = "0.1.0", path = "./../../../packages/shade_protocol" }
+
+thiserror = { version = "1.0.31" }
+
+rand_chacha = { version = "0.2.2", default-features = false }
+#rand_core = { version =  "0.5.1", default-features = false }
+rand = { version = "0.7.3" }
+sha2 = { version = "0.9.1", default-features = false }
+[dev-dependencies]
+cosmwasm-schema = { git = "https://github.com/scrtlabs/cosmwasm/", branch = "secret" }
+shade-multi-test = { path = "./../../../packages/multi_test", features = [ 
+  "admin",
+  "lb_pair",
+  "lb_token",
+  "snip20",
+] }

contracts/galactic_pools/exp/Developing.md

@@ -0,0 +1,142 @@
+# Developing
+
+If you have recently created a contract with this template, you probably could use some
+help on how to build and test the contract, as well as prepare it for production. This
+file attempts to provide a brief overview, assuming you have installed a recent
+version of Rust already (eg. 1.41+).
+
+## Prerequisites
+
+Before starting, make sure you have [rustup](https://rustup.rs/) along with a
+recent `rustc` and `cargo` version installed. Currently, we are testing on 1.41+.
+
+And you need to have the `wasm32-unknown-unknown` target installed as well.
+
+You can check that via:
+
+```sh
+rustc --version
+cargo --version
+rustup target list --installed
+# if wasm32 is not listed above, run this
+rustup target add wasm32-unknown-unknown
+```
+
+## Compiling and running tests
+
+Now that you created your custom contract, make sure you can compile and run it before
+making any changes. Go into the
+
+```sh
+# this will produce a wasm build in ./target/wasm32-unknown-unknown/release/YOUR_NAME_HERE.wasm
+cargo wasm
+
+# this runs unit tests with helpful backtraces
+RUST_BACKTRACE=1 cargo unit-test
+
+# this runs integration tests with cranelift backend (uses rust stable)
+cargo integration-test
+
+# this runs integration tests with singlepass backend (needs rust nightly)
+cargo integration-test --no-default-features --features singlepass
+
+# auto-generate json schema
+cargo schema
+```
+
+The wasmer engine, embedded in `cosmwasm-vm` supports multiple backends:
+singlepass and cranelift. Singlepass has fast compile times and slower run times,
+and supportes gas metering. It also requires rust `nightly`. This is used as default
+when embedding `cosmwasm-vm` in `go-cosmwasm` and is needed to use if you want to
+check the gas usage.
+
+However, when just building contacts, if you don't want to worry about installing
+two rust toolchains, you can run all tests with cranelift. The integration tests
+may take a small bit longer, but the results will be the same. The only difference
+is that you can not check gas usage here, so if you wish to optimize gas, you must
+switch to nightly and run with cranelift.
+
+### Understanding the tests
+
+The main code is in `src/contract.rs` and the unit tests there run in pure rust,
+which makes them very quick to execute and give nice output on failures, especially
+if you do `RUST_BACKTRACE=1 cargo unit-test`.
+
+However, we don't just want to test the logic rust, but also the compiled Wasm artifact
+inside a VM. You can look in `tests/integration.rs` to see some examples there. They
+load the Wasm binary into the vm and call the contract externally. Effort has been
+made that the syntax is very similar to the calls in the native rust contract and
+quite easy to code. In fact, usually you can just copy a few unit tests and modify
+a few lines to make an integration test (this should get even easier in a future release).
+
+To run the latest integration tests, you need to explicitely rebuild the Wasm file with
+`cargo wasm` and then run `cargo integration-test`.
+
+We consider testing critical for anything on a blockchain, and recommend to always keep
+the tests up to date. While doing active development, it is often simplest to disable
+the integration tests completely and iterate rapidly on the code in `contract.rs`,
+both the logic and the tests. Once the code is finalized, you can copy over some unit
+tests into the integration.rs and make the needed changes. This ensures the compiled
+Wasm also behaves as desired in the real system.
+
+## Generating JSON Schema
+
+While the Wasm calls (`init`, `handle`, `query`) accept JSON, this is not enough
+information to use it. We need to expose the schema for the expected messages to the
+clients. You can generate this schema by calling `cargo schema`, which will output
+4 files in `./schema`, corresponding to the 3 message types the contract accepts,
+as well as the internal `State`.
+
+These files are in standard json-schema format, which should be usable by various
+client side tools, either to auto-generate codecs, or just to validate incoming
+json wrt. the defined schema.
+
+## Preparing the Wasm bytecode for production
+
+Before we upload it to a chain, we need to ensure the smallest output size possible,
+as this will be included in the body of a transaction. We also want to have a
+reproducible build process, so third parties can verify that the uploaded Wasm
+code did indeed come from the claimed rust code.
+
+To solve both these issues, we have produced `rust-optimizer`, a docker image to
+produce an extremely small build output in a consistent manner. The suggest way
+to run it is this:
+
+```sh
+docker run --rm -v "$$(pwd)":/contract \
+    --mount type=volume,source="$$(basename "$$(pwd)")_cache",target=/contract/target \
+    --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
+    enigmampc/secret-contract-optimizer:1.0.3
+```
+
+We must mount the contract code to `/contract`. You can use an absolute path instead
+of `$(pwd)` if you don't want to `cd` to the directory first. The other two
+volumes are nice for speedup. Mounting `/contract/target` in particular is useful
+to avoid docker overwriting your local dev files with root permissions.
+Note the `/contract/target` cache is unique for each contract being compiled to limit
+interference, while the registry cache is global.
+
+This is rather slow compared to local compilations, especially the first compile
+of a given contract. The use of the two volume caches is very useful to speed up
+following compiles of the same contract.
+
+This produces a `contract.wasm` file in the current directory (which must be the root
+directory of your rust project, the one with `Cargo.toml` inside). As well as
+`hash.txt` containing the Sha256 hash of `contract.wasm`, and it will rebuild
+your schema files as well.
+
+### Testing production build
+
+Once we have this compressed `contract.wasm`, we may want to ensure it is actually
+doing everything it is supposed to (as it is about 4% of the original size).
+If you update the "WASM" line in `tests/integration.rs`, it will run the integration
+steps on the optimized build, not just the normal build. I have never seen a different
+behavior, but it is nice to verify sometimes.
+
+```rust
+static WASM: &[u8] = include_bytes!("../contract.wasm");
+```
+
+Note that this is the same (deterministic) code you will be uploading to
+a blockchain to test it out, as we need to shrink the size and produce a
+clear mapping from wasm hash back to the source code.

contracts/galactic_pools/exp/Importing.md

@@ -0,0 +1,62 @@
+# Importing
+
+In [Publishing](./Publishing.md), we discussed how you can publish your contract to the world.
+This looks at the flip-side, how can you use someone else's contract (which is the same
+question as how they will use your contract). Let's go through the various stages.
+
+## Verifying Artifacts
+
+Before using remote code, you most certainly want to verify it is honest.
+
+The simplest audit of the repo is to simply check that the artifacts in the repo
+are correct. This involves recompiling the claimed source with the claimed builder
+and validating that the locally compiled code (hash) matches the code hash that was
+uploaded. This will verify that the source code is the correct preimage. Which allows
+one to audit the original (Rust) source code, rather than looking at wasm bytecode.
+
+We have a script to do this automatic verification steps that can
+easily be run by many individuals. Please check out
+[`cosmwasm-verify`](https://github.com/CosmWasm/cosmwasm-verify/blob/master/README.md)
+to see a simple shell script that does all these steps and easily allows you to verify
+any uploaded contract.
+
+## Reviewing
+
+Once you have done the quick programatic checks, it is good to give at least a quick
+look through the code. A glance at `examples/schema.rs` to make sure it is outputing
+all relevant structs from `contract.rs`, and also ensure `src/lib.rs` is just the
+default wrapper (nothing funny going on there). After this point, we can dive into
+the contract code itself. Check the flows for the handle methods, any invariants and
+permission checks that should be there, and a reasonable data storage format.
+
+You can dig into the contract as far as you want, but it is important to make sure there
+are no obvious backdoors at least.
+
+## Decentralized Verification
+
+It's not very practical to do a deep code review on every dependency you want to use,
+which is a big reason for the popularity of code audits in the blockchain world. We trust
+some experts review in lieu of doing the work ourselves. But wouldn't it be nice to do this
+in a decentralized manner and peer-review each other's contracts? Bringing in deeper domain
+knowledge and saving fees.
+
+Luckily, there is an amazing project called [crev](https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/README.md)
+that provides `A cryptographically verifiable code review system for the cargo (Rust) package manager`.
+
+I highly recommend that CosmWasm contract developers get set up with this. At minimum, we
+can all add a review on a package that programmatically checked out that the json schemas
+and wasm bytecode do match the code, and publish our claim, so we don't all rely on some
+central server to say it validated this. As we go on, we can add deeper reviews on standard
+packages.
+
+If you want to use `cargo-crev`, please follow their
+[getting started guide](https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/src/doc/getting_started.md)
+and once you have made your own *proof repository* with at least one *trust proof*,
+please make a PR to the [`cawesome-wasm`]() repo with a link to your repo and
+some public name or pseudonym that people know you by. This allows people who trust you
+to also reuse your proofs.
+
+There is a [standard list of proof repos](https://github.com/crev-dev/cargo-crev/wiki/List-of-Proof-Repositories)
+with some strong rust developers in there. This may cover dependencies like `serde` and `snafu`
+but will not hit any CosmWasm-related modules, so we look to bootstrap a very focused
+review community.