Fix for Borsh version 0.7.0 to fix SAS Attestation decode

[andrey-lizunov]

Description

We had an issue with SAS Attestation decode using Borsh 0.7.0.
This PR fixes it using Borsh 2.0.0 and existing methods for SAS Schema conversion to Borsh schema.
Seems that we should remove previous implementation for Borsh 0.7.0 or mark it as deprecated.

Type of change

• Bug fix
• New feature
• Protocol integration
• Documentation update
• Other (please describe):

Screenshots

Testing

Link to broken Attestation example:
https://explorer.solana.com/address/4qNvYnG85MWaBmDu56GXfg22gR1GyuhDPHbjUGoz2Hm3/attestation

Related Issues

Checklist

• My code follows the project's style guidelines
• I have added tests that prove my fix/feature works
• All tests pass locally and in CI
• I have updated documentation as needed
• CI/CD checks pass
• I have included screenshots for protocol screens (if applicable)
• For security-related features, I have included links to related information

Additional Notes

---

Important

Fixes SAS Attestation decode by updating to Borsh 2.0.0 and updating deserialization methods.

• Behavior:
  • Fixes SAS Attestation decode issue by updating to Borsh 2.0.0.
  • Replaces deserializeAttestationDataWithBorsh070 with deserializeAttestationDataWithBorsh200 in AttestationDataCard.tsx.
• Utilities:
  • Adds deserializeAttestationDataWithBorsh200() in attestation-service.tsx for Borsh 2.0.0 deserialization.
  • Retains deserializeAttestationDataWithBorsh070() for backward compatibility.
• Dependencies:
  • Adds borsh2 as an alias for Borsh 2.0.0 in package.json.
• Misc:
  • Adds toJSON method to BigInt.prototype in bigint.ts.

^{This description was created by for 1cf7db9. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

@andrey-lizunov is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 1cf7db9 in 2 minutes and 4 seconds. Click for details.

• Reviewed 85 lines of code in 5 files
• Skipped 1 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. app/address/[address]/layout.tsx:55

• Draft comment:
  Ensure that the BigInt polyfill (imported from '@/app/types/bigint') is loaded early so that any JSON serialization of BigInt values uses the overridden toJSON method.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. app/components/account/sas/AttestationDataCard.tsx:12

• Draft comment:
  Good update: the code now uses deserializeAttestationDataWithBorsh200 (Borsh 2.0.0) instead of the legacy function. Verify that the new deserialization preserves the attestation schema structure.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is informative and asks the PR author to verify the behavior, which violates the rules. It does not provide a specific suggestion or point out a potential issue with the code.

3. app/types/bigint.ts:3

• Draft comment:
  The BigInt.prototype.toJSON override works but consider adding feature detection (to avoid overwriting an existing implementation) and possibly setting configurable/non‐enumerable attributes explicitly.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment raises valid points about defensive programming - checking if toJSON already exists and being explicit about property attributes. However, this is a new file specifically for BigInt handling, and the current implementation is simple and functional. The suggestions are more about code hardening than fixing actual issues. The comment points out real potential edge cases that could cause issues in some environments. Not checking for existing implementations could cause conflicts. While technically correct, these are defensive programming suggestions rather than critical issues. The current code will work fine in most cases, and the suggestions are more about theoretical edge cases. Delete the comment as it suggests optional improvements rather than pointing out clear problems that need to be fixed.

4. app/utils/attestation-service.tsx:102

• Draft comment:
  In deserializeAttestationDataWithBorsh200, the conversion via convertSasSchemaToBorshSchema is directly passed to the new Borsh API. Confirm that the expected schema shape matches what Borsh 2.0.0 requires.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the author to confirm that the schema shape matches the requirements of Borsh 2.0.0. This falls under asking the author to confirm their intention or to double-check things, which is against the rules.

5. package.json:55

• Draft comment:
  The introduction of 'borsh2' (alias for [email protected]) alongside 'borsh' (0.7.0) can lead to maintenance complexities. Consider documenting the intended usage and marking the old implementation as deprecated if possible.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a dependency-related comment, which our rules explicitly say to ignore. The comment is suggesting documentation and deprecation, which are not critical code changes. The presence of the override suggests this dual-version setup is intentional and managed. The comment does point out a real potential issue with dependency management that could cause problems. Maybe this deserves attention? Per our rules, we should not comment on dependency changes or versions we don't recognize. The team likely has a specific reason for this setup, especially given the explicit override. This comment should be deleted as it violates our rule about not commenting on dependency changes and versions.

Workflow ID: wflow_U8iK5EytYVgEaaQg

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[rogaldh]

Link to broken attestation: http://localhost:3000/address/4qNvYnG85MWaBmDu56GXfg22gR1GyuhDPHbjUGoz2Hm3/attestation

[ngundotra]

😮 smart

[ngundotra]

Can we delete the deprecated method? Otherwise looks great!