The problem Plutus solves

1Fragmentation Across Wallets and Platforms
Problem : Crypto users often manage assets across multiple wallets (e.g., MetaMask, Coinbase Wallet) and platforms (e.g., Ethereum, Solana, Polygon). This fragmentation makes it difficult to track balances, rewards, and overall portfolio performance.
Solution : Plutus provides a unified dashboard where users can connect all their wallets and view their aggregated balances, staking rewards, and portfolio metrics in one place.
2. Complexity of Staking
Problem : Staking crypto assets involves navigating complex protocols, comparing APYs, lock-up periods, risks, and fees. This process can be overwhelming for beginners and time-consuming for experienced users.
Solution : Plutus simplifies staking with an AI-powered assistant that:
Scans available staking protocols.
Compares rewards, risks, and other metrics.
Suggests the best options based on user preferences.
Automates transactions to execute staking actions seamlessly.
3. Lack of Governance Participation
Problem : Many stakers are eligible to participate in decentralized governance but face barriers such as:
Lack of awareness about voting opportunities.
Complexity of voting processes.
Privacy concerns when casting votes.
Solution : Plutus enables stakers to participate in governance securely and anonymously using zero-knowledge proofs (ZKPs) . This ensures:
Privacy: Votes are recorded without revealing voter identities.
Security: Prevents double voting and ensures only valid proofs are accepted.
Accessibility: Simplifies the voting process with a user-friendly interface.
4. Limited Cross-Chain Support
Problem : Most staking platforms are limited to a single blockchain, forcing users to switch between apps or services to stake assets on different chains.
Solution : Plutus supports cross-chain staking , allowing users to stake assets across multiple blockchains (e.g., Ethereum, Solana, Polygon) through a single platform.

Challenges I ran into

1. Implementing proofs was a very slow and pain-staking process after every error we had to restart the process and proof building.
2. Implementing Groth16 was a bit tough but the docs helped.
3. Values inputs while txResponse was the worst error during calling the contract deployed on open-campus, got over it through a day worth of trial and errors in smart contract's code and its version.
4. Implementing the agent's on chain transactions was a bit tough due to it's specific json requirements.