scrtlabs / secret-toolkit Goto Github PK
View Code? Open in Web Editor NEWA collection of Rust packages that contain common tools used in development of Secret Contracts
License: GNU Affero General Public License v3.0
A collection of Rust packages that contain common tools used in development of Secret Contracts
License: GNU Affero General Public License v3.0
I ran into this issue because I was trying to unit test my own functions which rely on secp256k1. It looks like the sign and verify functions need deps.api
to be given as input. But even after I gave it as input it still fails during runtime because the mock version of dependencies spits out an empty array when you sign something which secp256k1 doesn't like at all. Is there any workaround for this? Or a simple fix?
Implementation of common actions an admin can do in a contract:
Ideally this would also implement the underlying action of these messages - e.g. encapsulate saving to storage, etc..
secp256k1 depends on secp256k1-sys
a c wrapper. It has caused me build issues like having to update clang on my mac as well as being incompatible with rust-optimizer. Is there any reason to not use a pure rust implementation like k256
? Plus it would be one less dependency since k256
is already a dependency of secret-cosmwasm-crypto
it would be great if the snip-20 package supported queries with permits as defined in snip-24
Provide a safe integer type for messing with tokens (prevent overflows, negatives, etc..)
Secret-toolkit's(Branch = cosmwasm-v1.0) revoke-permit functions panics because apparently, you cannot store an empty value in the storage.
Here's the revoke_permit function that is trying to store an empty value.
Cw-0.10 doesn't have this condition before. Seems like it was added after version 0.10. This check here is causing this error.
I suggest we store permit name or any random value to avoid this error.
We can move permit validation to a service outside the contracts - should improve performance and gas usage, which will help standardize and prevent mistakes
The current implementation of the snip20
and snip721
modules fails to parse the query response if it was an error.
This isn't great. The library should know how to handle those cases. This came up while playing around with queries that require a VK, and providing the wrong VK.
See secretSCRT for reference
Would be useful to have implementation of:
This is a great reference for this
This would lower the learning curve around writing contracts that use SNIP-20 tokens and save some code lines ๐
When add_attribute_plaintext
is called on a Response, it adds an Attribute with encrypted: false
:
https://github.com/scrtlabs/cosmwasm/blob/6c639b5a85ef66f87d72284dc68ae051eab09007/packages/std/src/results/response.rs#L112-L122
but when pad_handle_result
is called on the Response, it pads all attributes (both plaintext and encrypted), causing problems for plaintext ones since a bunch of spaces are appended to the plaintext attribute key, preventing clients from accessing the key in the response JSON (without resorting to matching by pattern - which is obviously not desired nor intended).
secret-toolkit/packages/utils/src/padding.rs
Lines 32 to 37 in 95428dd
Extend the methods available under secret_toolkit::snip20
to also include the new interface specified in:
SNIP-21, SNIP-22, and SNIP-23.
Alternatively, implement new modules called snip21
, snip22
, and snip23
which include versions of the modified interfaces that are aware of the new features, as well as support for the new message types.
NOTE: at the time of writing SNIP-23 is not finalized yet so it's a lower priority.
We ended up including all new SNIP-2x functionality in the snip20 module. As far as I'm concerned we can still reshuffle this as discussed in this thread and release a new version, but for now let's experiment with it and see what feedback we get.
Example:
A very common way to answer a handle message is simply { "status": "success" }
or { "status": "failure" }
.
Every time we do that we have to write something along the lines of:
Ok(HandleResponse {
messages,
log: vec![],
data: Some(to_binary(&HandleAnswer::Send { status: Success })?),
})
For this we of course have to declare:
#[derive(Serialize, Deserialize, Clone, PartialEq, JsonSchema, Debug)]
#[serde(rename_all = "snake_case")]
pub enum ResponseStatus {
Success,
Failure,
}
#[derive(Serialize, Deserialize, JsonSchema, Debug)]
#[serde(rename_all = "snake_case")]
pub enum HandleAnswer {
Send {
status: ResponseStatus,
},
...
}
This is a lot of code and it's kind of annoying.
We should provide a standard implementation for common use cases that coders can use as a one-liner.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.