Amazing to see the work taking great leaps forward!
Can we know the auditing firm? @Dermot
5 Likes
Proposal: Could we possibly consider referring to it as simply POKT, rather than wPOKT?
Justification:
-
The term “wrapped assets” does not automatically denote the same meaning as “bridged assets”. Wrapping of tokens can occur within the same chain. For instance, standard ERC-20 $POKT on Ethereum could be wrapped into an incentivized $wPOKT by a non-standard ERC-20, similar in nature to tPOKT.
-
If we stick with the process where $POKT (mainnet) is wrapped into $wPOKT (ERC-20), this would imply another wrapping of the already wrapped asset when it’s bridged to other chains (Binance, Polygon, etc), resulting in $wwPOKT.
-
It’s likely that user experience will be enhanced by maintaining a consistent token name ($POKT). Users would simply have to select from familiar chains, with the token name remaining constant. Furthermore, centralized exchanges (CEXs) would not have the added task of clarifying that $POKT can be deposited by sending $wPOKT on the ethereum chain.
-
In my opinion, there isn’t any intrinsic benefit in assigning a “new name” to assets when they move outside of the mainnet. On the contrary, it could potentially confuse users (for example, how they could purchase POKT instead of wPOKT).
4 Likes
Could we integrate with https://twitter.com/axelarcore/status/1669382878101229568 to reach crosschain swaps. It seems to become the goto solution between many chains. Recently uniswap (pancakeswap, osmosis et al) jumped onboard.
1 Like
Hey @spenc
This is an interesting point. And it is true that more and more cryptoassets still use their original ticker on other chains. Stablecoins are an obvious one, but ETH - largely speaking - is too.
I’m keen to explore this further.
Our new Head of Marketing starts next week, and she should have some good insights into whether or not it helps from a marketing perspective to refer to “wPOKT” or “POKT” (but on a different chain).
4 Likes
We explored using Axelar as part of the original scoping exercise for wPOKT, as this was an option that Olshansky - amongst others - was particularly keen on. However, we ended up ruling out Axelar for this initial version of wPOKT for two main reasons:
-
The v0 Pocket blockchain does not have the threshold multisig functionality required to work with Axelar, so we would need to divert some of the protocol team’s resources to ship a new protocol upgrade. This is a non-starter for us. Shipping v1 sooner is a much higher priority than shipping a more trustless bridge.
-
Using Axelar would require additional custom development and testing, meaning a longer time to launch wPOKT. And I think we all want to experience the benefits of wPOKT sooner rather than later.
It’s a great question, though, and it’s a top priority for us to integrate with Axelar - or a similar solution - post the launch of v1. Having a more trustless bridge is also much more aligned with our overall strategic thesis of helping Pocket to become unstoppable across every dimension.
3 Likes
Just one thing to mention while I consider “launching POKT on Ethereum” slightly better terminology, I don’t mind using wPOKT from marketing perspective. What worries me is that this terminology got into the smart contracts, where we should imho prefer single standard ($POKT).
1 Like
Just wondering, have you considered using Starknet in order to reduce fees? That way you would be able to submit tx to Starknet L2 that’s significantly cheaper and you would not need to care about submitting batch tx to L1, while users would be able to mint their tokens (and actually pay lower gas fees).
There might be also some room for improvements in the smart contract - for example you can compress data by hashing rather than passing uncompressed input (that’s imo anti-pattern).
I’ve did some work related to token bridging in the past (and it was audited). If you would like I am happy to jump on the call and share some tips.
1 Like
We considered Polygon, Arbitrum, and Optimism, amongst the many EVM alternatives to Ethereum, but none came close to Ethereum when evaluated under the lens of the dual purposes driving this project:
Starknet has some interesting technology, but it doesn’t (yet) have the DAO/Defi infrastructure and/or liquidity we need for POKT right now.
We already have certain community members reviewing the code as it progresses, but it’s all available so if you are interested in reviewing the smart contract, we would love your input. See below:
3 Likes
I think it’s a little strong to call this a worry! Non-EVM tokens when represented in the EVM ecosystem - from wBTC all the way onwards - are typically prefaced by “wrapped” and the shorthand of “w” in their ticker. So this isn’t particularly unusual nomenclature.
In any case, we still have plenty of time to decide. And whatever decision that we make will be a thoughtful one.
4 Likes
I didn’t mean to launch token on Starknet, just to deploy mint controller on Starknet. For instance, if you want to mint tokens on Ethereum, you need to have centralised layer that will handle batching, gas fees and possible tx failures. With controller on Starknet, you can submit withdrawals as they occur and they will handle batch submission to L1.
If I understand it correctly the current wPOKT implementation mints tokens directly, which means the fee burden is on the controller and it adds complexity of capturing fees properly. It can be more efficient to move that burden on users, specially when you want to decentralise this flow (eventually).
For instance, when the user requests bridging POKT → Ethereum you can store the payload off chain (browser, centralised db, etc), while you only submit it’s hash to L1. From the controller perspective it means you only need to write bytes32 message on chain (very gas efficient). The cost of minting is then transferred to the user as he needs to provide uncompressed payload. This payload (address, amount, nonce) is then hashed again and if the hash is present on chain you can safely consume the payload which allows end users to mint tokens and cover the fees.
It’s basic cross chain messaging concept and it’s doable without Starknet - Starknet just removes the overhead of dealing with L1 directly. You can just deploy a controller contract on Starknet and the only thing it does is message forwarding to L1, so when your message is accepted on Starknet you can be sure it will be correctly delivered to L1, where it can be consumed by users.
Another reason why this might be a good choice is it might be easier to decentralise it. Right now, the controller can be operated let’s say by centralised key pair stored on cloud (HSM). In the future you can change this - implement something like Threshold BLS signatures into v1 or let pokt validators to verify proofs before L1 state can be updated.
Or you can actually deploy your own “starknet” on top of Starknet and thanks to recursive proofs you can efficiently transfer information that will be proved on L3 (PocketCairo) by POKT Validators through L2 to L1. It can work even vice versa, transferring burn information from L1 to L3, where again validators can verify such information and unwrap it on POKT chain.
The above are just ideas, it strongly depends on the direction how IBC will be implemented in v1. However, passing compressed (hashed) messages between Ethereum <> POKT seems to be slightly better option as it’s gas efficient and it’s simply more universal for messaging (doesn’t have to be limited to just mint/burn).
4 Likes
Sorry for the delay in getting back to you.
Very interesting points. And all will definitely be up for consideration as part of the next version of wPOKT, so I’ll reach out as soon as the planning phase for wPOKT v2 starts! IBC should be a massive help, and the general state of the art when it comes to bridging should also be much more advanced by the time that v1 launches too.
4 Likes
I’m just curious what the next version of wPOKT means? Will that be like another ERC-20 or is it more like upgradable controller (v1/v2/…)?
1 Like
Although the token itself isn’t upgradeable, everything is on the table, and we are open to a token migration in the future if that will deliver the most impact to the community. However, our priority for the next version of wPOKT is more about upgrading the back-end to be more decentralised by removing any reliance on any third party. For example, the spec for the wPOKT smart contract includes the following for access controls:
- AccessControl Wallets:
- DEFAULT_ADMIN_ROLE: granted to a Safe multisig controlled by POKT Foundation + POKT community members
- MINTER_ROLE: granted to Minter contract which is owned by the Copper sharded wallet
- PAUSER_ROLE: granted to POKT Foundation member
So you have them to hand, the technical specs are linked below:
Happy to chat in DMs if you have any further questions
3 Likes
Sharing this update to the main post for full awareness on changes to the spec, the updated timelines and what’s up next on the roadmap
5 Likes
Axelar is one option but it still requires bridge infrastructure. Another option could be designing the token specs/metadata to be compatible with layer zero protocol. Going that route might allow for the community to get an airdrop from onchain activity after they bridge or qualify the dev team to earn a grant for building things on layer zero protocol. I get that Eth has the big bucks but Arbitrum seems like a good compatible and cost friendly option to pursue for the v1 launch. We all took a hit with the decline in valuations no need to exacerbate the pain with eth gas fee volatility. Also there is a wpokt token already on eth and polygon what will happen to those holders? Would a migration to the new contract be the correct play for better user experience and retention?
3 Likes
It also requires an upgrade to the protocol to enable M-N threshold signature aggregation, which is why Axelar, along with other bridge options, will be part of the consideration for future iterations of wpokt.
This is a good point, but it’s important not to look at wPOKT as a monolith.
We are going with Ethereum first as it is where most of the liquidity is (Uniswap’s volume on Ethereum is c.4x what it is on Arbitrum) and where most of the DAO infrastructure we initially want to integrate with is too.
The next iteration will most likely be on Arbitrum and/or Polygon, as accessibility is a key consideration as you rightly point out.
I’m not sure I understand. Are you asking what will happen if we want to launch on Arbitrum in the future? If so, the bridge has been designed modularly to make it very easy to support bridging to other EVM chains. I’ll leave the exact implementation details to the technical experts. Still, as every wPOKT token is backed by 1 POKT token, there will be no need to upgrade the wPOKT token on Ethereum to integrate any new chain to the bridge dapp.
4 Likes
PNF will share a proposal for a wPOKT Uniswap LP liquidity strategy to the forum for consideration in the course of w/c 7 August (if not before)
looking forward to updates 
1 Like
Latest update on timelines and what’s up next on the roadmap
7 Likes
how was the feedback?
Finalise wPOKT audit by august
2 Likes