Issue Description:
The goal of this issue is to create the Deposit and Withdrawal sections on our exchange front-end. These sections will allow users to deposit and withdraw assets from the exchange.

The following components need to be modified:

1. web/@app/exchange/src/components/Assets.tsx
2. web/@app/exchange/src/components/Assets/

Tasks:

1. Implement the Deposit section:

   • Add a deposit input field where users can enter the destination address for the deposit.
   • Include an input field for the deposit amount.
   • Implement a deposit button for initiating the transfer.

2. Implement the Withdrawal section:

   • Add an input field for the withdrawal address where users can specify the destination address for the withdrawal.
   • Include an input field for the withdrawal amount.
   • Implement a withdrawal button to initiate the transfer.

Additional Notes:

• Ensure the design is visually appealing and responsive, adjusting appropriately when the browser window is not wide enough.
• Utilize Solid.js, Tailwind CSS, and TypeScript for development.
• Do not include advanced TypeScript logic or backend functionality at this stage.
• Both the Deposit and Withdrawal sections should be placed next to each other in the user interface.
• These sections can stack vertically (one above the other) when the browser window is not wide enough to accommodate them side by side.
• The majority of the required components have already been developed (numberInput, textInput, buttons).

Description:

I would like to assign a task to develop a Rust module that serves as an interface for communicating with a blockchain. We will be using the alchemy provider for this purpose. The module should provide the following functionalities:

1. Subscribe to Blockchain Events:

   • Ability to subscribe to specific blockchain events (e.g., "block mined") and receive a stream of these events as Rust Stream objects.
   • Support for subscribing to events from a specific smart contract, such as "Withdraw event" for a particular user, and returning a stream of objects.

2. Calling Smart Contract Methods:

   • Ability to call methods on smart contracts and retrieve data from them.

To accomplish this task, I recommend utilizing the ethers-rs Crate. This library provides helpful abstractions and utilities for interacting with Ethereum, including the ability to specify the HTTP provider or WebSocket provider, as well as the contract's ABI.

To get started, please create a new blockchain module within the server crate and begin working on the implementation. Feel free to ask me any questions if you require clarification or guidance on the best approach for development.

Please ensure that the resulting interface is robust, flexible, and meets the requirements mentioned above. If you encounter any uncertainties or believe that additional information is necessary, please don't hesitate to ask for further clarification.

Introduction

Users on KSOX Exchange will receive badges for certain actions, we need dashboard to present already gained badges and those that are not yet received.
There are 5 groups of badges more info can be found here:
README.md

Root

ksox/web/@app/dasboard/

Task Description

Develop Dashboard component that will present badges themselves in groups they belong to in appealing and informative way.
Each badge is going to have name, short description, progress bar, and avatar / graphic.
Badge can be in two states "gained" (progressbar 100% and highlighted) and "not gained" (progresbarr at X%)
Design frontend components using mainly color pallete from ksox/web/@app/dashboard/tailwind.config.cjs
Dashboard needs to be responsive, it has to present well on both desktop and mobile. For responsive design use only tailwindCSS media query tags.

Files

Progress bar component pattern can be found here:
ksox/web/@app/exchange-landing/src/components/Token/ProgressBar.tsx

Description

The current backend codebase lacks consistent formatting and readability in various sections throughout the project. There are multiple places where code reformatting can be applied to enhance clarity and maintainability. To achieve this, we need to leverage the power of Rust macros, including procedural macros, derived macros, and other available macros, to streamline and beautify the code.

Goals

The primary goals of this task are as follows:

• Reformat the codebase to improve consistency and readability.
• Apply Rust macros, such as procedural macros and derived macros, to simplify and shorten the code where appropriate.
• Enhance the clarity and maintainability of the code in the worker, engine, and engagement components of the project.
• Ensure that the overall project maintains good coding practices and adheres to Rust conventions.

Proposed Solution

To accomplish the goals mentioned above, we will undertake the following steps:

1. Conduct a comprehensive code review to identify areas in the backend codebase that can benefit from reformatting and improved readability.
2. Design and implement procedural macros, derived macros, and other applicable Rust macros to automate and simplify repetitive code patterns.
3. Apply the macros to the identified sections of the codebase, reducing duplication, and increasing clarity.
4. Validate the changes and verify that the refactored code retains its functionality through unit tests and integration testing.
5. Document the macro implementations, including usage guidelines and any necessary configuration updates, to ensure future maintainability.

Additional Information

This is a substantial task aimed at improving the overall consistency, readability, and maintainability of the backend codebase. If you encounter any challenges or require further clarification, please don't hesitate to reach out for assistance.

Description

The current badge storage mechanism in the engagement engine has limitations that hinder the flexibility of managing badges. The badges are currently stored in the code, preventing easy addition, modification, or removal of badges while the service is running. To overcome these limitations and improve the badge management functionality, we need to upgrade the badge storage to PostgreSQL.

Analyze the current engagement engine and the code responsible for badge storage: server/engagement/src/engagement_engine/badges

Proposed Solution

The proposed solution is to store the badges' metadata in a PostgreSQL database. This upgrade will allow us to add new badges, modify descriptions, names, and values of existing badges without having to make changes to the code. The goal is to preserve the current engagement functionality while enhancing the badge management capabilities.

Additional Information

Before proceeding with the implementation, please reach out to me to clarify any additional details or requirements. It is crucial to maintain the current code conventions and adhere to good practices throughout the upgrade process.

Note: If you need assistance or have any questions during the implementation, please don't hesitate to ask for support.

Overview

We need to create a simplified view of the Payment Processor Application based on the Revolut design. The design should be coherent for both mobile and desktop versions, focusing on a minimalistic approach as per the reference pictures provided.

Components

1. Home View

   • Mobile: View Design
   • Desktop: View Design

2. Transfer View

   • Mobile: View Design
   • Desktop: View Design

3. Basic Desktop View

   • View Design

Requirements

• Simplicity: The design should be minimalistic, removing unnecessary elements as shown in the referenced Discord pictures.
• Responsive Design: The design should be adaptable to both mobile and desktop platforms.
• Workflow:
  1. Mirror the reduced mobile design.
  2. Derive the desktop design from the mobile version, such that the top navbar and bottom navbar can be merged and go to the left, while the main content becomes larger and fills the right side of the screen.

Acceptance Criteria

• Home view and Transfer view implemented for both mobile and desktop.

Introduction
Users on KSOX Exchange will receive badges for certain actions, we need user panel to present already gained badges.
There are 5 groups of badges more info can be found here:
README.md

Root
ksox/web/@app/dasboard/

Task Description
Develop User Panel component that will present basic user info (user name, user's avatar) and received badges.
Panel should take less than half of the viewport's height.
Design frontend components using mainly color pallete from ksox/web/@app/dashboard/tailwind.config.cjs
Dashboard needs to be responsive, it has to present well on both desktop and mobile. For responsive design use only tailwindCSS media query tags.

Introduction
There is need for component that we can show notifications with. This component is placed in bottom left corner. It works like FIFO queue. Items are auto-removed after constant amount of time.

Root
ksox/web/@app/dasboard/

Task Description
Most recent notification is displayed at the bottom-most position of the component. Notifications are removed from the
top-most position when the have been displayed for some time. Notifications are tiles on this stack.
Tile should be of simple design should handle arbitrary children component.

Description

The current logic behind the Notification Manager in the notifications.rs file located at server/worker/src/database/managers/notifications.rs requires optimization and redesign to improve its efficiency. The existing implementation relies on a listen-notify channel from the database, where JSON messages flow to indicate changes in specific tables. The Notification Manager listens to this channel, retrieves modified or inserted data from the database, and propagates relevant messages to subscribed users based on their specified predicates.

However, the current approach becomes inefficient when dealing with a large number of users since it linearly checks each predicate for every received message. To enhance the performance and elegance of the Notification Manager, we need to come up with a more efficient algorithmic solution while maintaining its current functionality.

Goals

The primary goals of this task are as follows:

• Redesign the Notification Manager logic to improve efficiency and scalability.
• Optimize the algorithm to handle a larger number of users and predicates without performance degradation.
• Preserve the existing functionality of the Notification Manager, ensuring that subscribed users receive the relevant messages based on their predicates.
• Enhance the elegance and maintainability of the codebase.

Additional Information

To ensure a successful redesign of the notification manager logic, it is crucial to have a clear understanding of the current implementation and the desired improvements. Please feel free to ask any questions or seek further clarification before proceeding with the implementation.

Overview

We need to implement the functionality to allow users to connect their wallet to our application and perform deposit and withdraw operations between their wallet and the application's smart contract. This will involve interaction with the specific methods within our smart contract and implementing appropriate client-side logic and interfaces.

Details

Smart Contract: Treasury.sol

Deposit Flow:

1. Client calls depositPermit on the smart contract, which emits a Deposit event containing the information needed for the server to account for the funds.
2. Server listens for Deposit events from the blockchain, and when received, accounts the funds properly.
   Task: Properly call depositPermit method on the smart contract.

Withdraw Flow:

1. Client asks the server to sign data to prove to the smart contract that the server is aware of the withdrawal and authorizes it.
2. Client calls withdrawPermit method on the smart contract, providing a valid signature, triggering the Withdraw event.
3. Server listens for the Withdraw event until a deadline. If the event is not received, the server restores the locked funds to the user internally.
   Task: Implement this logic.

Design

The two subsites for deposit and withdraw functionality must be implemented more less according to this 'professional' Figma design.
There is a lot of free space to change this design and make that better.

Acceptance Criteria

• Implement client-side logic for the deposit using the depositPermit method.
• Implement client-side logic for the withdraw using the withdrawPermit method.
• Create interfaces for deposit and withdraw based on the provided Figma design.
• Ensure proper interaction with the smart contract and handle all necessary events.
• Include necessary validations and error handling.