Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
For the current dApp, see the entrypoint. Each stage's entrypoint is deprecated in favor of the next stage.
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.
See the testnet dApp current stage
Stage | Name | Functionality to test |
---|---|---|
ZK Batching.
Run a Panther node to batch UTXOs and insert them into the chain, using a browser-based Panther miner client.
User onboarding.
Onboard yourself to the Protocol. Create, register, and activate a zAccount, passing a KYC procedure (email/name only) using a third-party compliance services provider.
PRP rewards
Test PRP reward flow.
Depositing, adding zAssets, and wallet cold-start.
Deposit assets into the Shielded Pool. Test the cold-start functionality by running the dApp from scratch (either on a new device or a new browser) and accessing your transaction history. Use a faucet to access an additional test token.
Intra-MASP transfers and withdrawals.
Send zAssets inside the Pool from one zAccount to another, withdraw zAsstes from MASP to EOA.
"Taxi" and transactions via bundlers.
Use bundlers to interact with the dApp. Check the “Taxi” option to push your UTXO into the chain as soon as possible (more time-efficient, less price-efficient).
Stage 6
Fee Management, and zAccount renewal.
Protocol fees. Test the zAccount renewal function (after expiry date). Disclosure function where txn can be verified by a 3rd party
DeFi swaps, Basic disclosures, more supported assets.
Swap zAssets via external Swap protocols using Panther. This test version has adaptors for Uniswap V3 and QuickSwap on Amoy ( Polygon test network). Data Escrow storage part and updates to History screen is also part of this Stage
Stage 8
Technical Enhancements
List of technical enhancements to upgrade the quality and scalability of the code base
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:
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.
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!
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.
This is retained for reference only, the IPFS link and Gdoc for this stage are no longer supported.
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.
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.
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.
To test at this stage, follow the steps below.
Visit the miner test page.
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.
Check that you’re receiving rewards correctly.
Stop mining. (Note: the miner will finish the ongoing iteration before entirely stopping).
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
At this stage, Users will be testing:
Claim PRP voucher
View private balance on the Dashboard
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.
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.
For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.
Status: Completed
For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.
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.
To deposit a regular asset a user should:
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
Select the token to deposit if it is not preselected, or adjust your selection via the token selection modal window.
Enter the amount to deposit.
Click the Deposit button and complete the transaction.
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.
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).
Internal Transfer:
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.
Set the amount.
Choose the token.
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.
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.
Push the Send button to initiate the internal transfer.
Withdrawal:
Navigate to the Withdraw screen through:
Top main menu - zAssets - Withdraw screen,
Dashboard - Private zAssets section - token line - token management buttons.
Set the amount.
Choose the token.
Manage UTXOs as needed.
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.
Push the Withdraw button to initiate the internal transfer.
Stage 5 features
Status: Testing underway
During the Stage 5 test phase, the Mumbai network was fully deprecated, forcing the test dApp to transition to Sepolia.
Stage 5 introduces two core functionalities with some extra details on the impact to UTXO Selection:
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.
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.
Navigate to any the transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.
A new Bundler toggle is available for selection between a YES or a NO:\
Navigate to any of transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.
A new toggle to select Processing Type is now available.\
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.
For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.
Panther uses to process newly created UTXO in batches instead of individual UTXO commitment updates enabling lower gas cost for the transactions involved in this batch.
2a. Bundler = YES 2b. Bundler = NO
2a. Processing = REGULAR The functionally is the same as per previous stages since transactions are processed by zMiners. 2b. Processing = FAST
The updates here can be seen only in some cases and only for a few minutes when you have a newly created UTXO from a FAST (taxi) transaction. In the following screenshot, you can see a UTXO (in the UTXO selection modal) that a balance of 0.22 zETH is locked and not available for selection. This UTXO was just created from of a FAST transaction and while it can be spent individually, it can't be mixed with other transactions. Because, the user in this example has selected an existing UTXO, the dApp locks the UTXO created by a FAST transaction. This lock only applies for a few minute until the next zMiner runs and after that you wont see the lock. UTXO's that can't be joined by other UTXO are identified by a lock icon and with the reason, "fast output" icon.
For more information on zMiners, see the .
Status: Testing underway
Panther’s test network is now live on Amoy, Polygon’s test network, and can be accessed here. 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 entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.
Stage 6 introduces two core functionalities with some extra details on the impact to UTXO Selection:
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.
Simulated protocol fees collected during the testing will be deposited into the AMM’s pool of tZKP.
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.
Status: Testing in progress
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:
Route: By default, the product selects the best route, but users can change this option based on their preference.
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:
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.
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.
Slippage: This parameter, set by the user, defines the acceptable difference between the expected price of an asset and the actual trading price.
Minimum Received: This represents the guaranteed amount the user will receive, taking the slippage parameter into account.
Ratio: This likely refers to the exchange rate or conversion ratio between the swapped assets.
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.
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.
\