Description

The current process requires users to verify multiple words individually, causing the interface to loop back to the initial step after each word. This repetitive process needs to be clearer and more efficient.

User Feedback

• There's no clear indication that multiple words need to be verified.
• After each word verification, the interface resets to the initial security check page.
• Verifying all words in one step would be more user-friendly and efficient.

Acceptance Criteria

AC1 - Clarity on the Length and Form of Mnemonic

The interface should clearly inform the user about the total number of mnemonic words they need to verify and their sequential order.

Given a user is setting up their Mina Protocol wallet,
And the mnemonic verification step is initiated,
Then the interface should display the total number of mnemonic words required for verification,
And indicate the order in which these words need to be verified.

AC2: Efficient Verification Process

All mnemonic words required for verification should be presented and verified on a single page to enhance user experience and efficiency.

Given a user is setting up their Mina Protocol wallet,
When they reach the mnemonic verification step,
Then they should be able to verify all required mnemonic words on a single page.

AC3: Resolving the 'Enter' Key Behavior Issue

The 'Enter' key behaviour should be consistent and intuitive during the mnemonic verification process, ensuring that the verification step progresses without causing unexpected resets or loops.

Given a user is at the mnemonic verification step in the Mina Protocol wallet setup,
When they input a mnemonic word and press the 'Enter' key,
Then the action should correctly register and lead to the next step in the verification process,
And not reset or loop back to the previous screen.

Issue Title: Add Block Producer Viewing Feature in Staking Tab

Description

In the Staking Tab of Pallad, users require a convenient method to view block producers. This functionality will enable users to decide who to delegate their MINA to quickly.

Acceptance Criteria

1. View Block Producers: Users should be able to view a list of block producers within the Staking Tab.
2. Filter and Sort Options: Users should have options to filter and sort block producers based on various criteria like performance, fees, etc.
3. Delegate Functionality: There should be an easy way to delegate MINA to a block producer from this view.
4. User-Friendly Interface: The interface should be intuitive and easy to navigate.

Gherkin

Feature: View Block Producers in Staking Tab

  As a user of the Mina network
  I want to be able to view and assess block producers directly from the Staking Tab
  So that I can make informed decisions about delegating my MINA without leaving the wallet.

  Scenario: Viewing the list of Block Producers
    Given I am on the Staking Tab
    Then I should see a list of available block producers

  Scenario: Filtering and Sorting Block Producers
    Given I am viewing the list of block producers
    When I apply filters or sorting criteria
    Then the list should be updated to reflect my preferences

  Scenario: Accessing Detailed Information of a Block Producer
    Given I am browsing through block producers
    When I click on a block producer
    Then detailed information about the block producer should be displayed

  Scenario: Delegating MINA to a Block Producer
    Given I have chosen a block producer
    When I select the option to delegate my MINA
    Then the process to delegate MINA should be initiated

Most likely with Tauri.app

Use consistent JSON serialisation across all packages with superjson.

@palladxyz/mina-graphql currently uses json-bigint to do both customFetch and as defaultJsonSerialization. Using superjson instead of json-bigint and JSON would make better and consistent JSON serialisation across Pallad as a product.

This was first attempted in #121 but with little luck.

zkApp to Wallet Connector Package 🔌

With Pallad having its own injected provider, it is a good idea to have a client-side version for interacting with Pallad. zkApp developers shouldn't have to spend much time to integrate Pallad for its users to interact with the developer's zkApp. A package that abstracts over the injected provider's functionality could give developers the required quick access to Pallad's features.

It also allows for better testing of Pallad's injected provider in an example zkApp like Minaverse 🪐

Possible Solutions 💡

• Wagmi
• Standalone Mina package for all Mina ecosystem wallets

Requirements 📖

• Versioning of wallet APIs
• Completion of #111

Key Management Signing Operation Guards Improvement

Within the KeyAgentBase the type of signing operation is done by MinaSigningOperations. This function uses some type guards to determine which operation to perform given a payload: T. However there is a naive assumption here that the payload -> signing operation mapping is one-to-one, it is not, it is one-to-many.

In other words, it is possible to be given a payload but use one of several operations. I first ran into this when adding the createNullifier API from mina-signer, it shares the payload type with signFields!

The solution would be to remove the type guards and call a specific signing operation instead of just to assume from the payload type.

Wallet2Wallet Encrypted Messaging

Implement encrypted messaging between Pallad wallets.

Links

• https://github.com/paulmillr/nip44

Fix Decimal Truncation in Transactions Tab

In the Transactions Tab, the amount is displayed without decimal points, leading to a loss of precision. The amount should be displayed with two decimal places.

Feature: Display correct decimal points in Transactions Tab
  As a user
  I want to see transaction amounts with a consistent two decimal places across the application
  So that I can have a consistent experience throughout the application

  Scenario: Viewing transaction amounts
    Given I am on the Transactions Tab
    When I view a transaction amount
    Then the amount should include two decimal places

Displaying Liveness of Pallad 🧟

Good interaction design states that there should be some visibility of system status.

The design should always inform users about what is going on through appropriate feedback within a reasonable amount of time.

Pallad users should, for example, be able to know the status of the wallet not just by seeing transactions populate in their transaction overview screen or when their balance changes but also when the wallet is querying data from the network. Should there be errors or challenges connecting to a web node, remote API provider, or local host, Pallad should communicate that to the user. One case is displaying errors to the user in an understandable way that limits the impact on the user experience or allows them to understand the system status with a low cognitive load (loading bars, icons, and colours can help significantly in this arena).

Adjust SWR config to defer the loading and cache so it doesn't fetch on every overview render.

Ethereum Key Derivation & Signing Features

Because Mina is a zk-native chain, there is a world of possible features to build. One emerging and evolving area is the ability to scale Ethereum. This includes:

1. Bridging state from Mina to be verified on Ethereum using the Lambda Class bridge
2. ECDSA w/o1js, per the o1js documentation:

To interact with other blockchains and verify data from the outside world, o1js needs to be able to verify signatures. ECDSA is a widely used algorithm that is supported by many libraries and tools. For example, Ethereum transactions are signed using ECDSA over the secp256k1 curve. As a zkApp developer, when you want to verify an Ethereum transaction and make a statement about it, you must be able to verify the signature of the transaction which is why ECDSA is important for zkApps.

Pallad would greatly benefit its users by including the ability to derive Ethereum addresses and sign data using secp256k1 for Mina's zkApps.

Feature: Ethereum Key Derivation & Signing for Pallad
  In order to enhance interoperability and functionality,
  As a user of Pallad,
  I want the ability to derive Ethereum addresses and sign data using secp256k1.

There's quite a few hardcoded variables that we've left in the application, we should remove them and unlock the dynamic Pallad experience.

Delegation Transaction Labeled as "Incoming"

This bug arises when inspecting a transaction & should be named something else. The INCOMING & OUTGOING definitions need to include richer transaction types.

Example Screenshot

Handling Network Errors 🚨

Sometimes, when querying for a wallet's state from an API, the response might be an error, leaving the wallet unable to obtain the state it expects (e.g. AccountInfo). One known instance of this impacting users is in prevent users from progressing/completing the onboarding (either restoring or creating a new wallet).

Expected behaviour

Gracefully handle API errors that allow users to continue onboarding. Signifiers should communicate to the user issues/errors if they are relevant -- good interaction design is paramount.

Example Logs

When creating a new wallet and typing in the correct word to prove knowledge of the created mnemonic, users are left stuck at the onboarding screen with Next button highlighted but not progressing to the Overview page. Console's logs:

Correctly Label Transactions as 'Sent' or 'Received'

All transactions in the wallet are currently labelled as 'Received,' regardless of whether they are incoming or outgoing. This issue needs correction for accurate transaction labelling.

Feature: Accurate labelling of transactions as 'Sent' or 'Received'
  As a user
  I want transactions to be correctly labelled as 'Sent' or 'Received'
  So that I can easily understand my transaction history

  Scenario: Labeling a sent transaction
    Given I have completed a transaction
    When I view the transaction in the transaction history
    Then the transaction should be labelled as 'Sent' or 'Received' based on the transaction type

Currently users will see all transactions labelled as 'Received':

Resolve Wallet Crash on Sending Transaction with Low Fee

The wallet application crashes when the send button is hit for a transaction with a low fee (0.001). The GraphQL log shows a RangeError: The number NaN cannot be converted into a BigInt because it is not an integer.

Feature: Ensure wallet stability with low transaction fees
  As a user
  I want to send transactions with the lowest transaction fee possible without crashing the wallet
  So that I can use the wallet reliably

  Scenario: Sending a transaction with a low fee
    Given I am creating a transaction
    When I select the lowest fee
    And I hit the send button
    Then the transaction should be sent successfully
    And the wallet should not crash

The below screenshot is of the wallet console error:

• bs58check can be replaced by @scure/base
• pbkdf2, get-random-values can be replaced by @noble/hashes
• lodash is not used anywhere
• ethereumjs/util, I think, already uses noble-hashes and scure-base, so you would get less code in the result bundle

Description

We've successfully implemented a Proof of Concept (POC) workflow utilizing mina-local-network, paving the way for a significant enhancement in Pallad's test suites. The proposed feature involves the integration of workflows & (CI) that not only test against this deployed network within CI but also against public networks.

🎯 Goals

• Enhance Pallad's test suites.
• Implement workflows & CI that utilize mina-local-network.
• Test against both the local network in CI and public networks.

🛠️ Proposed Solution

• Introduce environmental variables to the test suites for greater flexibility.
• These variables should include configurable mnemonics, network URLs.
• Eliminate hard-coded parameters currently present in our test suites to allow for more dynamic and adaptable testing environments.

🚀 Package Release via Nightly Workflows

• Implement automated nightly workflows to release Pallad's packages to npmjs.
• Ensure each nightly build passes all new and existing tests before release.
• This automation enhances the frequency and reliability of package updates, providing users with the latest features and bug fixes.

💡 Expected Benefits

• Enhanced test accuracy and coverage.
• Increased flexibility and adaptability in testing different network environments.
• Improved reliability and maintainability of Pallad's test suites.

Description

The current version of the Pallad Web3 wallet is limited to supporting only 12-word mnemonics for user authentication and wallet recovery. This limitation prevents users with mnemonics of different lengths or desires higher entropy from a seed phrase, commonly 18, 21, or 24 words, from using Pallad. To enhance user experience and compatibility, this feature aims to extend mnemonic support to include 18, 21, and 24-word lengths.

Scenario: 24-word mnemonic in create new wallet
Given a user is setting up a new Pallad wallet
When they choose to create a mnemonic
And select a 24-word length
Then the wallet should generate a valid 24-word mnemonic
And allow the user to create a new wallet with this mnemonic

Scenario: 24-word mnemonic in restore existing wallet
Given a user is setting up a existing wallet
When they choose to restore a wallet from an existing mnemonic
And select a 24-word length
Then the wallet should allow the user to enter their 24-word mnemonic
And allow the user to restore that wallet

Some of the GraphQL provider queries have deprecated fields. We must remove them and use the proper fields.

For example in AccountInfoProvider's query:

export const getAccountBalance = `
  query accountBalance($publicKey: PublicKey!) {
    account(publicKey: $publicKey) {
      balance {
        total
      },
      nonce
      inferredNonce
      delegate
      publicKey
    }
  }
`

The delegate field is deprecated & should be replaced with delegateAccount.

Switching Chains ⛓️

Switching chains is a necessary feature in Pallad to allow the user to enter the chain's information and provider information, allowing the user to choose who severs their data and what chains their instance interacts with.

The wallet MUST emit a chainChanged event when this happens.

@palladxyz/features:dev: src/common/store/app.ts(3,37): error TS7016: Could not find a declaration file for module '@palladxyz/persistence'. '/Users/.../Documents/pallad/packages/persistence/dist/index.js' implicitly has an 'any' type.
@palladxyz/features:dev: If the '@palladxyz/persistence' package actually exposes this module, try adding a new declaration (.d.ts) file containing declare module '@palladxyz/persistence';
@palladxyz/features:dev:
@palladxyz/features:dev: [@PALLADXYZ/FEATURES] DTS Build failed
@palladxyz/features:dev: Error: error occured in dts build
@palladxyz/features:dev: at Worker. (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected][email protected][email protected]/node_modules/tsup/dist/index.js:2690:26)
@palladxyz/features:dev: at Worker.emit (node:events:512:28)
@palladxyz/features:dev: at MessagePort. (node:internal/worker:263:53)
@palladxyz/features:dev: at [nodejs.internal.kHybridDispatch] (node:internal/event_target:778:20)
@palladxyz/features:dev: at exports.emitMessage (node:internal/per_context/messageport:23:28)
@palladxyz/features:dev: RollupError: Failed to compile. Check the logs above.
@palladxyz/features:dev: at Object.error (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/parseAst.js:279:30)
@palladxyz/features:dev: at Object.error (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:820:32)
@palladxyz/features:dev: at Object.error (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:18635:42)
@palladxyz/features:dev: at generateDtsFromTs (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected][email protected][email protected]/node_modules/tsup/dist/rollup.js:7776:22)
@palladxyz/features:dev: at /Users/.../Documents/pallad/node_modules/.pnpm/[email protected][email protected][email protected]/node_modules/tsup/dist/rollup.js:7783:59
@palladxyz/features:dev: at _nullishCoalesce (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected][email protected][email protected]/node_modules/tsup/dist/rollup.js:1:198)
@palladxyz/features:dev: at Object.transform (/Users/.../Documents/pallad/node_modules/.pnpm/[email protected][email protected][email protected]/node_modules/tsup/dist/rollup.js:7783:18)
@palladxyz/features:dev: at /Users/.../Documents/pallad/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:1005:40