-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
first steps #1
first steps #1
Conversation
- Set up data structures for token metadata - Introduce an abstraction for off-chain storage of a `MerkleMap` This allows us to do dependency injection, so that we can use an in-memory map for testing, and real-world implementations can use the solution that best fits their needs. - Implement the first method of the `SoulboundToken` smart contract: issuing a new token.
Revocation does not yet take the RevocationPolicy into account.
src/RevocationPolicy.ts
Outdated
/** When a token is issued, issuer and holder should agree on who can revoke the token */ | ||
class RevocationPolicy extends Struct ({ | ||
type: Field, | ||
}) { | ||
public static types = { | ||
// the issuer has the right to revoke tokens | ||
issuerOnly: Field(0), | ||
// only the holder of the token can revoke it | ||
holderOnly: Field(1), | ||
// a token can only be revoked if issuer and holder agree | ||
both: Field(2), | ||
// tokens are indestructible | ||
neither: Field(3), | ||
}; | ||
} | ||
|
||
export { RevocationPolicy }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's potentially two ways to use the RevocationPolicy
-
Instead of making this a
Struct
we can make it anotherMerkleMap
who's root is committed to the contract at deployment time and use aZkProgram
to attest to theRevocationPolicy
of the SBT. -
Alternatively, the
SmartContract
could have a state that defines theRevociationPolicy
(e.g. a hash or field) and a method check if the inputStruct
argument satisfies those constraints.
* part of the contract state. | ||
* | ||
*/ | ||
class SoulboundToken |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great!
This should fix the CI build step.
This makes the tests more succinct, and also allows us to keep the off-chain map in sync.
Also, tried to add a test that demonstrates that verifying a nonexistent token fails. However, the error that's raised within the smart contract does not get caught by the test, and the test fails (although running the test shows that the right thing happens).
6d14721
to
8d53f37
Compare
If we use the plain metadata, the same signed message that was used to issue a token will be sufficient to revoke it. We introduce a new type, `SoulboundRequest` that contains the metadata, as well as the request type (issuing or revoking a token).
681c146
to
8869f72
Compare
39736e5
to
cb3922f
Compare
This allows users to validate that a token has existed at a certain point, without needing to call the contract again.
I've put down a design of how the contract keeps track of the off- and on-chain state, and added a method for issuing tokens. Reocation and attestation will follow soon.