-
Notifications
You must be signed in to change notification settings - Fork 1
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
Audit Meta #1
Comments
My notes, including user and protocol requirements: Design notes:Some high-level notes and assumptions about the protocol design based on the spec overview. s - concrete protocol instance. Quantity relations between entities:1 Token MP s Scripts relations:Token MP s Parametrized scripts:
User requirementsU0: I want to always be able to mint and burn existing tokensFollows:
U1: Have no restrictions that have no impact on safetyU2: I want that if amount of compromised signer keys is less or equal to a half, signers are remain in their powerThat actually follows from U3, so even if adversary have half of the keys, it can't change protocol state using only them, while signers can use compromised keys as well, having majority this way. U3: I want any one to be able to interact with the protocol iff having majority of signersU4: I don't want to have any unspendable funds on the protocol scripts
U5: I want any user to be able to freely burn their tokens of this protocolPreconditionsState thread is valid and ready
Protocol requirementsAll the protocol requirements MUST imply preconditions. P0: Every NFT token can ONLY be found at the only UpdateableAddresses validator at ANY moment of timeFollows from: U0 P1: The amount of signers MUST be oddFollows from: U1, U2, U3 P2: Protocol UTxOs MUST contain only necessary assets and datumBecause of common vilnerabilities:
Follows from U0 P3: UpdateableAddresses MUST only allow spending of it's NFT in a Tx with a strict majority of signaturesBecause of common vilnerabilities:
Follows from U3 P4: UTxO containing NFT token MUST have valid state thread datumBecause of common vilnerabilities:
Follows from U3, U0 Corresponding UpdateableAddresses validator MUST ensure that. P5: Token MP MUST only allow minting in a Tx with the corresponding NFT being spentBecause of common vilnerabilities:
Follows from U3, U0 P6: UpdateableAddresses MUST allow spending of any UTxO that does not contain NFTBecause of common vilnerabilities:
Follows from U1, U4 P7: Protocol behaviour MUST not change regardless of any protocol token name changeBecause of common vilnerabilities:
P8: Protocol MUST have correct arithmeticBecause of common vilnerabilities:
Follows from U0 P9: Protocol MUST not halt or staleFollows from U0 P10: multiple-satisfaction is not possibleBecause of common vilnerabilities:
It should not be possible, because:
P11: Burning tokens MUST not be constrainedP12: Burning tokens MUST not interfere with protocol state thread updateSo it should not be possible to burn tokens and put a lot of trash tokens into a state thread UTxO in the same Tx. Covered by P2, but just in case. Because of common vilnerabilities:
TODO: consider staking credentials |
look for problems with:
requirementstoken scripts
NFT
UpgradeableOwnersUser
Protocol
|
Goal:To mint tokens safely and allow holders of these tokens to burn them freely. Requirements:
Questions:What if the same public key hash is used more than once in the datum? Depending on the implementation, this could be a problem. |
User actions
|
SingularityNet UpgradeableOwners Protocol Audit
Validators
Vulnerabilities
The text was updated successfully, but these errors were encountered: