Description

Hypotheses

1. A.1) As a user, I can grant vesting to an arbitrary number of PubkeyHash(es) by locking Ada or any other native token in the vesting contract .

• #11
• #13
• #6

3. A.2) We as beneficiaries can unlock Ada or any other native token locked in a vesting contract once the specific deadline has passed.

• #11
• #6

5. A.3) We as beneficiaries as only unlock the value locked into the vesting contract if and only if the following conditions satisfies:
   a) Majority of the beneficiaries signs the transaction.
   b) The deadline of the vesting schedule has passed.

• #6
• #18
• #19

6. A.4) We as beneficiaries can only unlock value for which the deadline has passed, the remaining value stays locked in the vesting contract.

• #18

7. A.5) We as beneficiaries can update the group of beneficiaries i.e. PubkeyHash(es) of the vesting contract if the majority of the existing beneficiaries signs the transaction.

• #13
• #6

8. A.6) We as beneficiaries can unlock all the value from the vesting contract if and only if all the deadlines has been passed.

MLabs inspected the onchain and offchain code of the JPG Vesting Contract over a three week period and discovered two vulnerabilities and four recommendations. Additionally, MLabs has provided a testing framework and tests written to verify the claims made in the report (available on GitHub). This list is not exhaustive, as the team only had a limited amount of time to conduct the audit.

Description

• Analyse the offchain contracts for suspicious behaviour.

  • Off-chain code of the vesting contract consists mainly of shell scripts, and these scripts provide very little flexibility to make and unlock vesting.
  • For Eg: There's no way to unlock a vesting contract that has number of beneficiaries >= 4. This is because unlock script expects only 2 signing key as input.

• Test the offchain shell scripts against the plutip cluster. #7

Conclusion

We could not conclude all the required tests prior to the end of audit, but a partial auditing of the offchain has not revealed any vulnerabilities. With this being said, some hypothesis remain untested, therefore we cannot make a clear statement on the non-existence of vulnerabilities in the offchain code.

The Audit revealed the following two Medium Severity vulnerabilities:

• #12 of type unbounded-protocol-datum,

• #23 of type incorrect-logic.

Furthermore, the audit puts forward the following optimisations / recommendations:

• #4

• #5

• #14

Please note that as described in #10, only a partial audit of the offchain code was undertaken - not revealing any vulnerabilities.

For report brevity (and clarity), the testing framework and associated PRs will be mentioned here, and not included in the Audit Report. For in-depth explanation about what each PR is aiming to prove, please refer to the linked ticket description on GitHub.

Therefore, we would first mention the tickets outlining the hypotheses that the tests were trying to prove/disprove:

• #9,
• #10.

Secondly, we would like to mention the PRs proposing the tests to be integrated into the main repository.

• #19,
• #18,
• #17,
• #16,
• #13,
• #11,
• #6.

We recommend for the aforementioned tests to be included in the main branch and made visible in the CI.

Description

In the current version, we have to iterate the Portion list multiple times to calculate the total unvested value:

1. Filter the unvested Portion from the given Schedule
2. Iterate again to get amount from the filtered Portion
3. Iterate again to concat all the Value(s) present in the list.

unvested :: Value
unvested = mconcat . fmap amount . filter (not . isVested) . schedule $ datum

The same thing can be accomplished using foldr which only requires a single iteration of the list.

unvested :: Value
unvested = foldr (\ !portion !totalAmt -> 
                    if isVested portion 
                    then totalAmt
                    else mappend (amount portion) totalAmt
                 ) mempty 
         . schedule $ datum

Scope

During the audit, MLabs Audit Team (from now on referred to as MLabs) have used the provided files for the following scope:

• A. Audit the onchain contract

• A.1. Integrate testing frameworks (Plutip and PSM) to allow reproducible testing of hypotheses.

• A.2. Write tests to prove the well functioning of the on-chain components.

• B. Audit of the offchain components

• B.1. Test the well functioning of the provided shell scripts.

• B.2. Audit the shell scripts for any malicious or not intended behaviour.

Please note that point B.1. is not marked as finished due to it being partially explored. For more information please refer to #10.

Methodology

Timeline

In response to the above scope, the Audit process took three (one week) sprints and it can be summarised to the following actions:

1. Review and test the onchain/offchain components against the MLabs Vulnerability types.

2. Write test scenarios for the implementations, and run some of them against a Cardano node (via Plutip).

3. Find optimisations, code quality improvements, or recommendations.

4. Capture the findings in an Audit Report.

Information

MLabs analysed the validators and minting scripts from the github.com/jpg-store/vesting-contract repository starting at commit 703566b.

Audited Files Checksums

The following checksums are those of files captured by commit 703566b, and were generated using the following sha256 binary:

$ sha256sum --version
sha256sum (GNU coreutils) 9.0

The checksums are:

34ed...a6a6  app/Main.hs
6ef0...aa6c  src/Canonical/Shared.hs
ee50...1886  src/Canonical/DebugUtilities.h
add6...b689  src/Canonical/Vesting.hs

INCLUDE CheckSum

Audit Report

The audit report is an aggregation of issue, tickets and pull-requests created in the jpg-store/vesting-contract repository.

Metrics

CVSS

To leverage a standardised metric for the severity of the open standard Common Vulnerability Scoring System, together with the NVD Calculator. The metrics from the mentioned tools were included with each vulnerability. MLabs recognises that some of the parameters are not conclusive for the protocol - but considers that leveraging such a standard is still valuable to offer a more unbiased severity metric for the found vulnerabilities.

Severity Levels

The aforementioned CVSS calculations were then benchmarked using the CVSS-Scale metric, receiving a grade spanning from Low to Critical. This additional metric allows for an easier, human understandable grading, whilst leveraging the CVSS standardised format.

Description

Vesting contract uses Action type as it's redeemer, this type has a single data constructor which is named Disburse whose type is Disbure :: [PubKeyHash] -> Action. We think that this name is misleading as the role of this redeemer is not only to disburse the value locked in the contract when the deadline has passed but also to update the current beneficiaries of the Input datum. Hence, we think the option of updating beneficiaries should also be highlighted in the name of Action type's data constructor.