@meshsdk/contract 1.9.0-beta.2 → 1.9.0-beta.20
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +29 -0
- package/dist/index.cjs +27635 -31777
- package/dist/index.d.cts +3 -3
- package/dist/index.d.ts +3 -3
- package/dist/index.js +27963 -32105
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -15,3 +15,32 @@ Here's a list of open-source smart contracts, complete with documentation, live
|
|
|
15
15
|
| Payment Splitter | Allows users to split incoming payments among a group of accounts | [[demo](https://meshjs.dev/smart-contracts/payment-splitter)] [[source](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/payment-splitter)] [[docs](https://docs.meshjs.dev/contracts/classes/MeshPaymentSplitterContract)] |
|
|
16
16
|
| Swap | Facilitates the exchange of assets between two parties | [[demo](https://meshjs.dev/smart-contracts/swap)] [[source](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/swap)] [[docs](https://docs.meshjs.dev/contracts/classes/MeshSwapContract)] |
|
|
17
17
|
| Vesting | Allows users to lock tokens for a period of time and withdraw the funds after the lockup period | [[demo](https://meshjs.dev/smart-contracts/vesting)] [[source](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/vesting)] [[docs](https://docs.meshjs.dev/contracts/classes/MeshVestingContract)] |
|
|
18
|
+
|
|
19
|
+
# List of 'Bad' Contracts
|
|
20
|
+
|
|
21
|
+
This helps developers to better understand how smart contracts work and improves their ability to fix bad contracts.
|
|
22
|
+
|
|
23
|
+
## [Unbound value](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/escrow/unbound-value)
|
|
24
|
+
|
|
25
|
+
Unbound value is a vulnerability where the hackers can spam the application by providing excessive unnecessary tokens in a validator, causing permanent lock of value in validator due to protocol limitation of execution units. In the escrow example, we did not specificallly guard this scenario since it did not make economical sense for both initiator and recipient to perform such hack. However, it other application or scenario it may be required to specifically check the length of input / output to prevent such hack from happening.
|
|
26
|
+
|
|
27
|
+
## [Infinite mint](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/giftcard/infinite-mint)
|
|
28
|
+
|
|
29
|
+
Infinite mint is a vulnerability where there is no strict restriction on minting a particular policy where malicious players can mint more than desired tokens from one transaction. Normally it comes from when the validator checks against whether a particular token has been minted without strictly prohibiting other tokens from minting. This vulnerability is dangerous when a complex application relies on certain policy ID for authentication, while malicious players can produce uncontrolled circulation of token with that policy ID, leading to complex hacking scenarios causing loss of funds.
|
|
30
|
+
|
|
31
|
+
## [Insufficient stake control](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/marketplace/insufficient-stake-control)
|
|
32
|
+
|
|
33
|
+
Insufficient stake control is a vulnerability where the value payment only check against payment key but not checking with a full address. Malicious player can fulfill the validator unlocking logic by sending value to an address with his/her own stake key to steal the staking reward and voting power if the user is not aware of that.
|
|
34
|
+
|
|
35
|
+
## [Locked value](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/plutus-nft/locked-value)
|
|
36
|
+
|
|
37
|
+
Locked value is a design where the application would cause permanent lock of value alike burning value permenantly. It will cause loss of fund and value circulation. However, in some scenarios it might be a intented behaviour to produce umtamperable utxos to serve as single proven source of truth for DApps. One should consider the economics and tradeoff against the design choice. In the plutus nft example, locked value vulnerability is not considered as severe since only around 2 ADA would be permenantly lock in oracle.
|
|
38
|
+
|
|
39
|
+
## [Double satisfaction](https://github.com/MeshJS/mesh/tree/main/packages/mesh-contract/src/swap/double-satisfaction)
|
|
40
|
+
|
|
41
|
+
This is a vulnerability where a bad actor can unlock multiple script utxos by fulfilling less than intented criteria. This swap example illustrate this vulnerability by not checking there is only 1 script input. It leads to bad actors can extract more value than it was expected from the protocol.
|
|
42
|
+
|
|
43
|
+
### Resources
|
|
44
|
+
|
|
45
|
+
- [Workshop #1 video recording](https://www.youtube.com/watch?v=JgIhzix7rMo)
|
|
46
|
+
- [Workshop #1 video recording](https://www.youtube.com/watch?v=IQoN6yL3z1A)
|