Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 3 and onwards is the beginning of User interaction with the MASP. Even though the previous stages issued rewards (PRP) in the MASP, users did not directly interact with the Shielded Pool. This stage forms the basis of some of the key components that will be released in further stages.

Stage 3 provides a brand new User Interface with enhanced images, icons, colors, and space alignment while the overall dApp flow has not changed.

The core functionality includes:

• Deposit a new asset (test Matic) into the MASP. Asset allowlisting is one of the DAO functions to exclude scam tokens into the MASP. For testing purposes, the team has included test Matic and expects to include a few more tokens in later stages.

• Stage 3 includes the basic disclosure functionality under the History tab. Basic disclosures provide information about different types of transactions performed within Panther along with its transaction hash and the date/time of the transaction.

User Testing Flow

To deposit a regular asset a user should:

1. Go to the Deposit screen by selecting any of the available options. From the:

   • Within the zAsset menu item, click on the Deposit tab as shown in the screenshot below

   • Within the My Public Asset section in the Dashboard, select the token; this takes the user to the Deposit screen

   • Private zAsset section will also have the option to select and deposit

   • On zAsset Portfolio, click the balance card

2. Select the token to deposit if it is not preselected, or adjust your selection via the token selection modal window.

3. Enter the amount to deposit.

4. Click the Deposit button and complete the transaction.

5. View the corresponding changes in the Dashboard, your Private zAssets section, and the adjusted balance of the deposited asset.

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

At this stage, users will be testing two features that allow Panther to combine privacy-preserving DeFi access with compliance capabilities:

Third-party compliance integrations

Panther has built a system that retains neutrality by plugging directly into compliance providers and integrating them into the application’s flow. These systems can capture certain types of user data and issue a Zero-Knowledge proof attesting that users have been verified without the Protocol learning any information from them.

The Panther DAO has been commissioned to select a compliance vendor that aligns with its interests, a discussion taking place in Panther’s forum. For the sake of this Testing exercise, an integration has been built that uses PureFi’s system. PureFi is a multi-vendor compliance provider that has demonstrated interest in partnering with Panther through the DAO discussions.

Registering using these integrations is a multi-step process that connects a user’s Panther Account with the verification performed by PureFi.

It consists of: a. Creating a Panther Account by connecting your wallet (e.g. MetaMask).

b. Undergoing a basic verification on PureFi’s site (opened in a pop-up tab).

c. Completing the verification process in the Panther dApp by providing the created proof of verification. This process involves downloading files on your browser (around 30MB), which can sometimes take 2-3 minutes (depending on IPFS’ responsivity at the time. In case of trouble, reloading may help.)

The above activates the user’s Panther account created in step (a) above, and issues account creation rewards to the user.

Panther Accounts

Within Panther, users are identified through their Panther Account (which has a corresponding zAddress), a concept similar to a bank account in that it englobes all of a user’s transactions within a single reference point. Accounts attest to users’ compliance verification while retaining Zero-Knowledge properties. In other words, they prove that a user has passed verification (as well as the type of verification passed), but they do not store any private information about users.

We posted an article further expanding on the rationale behind both of these components, as well as Panther’s compliance focus. Check it out here!

Testing and providing feedback

As we mentioned, Testnet rewards are automated, and as such, the Testnet itself will reward users for going through the Account creation flow. However, the goal for the Testnet is to debug and enhance the Protocol before the mainnet beta launch.

Our expectation is that users submit bugs and share ideas to enhance end-to-end functioning, interaction and usage of wallets, UI/UX flows, and let us know about any component that doesn’t look or feel as expected. We have created the following spreadsheet containing all the details that users can test, which includes functional and visual components. Note that every testing case is numbered to facilitate the process of providing feedback.

Spotting and fixing any possible bugs within the Testnet will make the first version of the protocol more sustainable in the middle term while allowing users to receive their earned rewards.

How to test

Users can visit the Testnet link for Stage 1 to test the onboarding functionality. This involves creating a Panther Account, undergoing a simple verification process (name and email required, ID NOT required) with PureFi, and activating their Account. We recommend that you test along with reviewing the testing spreadsheet so that you can keep track of everything you need to test.

To share feedback, testers will be using a dedicated form as the only accepted procedure. The steps mentioned in the form’s description are needed to make this interaction both efficient and productive.

Status: Testing underway

During the Stage 5 test phase, the Mumbai network was fully deprecated, forcing the test dApp to transition to Sepolia.

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 5 introduces two core functionalities with some extra details on the impact to UTXO Selection:

• Integrations with 3rd party Bundlers

• Faster transaction option

Integrations with 3rd party Bundlers

Panther has integrated with Etherspot’s Skandha ERC4337 Bundler service to send transactions to the blockchain. Users will now have an option to select (Bundler = YES / NO) before submitting their transactions.

• Bundler = YES will send transactions via the Bundler services in which case the network gas cost is deducted from the balance of their Panther Gas Account.

• Bundler = NO will send transactions directly from user's EOA (externally owned account, i.e. the connected MetaMask wallet) and the network gas fee is paid from that wallet in the native gas token.

Introducing faster transactions

Panther uses zMiners to process newly created UTXO in batches instead of individual UTXO commitment updates enabling lower gas cost for the transactions involved in this batch.

UTXO selection update

Stage 5 enables UTXO's to be processed individually as opposed to a batch enabling near instant spending of the new UTXO’s. This reduces the wait time to process the batch but comes with an extra cost. Technically this is referred to using a ‘Taxi’ (from the Taxi tree where the UTXO gets added).

The user can choose between the Regular Processing (taking the bus) and Fast Processing (taking the taxi) from the toggle available under the Fee section before submitting any transaction.

As a result of the above change to process newly created UTXO in two modes, some UTXOs may not be immediately available to be used in another transaction (or spent). This restriction applies only for a short period of time (a few minutes) until the Bus Queue or the Miner has processed the next queue. These restriction are:

• UTXOs created by two separate FAST transactions can't be spent together

• UTXOs created by FAST transactions and a REGULAR transactions cannot be joined together

Again, it is important to note that these restrictions apply only for a very small duration of time after the creation of a FAST transaction and it pertains to how soon you can spend a UTXO created by a FAST transaction and join it with other available UTXO’s. It has nothing to do with the FAST transaction in itself but the output of this transaction to be used in the next transaction.

User testing flow

Bundler selection

1. Navigate to any the transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.

2. A new Bundler toggle is available for selection between a YES or a NO:\

Processing selection

1. Navigate to any of transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.

2. A new toggle to select Processing Type is now available.\

UTXO selection update

Notes: The fee functionality is not completely integrated in this version yet so the testing expectation is that transactions are processed via Bundlers and users also able to process FAST transactions. The deduction of fees and the full calculations of fees will be implemented with Stage 6.

What next?

For more information on zMiners, see the Stage 0 blog.

Status: Completed

For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 4 introduces two core functionalities:

• Internal Transfers (Send and Receive): Users can transfer zAssets to other Panther users inside the Shielded Pool. zAssets can be sent to another user using their zAddress. Every Panther user is assigned a zAddress that can be viewed on the Panther account. The Receive screen is also available for your convenience to share your Panther account address (referred as zAddress) via QR code. Simply, navigate to the dashboard and click on the Receive button.

• Withdrawal: Users will be able to withdraw zAssets from the Shielded Pool back to an external wallet. This external wallet can also be a new account different from the account used to deposit assets. Compliance checks are performed to ensure that users prove they are the owner of the zAccount they are interacting with and that the wallet where assets are withdrawn is a clean wallet.

The Protocol rewarding mechanics have been enhanced with two new features:

• Automatically converting pending PRPs into available PRP upon spending of UTXO(s) due to transfers and withdrawals.

• Rewarding a user with a flat PRP bonus upon spending UTXO(s).

User Testing Flow

Internal Transfer:

1. Navigate to the Send screen through:

   • Top main menu - zAssets - Send screen,

   • zAssets Portfolio card - Send button,

   • Dashboard - Private zAssets section - token line - token management buttons.

2. Set the amount.

3. Choose the token.

4. Manage UTXOs as needed.

NOTE: The current version allows the selection of a maximum of two UTXOs in a given transaction - that defines Selected Balance. By default, UTXO’s with the top two balances are selected. If the transfer amount is less than the chosen UTXO(s) amount, the new UTXO with the returned amount is added to users zAsset list.

1. Specify the destination address in the Panther account format, beginning with "ZK" and having a total of 42 characters - enter a new address or select from previously used options.

2. Push the Send button to initiate the internal transfer.

Withdrawal:

1. Navigate to the Withdraw screen through:

   • Top main menu - zAssets - Withdraw screen,

   • Dashboard - Private zAssets section - token line - token management buttons.

2. Set the amount.

3. Choose the token.

4. Manage UTXOs as needed.

5. Specify the destination address in Polygon network format, beginning with "0x" and having a total of 42 characters - enter a new address or select from previously used options.

6. Push the Withdraw button to initiate the internal transfer.

Status: Testing in progress

1. DeFi Adaptors:

The first DeFi feature has been introduced: Swap functionality. Users can swap their shielded assets (zAssets) while keeping them in the MASP and interacting with external decentralized Swap protocol. For the purpose of testing, Stage 7 will include integrations with two Swap protocols - Uniswap V3 and QuickSwap simulated on Amoy ( the new test network of Polygon).

To prepare the transaction, a user should (1) choose the target pair for the swap and (2) set the amount to send (swap from). The user can see the estimated amount to receive (swap to). Additionally, the user can (3) switch the send/receive tokens within the chosen pair. Note: The amount to receive is not final and may vary depending on the user’s transaction settings (particularly the maximum slippage parameter) and the actual pool parameters at the time of transaction execution.

A swap transaction requires users to define the following settings to initiate it:

1. Route: By default, the product selects the best route, but users can change this option based on their preference.

2. Maximum Slippage: This parameter defines the allowable difference between the expected price of an asset and the actual price at which it is traded/swapped. Users can choose from (a) Auto, (b) preset amounts (0.1%, 0.5%, 1%), or (c) a Custom option. Note: Setting the slippage below 0.05% may cause the transaction to fail, while slippage above 1% could result in an unfavorable rate for the swap.

Transaction Deadline: This parameter sets the time frame after which a pending transaction will automatically revert if not completed. The current setting is fixed at 5 minutes.

Transaction parameters are divided into two groups: (1) swap and (2) protocol. The second group is consistent across the product's functionality, while the first group details the specific characteristics of the swap route:

1. Price Impact: This measures the price change resulting from the swap transaction the user intends to execute, considering factors such as liquidity, order book depth, and order size.

2. Swap Fee: This is the fee collected by the external platform that facilitates the transaction route. To preserve user privacy, this fee is initially collected using zZKP and later paid to third parties by the protocol.

3. Slippage: This parameter, set by the user, defines the acceptable difference between the expected price of an asset and the actual trading price.

4. Minimum Received: This represents the guaranteed amount the user will receive, taking the slippage parameter into account.

5. Ratio: This likely refers to the exchange rate or conversion ratio between the swapped assets.

1. Data Escrow

Data Escrow is an important Product Feature that supports Compliance Data requirements. Panther Protocols has implemented different types of Data Safe mechanism based on the roles that the DAO, Institutions (also referred as the Zone Manager) and Compliance provider perform to support this. In the next stage, we will continue to build the decryption mechanism for those roles to access the data. The whole process will be tested when those roles participate in the testing process - essentially we see this as a process to Zone Manager testing the protocol along with other participants.

1. History page:

The History page UI has been updated with structured and detailed data, including the following factors:

• Transaction Type

• Amount

• Asset

• USD Value

• Date and Time

Additionally, data sorting by these factors has been implemented to enhance user experience. To use the functionality one should hover a cursor on a particular column title and click it.

\

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Status: Complete (but the docker Panther Miner is still working!)

This testing stage (and activity in production) is directed towards miners, a key role in the Panther ecosystem, as opposed to DeFi users. It started in July 10th, 2023, and is projected to last for two weeks.

To see the original announcement, along with explanations of the components tested, click here.

Testing scope

Stage 0 launches the Panther Miner, a specialized miner designed to interact with a blockchain network.

Within Panther, Ecosystem Operators run an Oshiya node — code that fetches the pending mining queue. Oshiya then computes updates to the Merkle trees needed to append the UTXOs of the queue to the trees, create a SNARK-proof that proves the correctness of the updates, and submit these updates to be written on-chain together with the proof to smart contracts. As such, the Panther Miner software acts as the “Bus Operator” for the Bus Tree (see Shielded Pools on behalf of a user.

In this implementation, the algorithm to reward miners is fairly simple. Eventually, the Panther community may want to implement a more sophisticated algorithm after some initial usage statistics are collected.

How to test

To test at this stage, follow the steps below.

Test in app

1. Visit the miner test page.

2. Understand the following three variables:

2.1 Interval (in seconds): the designated pause between iterations produced automatically by the miner. You may reduce this down if your system and the RPC provider handles the load, or you may increase this to lengthen the space between iterations.

An iteration includes:

a) Checking the BusTree contract for a queue expecting processing and selecting the most profitable one to process.

b) Generating a ZK proof by processing the chosen queue.

c) Submitting the ZK proof to the blockchain.

2.2 Private Key: the private key of the wallet used to sign batch transactions and receive rewards.

There are two options for this field:

2.2.a Use an existing key, e.g. exported from your MetaMask; or 2.2.b Generate a new key pair. Click “Generate private key using MetaMask” and get a new private key inserted into the corresponding field. You can add the new address to your MetaMask (click “Show Private Key” to unveil and copy the data) afterward.

A new public key (address) will be reflected as soon as you start mining. Find it in the “Mining statistics” section.

2.3 RPC URL*: use any RPC you prefer, as long as it’s valid for the Mumbai network.

3. Ensure you have a positive balance of MATIC in your wallet to interact with the product. You can visit faucet_1 or faucet_2 to get test MATIC tokens.

4. Click the “Start Mining” button to start the process.

5. Check that the “Logs” section is updating.

6. Check that the “Mining Statistics” section is updating.

Please, note:

• The “Generated Proof” amount can be bigger than “Submitted Proof,” meaning other miners submitted a generated proof earlier than you.

• “Mining Success” = “Submitted Proof”(s).

• Your Balance (of MATIC) will decline over time because the miner client generates UTXOs to let you interact with them to test the functionality. Submitting UTXOs incurs a cost.

1. Check that you’re receiving rewards correctly.

2. Stop mining. (Note: the miner will finish the ongoing iteration before entirely stopping).

Using a Docker image

For users interested in running the Panther Miner themselves instead of using a browser version, the Dockerized version has the same functionalities and logic outlined above. Here’s the link to the Docker image page: https://hub.docker.com/r/pantherprotocol/miner-client Smart contract details (on Mumbai):

• BusTree: 0x678D34aA4fc546bA806287a8289FfdAA84681a03

• VPool: 0xCd85e3E918F1A36F939281d3ca707EE262a364c6

• test DAO multisig: 0xfB474a7FeCDaFBD412ebF0d60A0C32794F82d3dD

• PantherVerifier: 0xeeAfce13506847a19141A4513718df17383f4f7b

• PantherPool: 0xfDfD920F2152565E9D7b589e4e9faeE6699AD4bd

• Vault: 0x9619bd59411a8387a4119e548017C5b86c7bCec5

• FXPortalBridge: 0x542c2c3e6BBfD5979E5FEC6708764B93Ba210c51

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

At this stage, Users will be testing:

• Claim PRP voucher

• View private balance on the Dashboard

Vouchers

Vouchers are a reward mechanism that can be used by the Protocol to incentivize for certain functions that have to be triggered by Users. We refer to them as Admin functions. Those could include but not limited to functions such as

• Recharging Reward Pool

• Trigger conversion of token

Note: the onboarding reward voucher issued in this Stage is only for testing purposes.

Note: it can take up to a minute to get the voucher screen updated with the new voucher.

Voucher has a predefined value which can be different depending on the type of performed action (Onboarding = 500 PRP, triggering recharge the reward pool = PRP 100). Voucher is nominated in PRP. To get those PRP, one should claim a voucher which is akin to submitting a transaction “burn a voucher and get the corresponding PRP”.

Vouchers are grouped per type of action performed. Stage 2 will have two such groups - (1) Onboarding bonus voucher and (2) Recharge bonus voucher.

Vouchers can be claimed by group only, which means a user gets the total PRP for all vouchers in a given group. When claiming is completed successfully, a user will see an updated balance on his (a) Dashboard → Panther Rewards Points section → Available PRP amount and (b) Rewards page → Redeem PRP screen → Available PRP section.

Testing and providing feedback

As we mentioned, testnet rewards are automated, and as such, the testnet itself will reward users for going through the Rewards process. The goal for the testnet is to debug and enhance the Protocol before mainnet beta’s launch.

Our expectation is that users submit bugs and share ideas to enhance end-to-end functioning, interaction and usage of wallets, UI/UX flows, and let us know about any component that doesn’t look or feel as expected.

Status: Testing in progress

1. UTXOs joining on deposit:

The efficiency of the product is improved by maintaining the user's balance in a single UTXO during the deposit. This allows users to engage their entire balance in a single transaction, eliminating the need for additional MASP transactions to consolidate smaller UTXOs.

The dApp maintains the user's balance in one UTXO for optimal clarity and efficiency, following the preference to have a single large UTXO instead of numerous smaller ones. This structure allows users to engage any part of their balance in just one transaction, mitigating the necessity for a supplementary MASP transaction to consolidate smaller UTXOs.

When handling a deposit transaction, the dApp merges an available zAsset UTXO of the largest amount with the deposited amount, rather than initiating a new UTXO. As a result, the new UTXO displays the total amount collected.

1. zAccounts blacklisting:

The update introduces a blacklist functionality, aimed at ensuring compliance with legal standards while maintaining the core privacy features. This update enables blocking users reported as illicit by reporting agencies.. ZMs can now oversee and manage such request of discovery of any bad actor in their zones and take measures more effectively

The blacklist feature is designed to integrate with existing compliance processes aligning with Panther’s broader compliance mechanisms.

1. Diamond Proxy updates:

The necessity of implementing the Diamond Proxy architecture in the product arose from the issue of contract size limitations on Ethereum. In the old design, PantherPool held multiple logics such as zAsset activation, PRP claiming, PRP conversion, the main transaction and zSwap, ForrestTree, and some helper functions. As a result, the PantherPool contract grew to around 30-32 kilobytes, which exceeded Ethereum’s limit for contract size, set at 24.6 kilobytes. The team initially addressed this by offloading some logic, but this solution was insufficient for future scalability, particularly with the planned introduction of zTrade functionality.

The Diamond Proxy resolves this by allowing multiple contract implementations to be accessed through a single proxy. This proxy can delegate calls to different contract implementations as needed while maintaining a shared storage across all implementations. The advantage of this architecture is that it bypasses the size limitations by distributing the logic across smaller, more manageable contract pieces, ensuring scalability as new features (such as zTrade), are added to the protocol. Each implementation can have its own storage while benefiting from the shared core storage managed by the proxy.

By implementing this architecture, the protocol can not only overcome the immediate size limitation but also future-proof its infrastructure for new functionalities and scaling, ensuring smooth deployment and upgrade processes in the future.

1. Taxi ring buffer logic updates:

The Taxi functionality got a significant upgrade with the introduction of a ring buffer mechanism, marking a substantial improvement in blockchain data management. This update revolves around the implementation of a smart contract supporting two level-8 Merkle trees, each containing 128 leaves. The core innovation lies in its cyclical approach: as one tree fills up with data, the system seamlessly transitions to the second tree while resetting the first to an empty state. This process continues in alternation, effectively creating a ring buffer that optimizes memory usage and streamlines data handling.

On the smart contract side, the implementation is elegantly simple yet powerful. Only the root of the current active tree is stored, significantly reducing memory requirements. The contract autonomously manages the transition between trees, including the reset process, ensuring efficient and continuous operation. Meanwhile, the data management component has been enhanced to track the current location of used UTXOs within the trees and utilizes only the latest state of the Taxi tree. This approach eliminates the need to maintain historical data, simplifying data queries and substantially reducing storage requirements.

The benefits of this ring buffer update are far-reaching. By cyclically reusing trees, the system avoids unbounded growth of data structures, leading to optimized memory usage and improved performance. The simplified data management process results in faster transaction processing and enhanced scalability, allowing the system to handle a larger volume of transactions without a proportional increase in resource requirements. Moreover, the focus on current state rather than historical data significantly reduces storage needs and simplifies verification processes.

1. Strengthening UTXO Management with Enhanced Privacy, Key Rotation, and Nullifier Security:

The code has been enhanced to address key issues related to UTXO management, with significant improvements focusing on privacy, security, and compliance. A set of critical updates was implemented to tackle vulnerabilities in the system, particularly regarding how UTXOs are verified and managed through compliance provider public keys and nullifiers.

The addition of a UTXO secret random to the zAsset commitment addresses a critical security vulnerability in the protocol. This update prevents potential cheating on the receiver's root spending key, which previously allowed for unintended anonymous transfers. By implementing this change, we ensure that every UTXO's spending public key is correctly derived from the receiver's root spending public key, maintaining compliance with the protocol's design. This enhancement effectively closes a loophole that could have allowed users to bypass essential verification steps, thereby strengthening the overall security and integrity of the transaction system.

Secondly, the handling of compliance provider public keys was updated to allow for key rotation and secure management. Previously, if a compliance provider's key was compromised, the protocol faced risks of unauthorized access or transaction manipulation. Now, the system ensures that these keys can be securely updated, while still maintaining the integrity of UTXO tracking. This prevents any security breaches linked to compromised keys and reinforces compliance protocols.

Finally, nullifiers - which are crucial for determining whether a UTXO has been spent - have also been enhanced. The system now ensures that nullifiers are securely generated and tied to the UTXO secret random and compliance provider keys. This update allows compliance providers to compute the nullifier and verify whether a UTXO has been used, without revealing sensitive user information. If needed, compliance providers can open a data escrow to investigate specific transactions. This addition guarantees that UTXOs are correctly tracked, preventing the reuse of spent tokens and ensuring secure transaction validation.

Together, these improvements significantly increase the security, privacy, and compliance capabilities of the protocol. This ensures the system is robust against potential manipulations and capable of securely handling UTXO transactions, even with future token standards or compliance requirements.

1. Streamlining Codebase with BigInt while Enhancing Efficiency and Reducing Dependency on External Libraries:

The code has been enhanced by standardizing the handling of large integer values, transitioning to the native BigInt type instead of relying on both BigInt and the BigNumber library from ethers.js. This improvement addresses the previous inconsistency, where the combination of these two types led to unnecessary conversions, complicating the codebase and increasing reliance on external libraries. These conversions not only affected the readability and maintainability of the code but also increased the risk of bugs due to the constant switching between formats.

By focusing on BigInt for all internal operations, the codebase has become significantly more streamlined and easier to maintain. The use of BigNumber is now restricted solely to cases where it is essential for smart contract interactions, reducing the overall complexity of the code. This approach also helps improve performance by eliminating the need for continuous conversions between BigInt and BigNumber.

Moreover, this update prepares the system for future improvements, as BigInt is expected to receive better support and optimizations within the evolving JavaScript ecosystem. As BigInt is a native JavaScript feature, this change ensures the codebase is more aligned with modern JavaScript standards and future-proofed for long-term sustainability.

1. Enhancing Token Management by Improving Security and Accuracy in Token Type Verification:

This test version has been improved by addressing a critical issue related to the proper identification and management of token types. Previously, the system did not accurately differentiate between various token standards (e.g., ERC-20, ERC-721, or ERC-1155), which allowed users to potentially misrepresent the type of token being used in transactions. This lack of verification created a security risk where users could manipulate the system, falsely claiming a token type and benefiting from this misrepresentation. Furthermore, the protocol lacked the infrastructure to store or verify this token information effectively, leading to potential vulnerabilities as more token standards are introduced.

To resolve this, a new solution was implemented that introduces the TokenTypeAndAddressDecoder library. This library enables the protocol to decode the public input of transactions and accurately return both the token type and token address. Additionally, the zTransaction and zSwap facets have been updated to ensure compatibility with the latest circuit updates, allowing them to accept token type and address in a single signal. The library then decodes this signal, ensuring that token types are correctly handled during transactions.

As a result, the product now offers improved security by accurately verifying token types and addresses, minimizing the risk of system manipulation. This enhancement not only addresses the immediate security concerns but also prepares the system for future expansions, allowing it to handle a wider variety of token standards with increased reliability and efficiency.

Status: Testing underway

Panther’s test network is now live on Amoy, Polygon’s test network, and can be accessed . Due to this network change, users will need to complete the onboarding process again and activate their test zAccount. Users who are using their old accounts, however, will not have to go through PureFi credential process again and will be moved directly to the account activation. This is a one-time activity required to access Panther.

For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 6 introduces two core functionalities with some extra details on the impact to UTXO Selection:

Fees Testing

This release introduces the mechanism for charging different types of fees within the simulated testnet, including Protocol Fees, Network Gas Fees, KYT fees and KYC Fees. All simulated fees are paid from the Panther Gas account in tZKP.

AMM Refilling with Protocol Fees Testing

Simulated protocol fees collected during the testing will be deposited into the AMM’s pool of tZKP.

Limited Subsidy Rewards Testing

The production (mainnet) version of Panther Protocol may include feature that will allow to introduce additional rewards to partially or fully compensate costs like Network Gas Cost, KYC, KYT and Miner fees, in service of encouraging use of the platform. Stage 6 of our testnet simulates this feature for testing purposes.

Note: This feature is designed to cover only tZKP-nominated fees, and will not involved test MATIC or other native test network tokens unless using the relayer service.

For the current dApp, see the entrypoint. Each stage's entrypoint is deprecated in favor of the next stage.

Testing scope and stages

The following are the different stages of testing that users will undertake.

As mentioned, specific testing guides for each step will be released along with them.

More information on each stage can be found in the following sub-pages.

Note: As the protocol developer, Panther Ventures Limited is resuming the testnet after re-deployment on Amoy. Panther Protocol Foundation is finalizing the details of the reward mechanism and will ensure that testers are rewarded proportionally to their efforts and we expect all incentives will be distributed via airdrop.

Disclaimer

For the avoidance of doubt, tZKP, tzZKP, tPRP, test MATIC, and any other tokens mentioned in this announcement or within the product are for testing purposes only and have no economic value, nor can they be exchanged for value.

Participation on our incentivized Testnet versions may result in you earning rewards, but such credits are not represented on any blockchain as tokens.

What next?

See the testnet dApp current stage