ORC-8 The Session Network Token #36
Comments
|
Thanks for publishing the plan! The motivation seems clear to me, and I'm looking forward to more details. There are some immediate questions come to my mind, would be nice to have some discussions:
Looking forward to further discussions and clarifications. Edit: Private purchasing of ONS by bridging the legacy private OXEN token Imagine a user purchasing an ONS name for their Session ID. If they use a transparent token to make the purchase, their tokens are likely from a KYC-ed exchange, and their Session ID would be connected to their real-world identity. However, if they use a privacy coin to purchase the ONS name, then they can maintain their privacy. Technically, it might be possible to implement a dual-stack architecture, allowing users to decide whether they want to purchase an ONS mapping using the new transparent Over time, as users become more educated, there might be a gradual migration towards the legacy private coin. It's important to avoid completely shutting down the legacy private version, as it could lead to a one-way path with no option to revert. Politics is full of change and drama; what is discriminated against today might become a new fashion in a couple of years. I believe that our mission is to keep the project alive for long enough, potentially decades, and preserve the flexibility of optional privacy coin, until the day we see the light again. People will eventually awaken and fight for their rights. There are several potential outcomes:
Overall, it's crucial to keep the project adaptable so we don't miss the potential opportunity of reviving the privacy coin. I'm not worried about the long-term huge demand for the project. My concerns are more about irreversible short-term decisions. Hence, I hope we can consider the dual-stack approach. Please let us know how we can contribute! Edit 2: Lean-startup style token transition Imagine a user who has already purchased the new EVM Thinking more about it, For most use cases, a one-way conversion from This approach isn't to oppose a more fundamental transition to EVM tokens but rather follows a lean-startup mindset of gradually migrating the ecosystem to EVM. By fully utilizing the wrapper EVM token in the early stages without overhauling the fundamental infrastructure, we maximize potential gains while minimizing costs and risks:
By adopting this approach, the transition to |
|
Thanks for posting this ORC. It is an interesting proposal. I share @venezuela01 concern about the new SENT token being a transparent token. That would severely impact the privacy aspects of Session. To avoid that in the short term, I think you'd need to look at the newest chain that Aztec is developing that will have smart contract functionality as well as public and private state channels. That said, the last bit I read (a while ago) said that the new Aztec chain won't be EVM compatible b/c their research has shown it really isn't possible to have private state on an EVM chain. Anyway, these are just my initial thoughts after reading the ORC. I'll think on this some more and I look forward to hearing more details. |
|
I also agree with @venezuela01 I would prefer a dual token approach. Move everything over to SENT as planned, stop minting coins as planned, but leave the Oxen blockchain as a side chain that people can move in and out of for private transactions. Ideally controlled natively by service nodes. If private transactions are removed completely I can see many people dumping the coin, we just have to look at how many people stopped using Kucoin once they implemented KYC to verify this. Oxen holders have strong convictions in privacy. I understand and agree with the plan but to remove private transactions completely would be a grave error in understanding of who Oxen holders are. |
|
On one hand, I see the desire to streamline access to Session and it's infrastructure for mainstream consumption and for those without the time or desire to learn something new. That makes sense for business and for marketing, it should help with adoption of Session. On the other hand, the ORC implies a decision to abandon privacy to chase profits. At least, many like myself will read it that way. I don't think "nobody wants to work with a privacy coin" or "regulation-related delistings" are going to be received as winning arguments. Considering both hands, the compromise point is going to be maintaining privacy while also cucking to the regulators and probably some investor somewhere. If an "EVM-compatible Layer-2" is what's been decided already, then it's going to have to be some sort of ZK or similar implementation. Marketing-wise, this can be spun as "moving from ring signatures to zero-knowledge proofs" and most people will be fine with it. We might even get a bump from the Layer-2's marketing as an example of adoption of their network. One final thought: Would it be better to get OXEN supported by ChainFlip and work together on launching their DEX with the existing token? I understand there are personal and business-related issues with achieving this, but Oxen's Service Node operators were early supporters of their network and many of us will be running ChainFlip nodes with the tokens received as part of that early support. They have already stated plans to support Monero, doesn't that mean they're okay with privacy coins? Of course there would be considerable development resources needed to pull off a DEX integration, but that's also true of ORC-8 in general. Thanks for all of the excellent work and massive amounts of time that everyone has put into Loki, Oxen, Session, etc. It's really important work and it's a meaningful contribution to the next chapter of telecommunications infrastructure. If we abandon privacy on the incentive layer, so be it and I'll still be here anyway. If we can avoid that, though, it would be better for everyone. Edit: typos and clarity Some specific points of concern for moving away from being a privacy coin:
|
@dis7ant, I agree with this point. In my earlier reply I had mentioned Aztec's latest work, but the more I think about it, the more it possibly makes sense to fork their older Aztec Connect repo and launch our own L2. Aztec Connect was "the encryption layer for Ethereum". It was much more flexible than privacy protocols such as Tornado Cash. It also allowed for batch transactions so users could interact with DeFi smart contracts on Ethereum mainnet while maintaining privacy. The Ethereum community was pretty upset when Aztec decided to cease operation of Aztec Connect and instead build a new separate chain. I used it a lot to move funds from one Ethereum mainnet address to a new one without linking the two addresses. If the team proceeded with forking Aztec Connect the community could maintain privacy via shielding their ETH and SENT on the new forked L2. ETH could be used for the L2 gas and of course for the sequencer to pay for batch transactions down to L1. SENT could live transparently on L1 as well but then could be bridged to the new forked L2 to shield it and then use it there to pay for Session premium features. Operators of Session service nodes could shield their SENT on the L2 and could sign 'staking transaction' messages that lock some amount of SENT along with information about which service node the coins are staked to. @KeeJef, these are just high level thoughts at this time but I would definitely recommend looking into forking the Aztec Connect repo and running your own L2 to replace Oxen mainnet. Your research may uncover issues that may not make it viable, but if it turns out to be workable, I think it would be a win-win.
|
|
Hi ! A have 20 SN. I bought for this OXEN. I'm not going to close them. But I wonder -how much will I lose? |
This question is mine as well and will likely be on the top of the list for many SN operators and stakers. Along with - for everyone having been on board for a while and seeing the OXEN value fall and fall - "how much more do I want to lose". If you want to prevent lots of people unstaking in the next days and thus destabilizing the whole SN network simply because they feel they better limit their losses now, you might want to be a bit clearer on that topic than "we are still working out the details" and "we’re planning to have large incentives". |
|
Thanks for the comments thus far, i'm going through them now
In my view SENT should not be a privacy token and should be a transparent ERC20 token. This is for a couple of reasons:
In saying all of this, I do still believe in privacy at the currency layer, however my view of the future of SENT is that this privacy should be enabled by EVM specific privacy tools. For example Tornado Cash, Railgun, Aztec, etc. To give an example, currently a user who has Ether which they bought from a KYC exchange can mix their Ethereum using Tornado Cash, they would then be able to use this mixed Ethereum to buy SENT via Uniswap and purchase an ONS or pay for Session Pro. This is just one way a user could get more privacy on Ethereum and I think it's likely that further development happens in EVM land to build additional tools like this. I think it would also be possible to seek deeper contract level integrations with privacy tools allowing interactions like purchasing ONS names to happen privately. However, this is an open field which we need to explore more.
There will likely be a period where we need to maintain a dual stack functionality since I think this would be the best way to migrate (keeping the Service Node state on the Oxen chain and representing the user balance state on EVM chain) however I think this should be a one way migration (users can migrate to OXEN -> EVM but not visa versa). Otherwise we are going to need to keep maintaining the wallets and Oxen transaction ecosystem. Maintaining the wallets is not a trivial exercise and if wallet experience is suboptimal we will see very little usage of Oxen (this is already the case, actually) with only a handful of actual Oxen transfers occurring on a daily basis, limiting the practical anonymity set of Oxen. Another plus to unidirectional migration is that once migration is complete we can essentially prune the entire Oxen blockchain, freeing up ~18gb of space for Service Nodes to store Session related content and lower the disk space requirements for new Service Nodes. However I think the most important reason is that once this migration occurs we aren’t going to be innovating on the Oxen transaction chain anymore, we are going to be devoting our development efforts to building Session and Lokinet. We aren't going to have time to implement new transaction privacy methods like Lelantus, Serpahis or other ZKbased privacy protocols or improve UX on the Oxen chain, this will leave the transactional privacy elements on the Oxen chain lacking when compared with state of the art protocols, and i think that will greatly limit usage compared with projects which focus on transactional level privacy.
Currently our biggest challenges are around building the decentralized bridging and operating mechanism between the Oxen chain, and the EVM chain. Long term our primary idea on how to achieve this is to maintain the Oxen chain as the “Oxen workchain”, with the Oxen workchain tracking only the state of the Service Node network, including pending rewards, deregistrations, decommisons etc… Then having this state periodically snapshotted and posted to the Ethereum network. This snapshot would contain a BLS signature from some threshold of the node network and would update the state of the EVM contract so users could claim rewards. In the reverse direction Oxen workchain nodes would also subscribe to RPC endpoints for the EVM layer 2 or run their own EVM L2 node to fetch events which occurred on the EVM chain and then form consensus about this events by communicating with each other, this would allow staking to occur from the EVM chain. Currently open problems are around the efficiency of this snapshotting method, Large threshold BLS signatures +2000 plus signers and EVM contract validation of these signatures, smart contract design etc… There are also several open problems around how witnessing events of the EVM chain would occur and how we would come to consensus about those events on the Oxen workchain, tokenomics questions, branding etc…
At the moment we have legal advice limiting the information we can share about prospective tokenomic plans. However, transitioning Service Node operator, and Service Node contributors over to SENT is one of our top priorities and we are investigating the best way to ensure operators transition across networks. We will release further information on how the migration process will proceed as soon as we can, with particular emphasis on the Service Node network, given its critical role in maintaining Session and Lokinet operations and securing a successful transition to SENT. |
|
Please let oxen fly on the stellar decentralized exchange, especially using the latest soroban smart contract launched by stellar to realize more governance tokens and web3 connections and other functions. More importantly, stellar tends to embrace regulation, reduce gas rates, and enhance the ease of use of the blockchain. I believe that oxen's privacy construction combined with stellar's compliance will have unlimited development potential. |
|
It seems to me that the decision to switch to SENT has already been made. As the most attractive business model. OXEN will be done away with. Perhaps it's the right thing to do. |
|
I will probably keep my Oxen staked. The whole point of the Lokinet and Session is to work OUTSIDE of their damn constructs. I used to teach maritime law and I can tell you this.. You do NOT have to obey. Stay focused! Build Lokinet, Session and the OXEN coin monetization the way it should be, NOT how "they" say it needs to be. Do it right! #nofear |
|
Not trying to shill here but I think you should look into making a custom chain with substrate on Polkadot. This could be the best of both worlds - having a custom feature set, fee model, etc. while being interoperable with other projects and having access to liquidity. EVM compatibility and bridges to Ethereum, Bitcoin, and other non-polkadot blockchains are all plug and play features of substrate and Polkadot. Substrate also has modules for ZKP and there's a lot of demand for more hardcore privacy focused chains. Could be a perfect fit. |
|
Given the history I can't help but wonder how much of this discussion is actually aimed at getting feedback. We had similar discussions before and very little if any of the community recommendations were taken into account. In the spirit of changing winds I'll give this another try hoping it does not fall on deaf ears. I'm not against switching to an Ethereum token. However, I do not think the proposal addresses the underlying issues of Oxen. I've voiced my opinion before and will do it once more. The infrastructure of the network provides is essential to the existence of Session and Lokinet. However, the economic model upon which Oxen was built is flawed. It has been flawed from the beginning when assumptions about the growth were simply wrong. It took a few years for it to finally take effect, yet here we are. The entire idea of Sybil resistance is based around the economic model. It is not the exchanges fault, nor is it the privacy aspect of Oxen. The underlying issue is the constant coin inflation that makes service node operators suffer impermanent loss and incentives constant selling to cover the loss on value of staked coins. The idea that this would be offset by burning is just flawed. It never could and never will as long as it is optional and not enforced by the protocol. Everything the infrastructure provides is free but in reality comes with a cost reflected on the price action and liquidity. And here we are, a few hundred nodes staked, all operators with net loss on their investment yet continue to show support. It kinda sounds like they are doing this out of altruism, and not financial gain. Kind off sounds like Tor don't it? Did we go full circle? I strongly believe unless this changes, the project is doomed to fail. The community will only support the network for a limited time if all we get is digital numbers worth nothing. As long as the application layer of Oxen can be used freely there are no incentives to use the coin. I refuse to believe a team of such smart and technical people does no grasp the detrimental effects this has had to the community that supported for the project for so many years. Acknowledge the issue, apologize for not listening to the community and not being transparent about why this was not addressed sooner!
This requires a lot more information and details. Is static equal to fixed supply? How would that even work. Where do the rewards come from? What is the economic model? Simulations?
Running a local EVM L2 node introduces on service node operators but it seems like it is the only realistic option. Using public RPC endpoints will likely create more problems with availability and reliability unless paid for. I would expect some technical report on the resource requirements of running a local EVM L2 node alongside Oxen node before the decision is made.
These are all valid points, yet the elephant in the room is not addressed. Who would pay the gas fees for the signature validation? Security comes at a cost, we can not simply borrow the security Ethereum provides without paying for it. Moreover the change in tokenomics is fundamental to this transition yet none is presented. Not even ideas? This looks very much like a half baked solution to a localized problem that does very little to address the actual global problem. If the community is expected to sacrifice privacy it should be clearly presented what we are sacrificing it for. Exchanges, integration, interoperability are just buzzwords with no substance that do not address the main issue at all.
Having been involved with the space from a legal perspective my self I can relate to this somewhat. However, we can talk about ideas and not plans. Voicing ones opinion on what is being looked at and researched does not impose any legal obligation. We should be more open and transparent with regards to ideas being explored. Whether or not those are legally acceptable is another topic, which can be addressed at a later time. Finally, I would like more emphasis be put on the economic model of SENT. It is now undeniably evident a constant coin inflation is destroying the market and forcing service nodes to abandon support. If a fixed supply model is being considered we should be open about it and discuss more on how that would work both in terms of technical issues as well as economics. I would suggest the team takes some time to formalize this proposal more clearly before requesting community feedback. Perhaps the correct way to go about it is to decompose it into smaller technical and economic obstacles that need to be addressed. Address those first and then put forth a proper ORC that clarifies the necessary changes. |
Can't argue with that, it's also the primary weakness of Lokinet in general compared to Tor. An argument could be made that moving to a massively-used transparent infrastructure with privacy tools like Tornado Cash could actually help with anonymity, if used properly. I don't know if I'm sold on that being true, but it's an interesting point. If the privacy of OXEN is weak anyway compared to competing privacy coins, why not focus on being a really good private communications network instead of focusing on being a private payments network...that makes sense to me. After all, people are going to just send Monero over Lokinet and Session instead of OXEN or SENT. May as well directly integrate Monero payments if it's going to be used for that anyway, and compete with whatever Elon and Jack's messaging-app-with-payments-infrastructure ends up being. Dissecting the additional Layer-2 EVM comments: Other thoughts: |
|
Lyrical introduction))) Specifically on the issue.
In general, I hope that the team understands that SENT will not solve the liquidity problem. Yes, this will reduce the cost of developing the Oxen core, but again, the development of Lokinet and Session, as I understand it, was carried out at the expense of a certain value of Oxen, but in order for the SENT token to be able to make a profit, it must first be promoted. PS: I suppose that as a result of the OXEN exchange for SENT, within a few months this token will show its non-viability and the further development of Lokinet and Session will have to be carried out only through donations and paid services. Glad to be wrong, but I don't see under what conditions SENT can save the situation. It is quite difficult for me to express my thoughts, because of the low level of English proficiency, otherwise there were more nuances. |
|
The team claims that we can't compete with other privacy coins unless we 100% focus on that. I'm going to agree that aren't able to complete in our current position. However if the team had substantially more funds and substantially more transactions for decoys then we could compete. The team needs to;
The team needs to commit to;
This commitment should be actioned when;
If sending transactions through Session becomes popular with users then the coin can be transitioned into a dual stack privacy-coin/token. The token can continue to be accepted by exchanges as it isn't seen as a privacy coin and transactions through Session can become private without anyone even noticing. Does anyone else support this? |
|
I support ORC8 as written. I have been participating in Loki/Oxen since launch and currently have 6 solo Snodes. I have always felt that this is one of the better projects in the space and has two very useful applications for web3. The project needs to find a way for mass adoption and monetize it's app's more effectively. When the Chainflip announcement came I was very excited that there would be more opportunities but that has yet to occur. Having a specific token that is easy to access would be a great benefit and could lead to wider adoption.. |
|
Many CEX lists will help the project grow. |
We have not been flying blind here, everyone is on the same page here about needing to find long term ways to offset new coin emission. The primary way we believe to do this is to monetise our successful applications (Session/Lokinet). If we can convert a small amount of the users of these applications into paying users and market buy and burn Oxen/SENT with those funds then we can effectively offset the newly emitted coins which are paid to Service Nodes to preserve network functionality. This has been the plan since at least 2021, and its the direction we are moving in currently.
One of the broad ideas here (subject to change) is to hard cap the supply of $SENT and construct a rewards pool, this pool would start with an initial balance of say 100 $SENT, it would pay out say 15% of this $SENT per year given the total size of the pool was either <= 100 $SENT. Given no new funds flow into the pool every year the amount of $SENT paid out of the pool would reduce over time and subsequently so would the operating Service Nodes on the network. However this would be countered by $SENT flowing back into the pool, through Session/Lokinet monetisation. If the pool exceeds 100 $SENT then it would pay out rewards in excess of the 15% per year to encourage growth of the network. This all works while keeping supply fixed and forces a timeline on monetisation given the reducing rewards. None of those numbers should be considered as final, but thats one of the basic ideas.
I think we would give operators a choice on this one, whether to run a local node or subscribe to an EVM RPC endpoint, thankfully i think the actions which we we would be witnessing from the EVM chain would be fairly low volume (staking transactions, unlocks and maybe a few others) its likely that these events could be witnessed without exceeding the free tier options of the larger RPC providers (rivet, alchemy, infura etc...) however for local node operators this requires more investigation on resources required.
These are questions we are trying to answer now with a prototype implementation, however i can give you some insight on the ideas here, a snapshot would be a BLS signed representation of some element of the Oxen workchain state, that could either be a low defintion snapshot of all of the Service Node balances or the exact balance of a specific Service Node. For me the specific implementation i am liking right now is that the service node network produces low definition snapshot of all Service Node balances once every 24 hours, this includes an aggregate BLS signature and indexes for all signing parties. This snapshot is available via RPC from the Oxen workchain to anyone. Unlocking Service Nodes can grab this snapshot and submit it to the EVM chain for validation, the unlocking Service Node pays the fees for validation of this snapshot, validation can occur onchain because Service Nodes register their BLS pubkeys onchain when they stake and smart contracts can somewhat efficiently validate BLS signatures with a large number of signers https://geometry.xyz/notebook/Optimized-BLS-multisignatures-on-EVM. Given a threshold of nodes signed this snapshot it would update the state of a contract which contains owed rewards for each Service Node. Once this update is complete Service Nodes stakers can claim $SENT from that contract equal to their owed rewards, even if they didn't submit the snapshot update themselves. Gas costs are the primary concern here, but since we would be on an EVM L2 these are less relevant, I'm not yet confident claiming a Gas amount which would be required to execute an snapshot update, but we are hoping based on our investigations that in the worse case naive BLS validation, usage would be under 7m GAS which would be around 1.5$ on most L2s. However I'm hoping we can get this number under well under 7m Gas.
These are not just buzzwords, i have spoken to many investors over the past few years who have chosen not to buy Oxen because of these reasons, including, no hardware wallet integration, not on big enough exchanges, not interoperable with Ethereum, poor wallet experiences etc... I don't think this is the primary reason that people choose not to buy in Oxen, but it is one of the major reasons. |
|
EVM? Gas fees? Smartcontracts? Privacy? |
Is this a philosophical point? If you mean this literally i don't understand the claim, of the top 20 market cap projects 6 of them are non native tokens issued on another blockchain, there is billions of dollars locked in tokens issued on "Someone else's blockchain"
I can think of Toncoin as atleast one example of a very successful ecosystem integration, although not directly comparable to $SENT i think this shows one of the best case scenarios for ecosystem integrations, and proves that this concept can be successful.
I think it would be wrong to issue $SENT on Ethereum, to keep fees low i think we should issue on an Ethereum adjacent EVM L2 or L1, average transaction fees on most L2s have never peaked past a few cents for simple token transfers.
I think the end goal would be to accept any fiat or crypto payment method for Session pro and then convert this to $SENT on the backend, but potentially offer a discount for users who subscribe using $SENT directly.
I think if we make the full transition to an EVM layer 2 then the onchain DEX's will be the highest volume markets, and yes i think those pools would have increased liquidity compared to wOxen. The barriers to entry will be far lower for LP's wanting to make markets on a L2 given lower fees and more liquidity will be available from native token holders since all $SENT holders will be on the same chain.
The point is not that centralised exchanges will line up automatically, but that it becomes practically much easier to list $SENT from both a regulatory perspective and an development perspective. From a regulatory perspective exchanges have no issues with the privacy properties of ERC20 tokens. From a development perspective integrating a new ERC20 token is often just a few lines of code, vs potentially thousands of lines and hours of development time if the exchange doesn't already support something similar to Oxen like Monero, and even if it does, there are still important differences which need to be communicated and understood.
I think the difference here is that Dash hasn't built a highly successful product like Session to lean on, their currency is their whole project so removing/minimising features of the currency hurts the future performance of the project more. This ORC leans more on our most successful products like Session & Lokinet and integrates the coin and project into a singular brand. |
On the one hand, this can be seen as a philosophical moment, but on the other hand, this is a statement. Almost all TOP projects are very successful commercial projects, but calling them independent and decentralized can only be a stretch. The blockchain itself does not have the necessary properties that Nakamoto once spoke about, the important thing is how the blockchain is implemented. For example, CBDCs are also built on the blockchain, and most cryptocurrencies are similar to CBDCs, they are simply controlled by a small group of businessmen, and not by the state).
This question follows smoothly from my previous thesis.
PS: Once again I want to repeat that I'm not trying to criticize, but I just want you to take a balanced approach to making a decision and study all the problems that may arise. |
|
I don't support this direction to replace oxen, I held oxen because I believed in the need for a coin like Oxen. A coin that is inherently private, not an energy waste and allows for fast transactions. It is why I consider it technologically superior to Monero. Moving away from that to be yet another non private ethereum token means it looses its value to me to the point i'd rather have something else. I liked the coin as it was, if it just becomes a non innovative trackable token it holds no value to me to the point where I will be selling all of it. Ideally run them in parralel with a 1:1 swap so that people who value what oxen is can use oxen. |
|
@henk717 I agree with your point of view but I also see where the team is coming from. In my opinion the main problem with Oxen as a privacy coin is that the anonymity set is too low. We need more people using Oxen for it to be a good privacy coin. That is why I urge everyone who wants Oxen to be a privacy coin to support my proposal in this comment as a compromise between what we want and this ORC-8. |
|
The last thing I'm going to say on the topic. If the community isn't interested in the compromise I wrote above (that would be my proffered option) then I'll support this ORC-8 as is. |
|
These are sad but not surprising news. I've always supported the Loki project and publicly discussed on discord, with Kingsley and KeeJef against the Loki rebranding to Oxen. Nevertheless, I kept my full support to Oxen, despite not agreeing with it. And this leaves me to the current situation and is based solely on my personal opinion and I'm not taking in consideration (not even aware of) of the amount of work needed, for such personal proposal. In my opinion, the creation of SENT is a good strategy for Session users to adopt the messenger and to have private value transactions, as it also move them away from the mostly unaware Oxen. Oxen (or SENT) should be back to the old POW mining type of Blockchain, with a finite coin/token emission. (People are only really trusting POW) The idea is to keep the SN as network validators (as they are now, but without issuing SENT), and an algorithm (solely CPU - RandomX or a new created - the Loki team did it before 🙂) should be chosen to mine the blocks and issuance of the tokens (a % on rewards should be allocated to SNs) However, the Service Nodes will have a new key player process, for the current web3 DeFi DEX wallets and swap capability.
Regarding Lokinet, don't change nothing (just the token for the Exit nodes) and keep it solely on the L1 (private) That's it. TrampledF |
There's a practical issue that I haven't seen discussed anywhere. If the plan is to phase out the Oxen chain entirely, how will we deal with those Oxen holders who may not be closely following the project, have not voiced their opinions, and might miss the migration window? According to Theoretical Analysis of Oxen Wallet Counts vs. Top Ethereum ERC20 Token Wallet Counts and an Alternative Approach to Increasing Oxen Holders, currently only 41% of Oxen is staked, with a large amount of Oxen owned by thousands of holders not participating in any service nodes. How can we ensure that every holder is notified before the Oxen chain is shut down to prevent anyone from losing their funds on the obsolete chain? |
I am concerned that there might be miscommunication and misinterpretation between the team and the community, as my observations suggest otherwise. The primary issue is that ORC-8 encompasses several aspects, making it challenging to provide binary feedback (positive/negative) as a whole. This is because one might agree with one sub-topic but disagree with another. Regardless, I have decided to volunteer myself to count the valid comments in this thread and manually classify them as Positive, Neutral, or Negative—either as a whole or specifically concerning the replacement of Oxen with a transparent EVM token. My classification is based on my subjective interpretation of community feedback. If anyone disagrees with any specific classification, please quote the specific row in the following table and make a suggestion. My statistics do not support the conclusion that "most community feedback has been positive." The team might have different criteria for rating a comment or a different perception of feedback; however, feelings can sometimes mislead us. If you believe my statistics significantly differ from your perception, I recommend engaging in the same practice and reviewing your conclusion again. I have identified 32 valid comments in the thread:
If you have a better methodology for aggregating community feedback, I would be happy to volunteer for the work.
|
Another potential benefit of keeping the Oxen chain alive is that, if a bidirectional communication between Oxen and EVM is successfully established, we might use the same technology to convert stablecoins like USDT, USDC, or DAI from the EVM chain back to the Oxen chain. These would then become privacy-centric stablecoins, which could potentially become a killer feature of the project. |
|
Kee wrote in his last comment that there is not enough money to develop privacy coins. And that it is a very time-consuming and complicated process. I think that is the main reason. He never once asked the community to help with money for development! You can only kill this project when you are sure that no one is interested in it. After no one supports it financially. Privacy is being pushed to the periphery because it is a threat to the globalists and must exist on people's donations. Otherwise it won't work. It looks like they have already made their decision. (However, nothing prevents them from postponing it for a few months and trying to collect donations from people. Why not? Why don't we ask the team to do it?! The fact that privacy coins are delisted from exchanges is not a bad thing, on the contrary - a good thing! It shows that we need to evolve and not give up! |
Philosophically, another approach could be to donate the entire Session/Oxen/Lokinet code base and branding resources to Monero Research Lab, allowing them to handle the Oxen privacy chain development and anti-censorship battles. |
I support and fully agree! |
|
@venezuela01 I would like both of sentiments changed to positive. |
@Lucifer1903 Thanks for the feedback. I have revised the sentiment of your last comment as you requested and updated the charts accordingly, without altering the sentiments of your previous comments. To clarify, I've recognized a flaw in my methodology: Some members' opinions might change over time, some members might supply additional arguments to emphasize their previous positions, as a result we need a more advanced way of accounting for or disregarding historical opinions. If the community is serious about these statistics, please feel free to initiate a separate discussion, and we can contribute further to the new thread. Rather than proposing a perfect solution for aggregating community feedback, my attempt has revealed the difficulty of measuring community feedback. I'd like to invite the team to share their methodology on how they conclude that the majority of community feedback is positive. If they are confident in this conclusion, there is likely some clearly defined methodology which would be widely accepted. If such a methodology is hard to establish, as my previous attempt shows, then we should reevaluate whether the conclusion itself is reliable. |
Right on! I think that's a great idea. Let Monero folks do it, as it seems only they can and want to pursue the privacy path. If Oxen can't or too much trouble for them, let Monero do it. |
|
Hey folks. With the pending "migration" to EVM or conversion to Session token, why is nobody talking about WOXEN? This is something we already have - ethereum.oxen.io/#/about |
We are still working through the details of the migration process internally, when the migration occurs we will be using every communications channel we have available to communicate the migration process, this includes non traditional channels like using banners in the wallet and on the websites, as well as traditional channels, like Telegram/Session updates channels and Twitter
This was based on a broad analysis of not just public comments on this ORC, but comments in Telegram, Session and other social channels, including personal communications which we have had with investors, and Oxen holders.
wOxen is cool but its centralized in its issuance and fragments liquidity across both the Oxen and Ethereum chains, its also unrepresentative of future Oxen tokenomics and uses an older token standard. We want to move towards a unified vision around a new token which ties back into the Service Node network |
What criteria will determine the closing of the migration window, in terms of the percentage of the Oxen market cap being migrated? Currently, with around 64.9M Oxen in circulation, after what proportion of Oxen has been converted to the new token will we opt to phase out the old chain? If the goal is achieving a 100% migration, this seems unfeasible given the difficulty in reaching every stakeholder. We might overestimate the efficacy of our marketing channels, if they were truly so efficient, Oxen would be more widely recognized by now. This situation brings to mind the historical Bitcoin investors who only recovered their lost private keys many years following Bitcoin's significant rise. Should we establish a threshold, perhaps at 99%? Has there been any forecast regarding the time and effort required to reach almost every holders, aiming to convert more than 99% of the market cap? Furthermore, by doing so, we'd inadvertently be excluding certain stakeholders, much like leaving someone out of a lifeboat. How can we ethically reconcile with such a decision? And how do we intend to assist an Oxen holder who comes back after the migration window, alleging their assets are now inaccessible on the obsolete chain? If we don't uphold our commitment to previous investors, how can we inspire trust in future investors? When criticized for leaving someone out — and possibly being labeled a scam project that reneges on promises and mismanages individuals' funds — how will we respond?
If you are genuinely considering the feedback from Telegram, Session, and other social channels, could you share the methodology and findings of your broad analysis? Otherwise, I'd be willing to volunteer and publish my own broad analysis report using public data. It may or may not align with your conclusions. |
|
The first thing you should consider is what each move does for the community. Right now you kind of see there is a rift happening from the vocal minority. This is why being an ethereum project is paramount. You'll easily triple the session community size the moment you launch on ethereum when the various eth communities see a new and interesting project is launching on their favorite chain. Ethereum will also bring on board a diverse pool of new node providers. I just dont see that happening with any other chain during this bear market. Next is networking. Vitalik is a huge proponent of privacy. He was even one of the first supporters of tornado cash. see https://decrypt.co/155278/vitalik-buterin-pushes-for-privacy-pools-to-balance-anonymity-with-regulatory-compliance to read about his current stance. Being labeled ethereums new privacy messenger will be huge for marketing and networking. Each update will be watched/read by thousands as they curiously keep up to date on their new privacy app. Finding and aligning yourselves with privacy minded people and communities is crucial for the success of session. Finally speculation/trading will greatly benefit session on ethereum than on any other chain. right now theres over 100B of potential capital floating around on ethereum while between opt/arb/polygon theres at most 5B. The importance to market cap of being an ethereum project alone should be enough reason to have the main contract on ethereum. On day one I see millions flowing into SENT on ethereum. Polygon? Opt? not so much. Polygon is probably your main choice right now when you look at the gas fees. Theres nothing wrong with polygon but its important to note its not a true L2 and is already kind of bloated with an archival node size larger than Ethereums. I see polygon as a cheap but temporary solution on a long enough timeline but should suffice in the short term as session is able to establish itself. Golems payments are currently being processed on polygon (main contract on Ethereum) and Ive seen no problems with it. Even though Golems protocol txs are on polygon it is still seen as an Ethereum project to the community which is why the market cap is still relatively high. I view opt/arb as a better tech solution but their higher gas fees obviously factor in right now. If session had deeper pockets I'd recommend them or even building your own EVM sidechain but you'll get the same performance on polygon. But if opt/arb offer some sort of partnership involving funding or grants that obviously changes things. This bring up the point that issuing on Ethereum first will allow you the flexibility of easily switching L2s in the future without compromising the stored value of the project. I see at least 66% of SENT tokens being stored on ethereum between locked team/reward tokens, speculators, exchanges and LPs. If you first deploy on polygon then a year later you decide to move to a better/cheaper L2 that comes out it could seriously harm the future of session shifting the entire $ of the project to another chain yet again. People may decide to drop out or view it as poor decision making. Whereas migrating to a new L2 while already established on Ethereum to save on gas fees seems like a big brain move. The OXEN migration to the new chain is another factor I can see why you would want to issue straight on a L2. Doing a "free" swap will be viewed more favorably than charging everyone gas fees. I would issue all migration tokens on the L2 and just give people the option to bridge to the L1 or send to an exchange if they want. If you launch only on a L2 there will be serious questions if others will dump when game theory kicks in. But if people see the main value is stored and secured on ethereum its more likely there wont be a panic to dump tokens. Being anchored on Ethereum eases all qualms of SENT failing on a L2 or being immediately dumped after the migration. Managing a bridge to the L2 may be seen as a pain but will be worth it in the long haul. hopefully this helps you in your decision making TLDR; |
|
@Lucifer1903, Many projects have their token contracts on both Ethereum main net and one or more L2s. For example, Synthetix was one of the early projects to migrate complex business logic to Optimism for gas savings. Things such as staking, minting/burning sUSD, claiming weekly staking rewards, and governance votes for the different councils. That said, since they are an older project, all those same functions exist in smart contracts on main net too, it just costs a small fraction to do the same functions on Optimism, so a lot of smaller holders migrated their SNX to Optimism to handle all the weekly staking related transactions. So, with that being said, the SENT token contract could be deployed to main net so that some people can keep their tokens on main net for holding or providing liquidity to pools such as on Uniswap. The team could then deploy the necessary business logic related contracts to an L2 so that users could migrate SENT tokens to the L2 for holding, trading, LPing, staking for a snode, claiming snode rewards, unstaking, etc etc. I think if they did it like that then they could possibly offer a choice when a user migrates from OXEN to SENT. They could choose to get their SENT on the L2 or main net. Though, that may involve additional complexity so it may only make sense to allow migrating the main net then the user would need to use an L2 bridge to migrate to the L2 to then stake their SENT tokens. |
|
I have read explanation and a lot of reasoning in this thread + Q/A videos... Full support
GRAVE strategic mistake:
I can elaborate extensively on why, if team is interested (which is not likely, coz decision is clearly already made), but anyone who operates in first principle thinking surely figured it all out by now. There were many people in this thread who has already outlined some glimpses of mistakes while making such moves. |
|
There's a man on the team who has influence. And a fan of anonymity and privacy. We have to "keep knocking on the door". |
|
I'd like to quote a message from the Oxen telegram group:
I replied with:
I have tagged this message @KeeJef and @Crypto_mc in the Telegram channel. Surprisingly, shortly after I sent my message, my post was deleted by a moderator in the group and my account was restricted from posting. This is not the first time I've been restricted from posting, despite not using any offensive language, straying off-topic, or making statements that distort the truth. @KeeJef, could you clarify if this kind of banning of candid community members reflects your perception that most community feedback is positive? Is this positive feedback a result of suppressing dissenting opinions, or is the recent banning an isolated incident of individual moderator misconduct that should be reassessed for its legitimacy? Shooting the messenger will not lead to the success of the project. |
|
@venezuela01 I'm not aware of your banning in the channel, wasn't something i did, and i don't understand why that post would result in a ban, might have been accidental, please contact https://t.me/tophut to clarify |
Thanks for clarify. This is what I get from @msgmaxim
I trust that this was not intentional, but unfortunately, it has been a really poor experience for me since I've been banned multiple times in the past few months and I gave up posting many of my opinions because of that. I'm still unable to post anything, I'll wait a few more hours. Edit: still unable to send any messages after 24 hours. admin has no idea what's wrong. 
|
|
In ORC-8 The Session Network Token, @KeeJef acknowledged, "This is not to say that Session monetization wouldn't be successful on Oxen; however, I think it would be to a lesser degree." I'm glad that the CTO of the project agrees that Oxen with Session monetization is feasible and potentially could be successful. However, it appears there is a trade-off between being so called "more successful," with quotes, and having more privacy. Have you consulted the community about whether they prefer a "less successful" Oxen project with more privacy, or a "more successful" Session token with less privacy? In the previous comment, I presented my statistics showing that the majority of comments are against a transparent token. You argued that comments from Telegram, Session, and other social channels are positive. Then, I asked you to show your methodology and data for the feedback you collected, but you didn't respond. Do you still insist that the majority of community members support a transparent token, even if you clearly inform them that Session monetization with Oxen could be moderately successful but not "more successful"? Could you share your data on feedback collection to substantiate this claim? Note that Telegram supports exporting chat history; I can provide you with a copy if you like. Have you consider a vote, given that Token Migration Case Studies shows that voting is a feasible practice to some projects, especially when the migration is not trivial? If you haven't consider a vote, it's good to discuss about it, even thought experiement is good, because we might have other big changes in the future. If you believe voting isn't a good solution, please explain why we are different than other projects who conducted a voting like Helium, Unibot and Threshold Network. |
|
Good points!!!
…On Tue, Dec 5, 2023, 4:55 AM venezuela01 ***@***.***> wrote:
In ORC-8 The Session Network Token
<#36 (comment)>,
@KeeJef <https://github.com/KeeJef> acknowledged, *"This is not to say
that Session monetization wouldn't be successful on Oxen; however, I think
it would be to a lesser degree."*
I'm glad that the CTO of the project agrees that Oxen with Session
monetization is feasible and potentially could be successful. However, it
appears there is a trade-off between being so called "more successful,"
with quotes, and having more privacy. Have you consulted the community
about whether they prefer a "less successful" Oxen project with more
privacy, or a "more successful" Session token with less privacy?
In the previous comment
<#36 (comment)>,
I presented my statistics showing that the majority of comments are against
a transparent token. You argued that comments from Telegram, Session, and
other social channels are positive. Then, I asked you to show your
methodology and data for the feedback you collected, but you didn't
respond. Do you still insist that the majority of community members support
a transparent token, even if they are clearly informed that Session
monetization with Oxen could be moderately successful but not "more
successful"? Could you share your data on feedback collection to
substantiate this claim? Note that Telegram supports exporting chat
history; I can provide you with a copy if you like.
Have you consider a vote, given that Token Migration Case Studies
<#62> shows
that voting is a feasible practice to some projects, especially when the
migration is not trivial? If you haven't consider a vote, it's good to
discuss about it, even thought experiement. If you believe voting isn't a
good solution, please explain why we are different than other projects who
conducted a voting like Helium, Unibot and Threshold Network.
—
Reply to this email directly, view it on GitHub
<#36 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BBND5JMCWBY5XBZFNIRE4P3YH3VSRAVCNFSM6AAAAAA2WXBU4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBQGQYTGMZRGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I think the premise of that statement is false dichotomy. Only thing that determine any crypto project long-term - is it's real world usefulness and how it will stand against attacks on freedom (having independent infrastructure), great examples:
How i personally see successful token should be:
I'm sure that actual real choice presented here is between:
Those 2 things clearly can not co-exist - because it's quite literally a frontline. Right thing to do - is being as hardcore as possible, perhaps even more hardcore (becoming absolutely anonymous on devs end, like ThinkPad + Whonix type of OpSec for publishing code 😃). Because it will make world a better place, we've seen enough looses for freedom lately... My hope is Oxen / Session / Lokinet devs understand exactly why it's on the frontline of war and won't compromise or back down in any way, coz otherwise...well it won't end well for anybody. And i really wish you well! |
|
Implementing ERC20 token into a privacy-centric ecosystem will 1) not attract any real interest, because people in transparent crypto aren't interested in whatever you're bringing, since they already live in KYC world and avoid privacy projects like plague and 2) will cause the real interest to abandon the project, since it's no longer a privacy-centric project. This is just my opinion. |
and others
ORC-8 The Session Network Token
Introduction
It currently appears that KuCoin is moving to remove OXEN from their exchange. While this is an adverse development, it (in part) confirms concerns we have with the coin. OXEN isn’t working. While the network is stable, Session is reaching new all-time highs, and Lokinet is blazing a path, OXEN is struggling to keep up with the pace. We don’t want OXEN to get left behind — and we have spent a lot of time thinking and talking about how to get it back on its feet.
Earlier this year we knew that we needed to give OXEN some love. We planned a brand refresh that would clarify OXEN’s position in the space, create new, more reliable customer funnels, and freshen up our visuals. As the project progressed, we uncovered more and more problems — with our brand structure, our coin, and ever-increasing regulatory pressure. We needed to make moves to reunify the brands of our project, rework our tokenomics, and connect with the rest of web3.
However we kept straying further from our original goal, we realised we needed to talk to you. We are not done yet, but it’s time to start sharing our ideas with you.
Motivation
Branding
Session is on the rise. People know what Session is, they trust Session, and they understand why it is valuable. In the crypto world, a lot of people are already using Session as their daily messaging app. And yet, a lot of these people have never even heard of OXEN. Some of them don’t even realise there is a coin behind the app. Despite some efforts — like cross-channel promotion, Powered by OXEN, and official communities in-app, the cut-through just hasn’t been what we need.
We need a brand that is strongly connected to Session: in name, appearance, and theme.
Connection
OXEN is an island. While being a standalone chain comes with its perks, it also comes with devastating drawbacks. We are small, we are isolated, and nobody wants to work with a privacy coin. As exchanges turn their backs on coins like OXEN, we are left with limited fiat onramps, low liquidity, and dwindling opportunities with centralised exchanges.
Web3 anticipated this problem, and set out to solve it: but OXEN lacks interoperability and connectivity with the rest of web3. This leaves us managing specialised and unfamiliar wallets and lacking native support on dexes. These days people expect to swap for a token on Uniswap, hold it in MetaMask, and stake them straight from a website.
We need a token which can connect with web3 and its community.
Tokenomics
Our tokenomics made a lot of sense back when they were first conceived. We were following the Monero-model, whose economic structure was borne out of opposition to the Bitcoin fee-model. Back then, there were no considerations to be made about governance tokens, rebase tokens, or any of the other constructs which web3 would later concoct.
Currently, we are running with an inflationary model where coins are minted to reward nodes. As nodes receive rewards, they are also being slowly (but infinitely) diluted and creating sell pressure.
To offset this, we have monetisation — but with our standalone blockchain, most scalable monetisation models require a manual buy-and-burn setup. This is centralised, requires trust, and encourages unhealthy market dynamics.
We need a modernised tokenomic model which better suits the project and its goals.
Proposal — Session Network Token
Session Network Token is a reimagination of the original Loki from 2018. We’re not just changing the name — we are changing what we are, what the token is, how the system works, and how we talk about ourselves.
SENT will be the token behind Session, other Session-branded apps, and the network of nodes which supports them.
New token
Session Network Token (SENT) is a new token on a yet-to-be-determined alternate EVM compatible Layer-2.
This immediately opens doors to new liquidity, collaborations, and interoperability that has not been possible in the past. Session Network Token will be able to integrate with popular wallets like MetaMask, fully support hardware wallets like Ledger and Trezor, and make staking simpler and easier.
Importantly, this new token also allows us to transition to a static, capped supply, make on-chain value capture easier and more transparent, as well as opening the door to new tokenomic mechanisms, such as token pools.
The reward pool
All of the network’s value is captured and redistributed through the reward pool. The pool is filled with tokens from monetisation mechanisms such as Session Pro, Network Enterprise, and Session Enterprise. As these value capture mechanisms scale, the reward pool grows and incentivises new operators to join the network.
Our current working model for the reward pool is based on industry leaders — although its designs are still in flux. Importantly, the reward pool allows us to have a fixed supply for the network, preventing long term effects of inflation from impacting holders and node operators.
Lokinet
This transition also includes hugely increased focus and attention on Lokinet and the technology behind it. Lokinet will also be folded into the Session family — gaining stronger connection to the Session Network Token, Session, and being able to more easily leverage the value of those brands and userbases.
In the past, our token has been divorced from the things that make it powerful, instead needing to reference Session and Lokinet for proof of value. Now, Lokinet’s unique value can be re-communicated through the Session Network Token.
In the future, it will be possible for others to leverage the network just like Session and Lokinet. We have already had meetings with potential business partners, and people are already expressing interest in utilising the network for their own products, and this will likely be a key part of Lokinet’s success in the future.
Answers to Initial Questions
How is all of this going to work?
Right now we need to finish conceptualising and executing on our new branding and direction. We're bringing you guys in on the ground floor to help us work on some of the details so we can work together in the same direction.
Next, it will be a matter of bringing OXEN across to the new network. We have already started creating technical documentation for how the transition will work, and at the moment we are looking into leveraging wOXEN to bridge people across to SENT.
Where do I trade my OXEN now?
Right now we are planning to increase the wOXEN liquidity on Uniswap. Because Uniswap is a decentralised exchange, we will not be exposed to the same risks of regulation-related delistings while we transition towards a Layer2.
When will we find out more?
We know you want to hear from us — and we want to hear from you, too. We will be doing AMAs to answer your important questions and get discussion rolling about decisions which are yet to be made. You can also comment on this ORC to add your perspective.
Keep an eye out for announcements about them on our socials.
What will happen to my OXEN?
You don’t need to do anything right now. We are still working out the details about how exactly we are planning to bridge OXEN to SENT. Once the transition is complete, all OXEN should be swapped for SENT, but right now, it is fine to continue holding OXEN as per usual.
Good news for those of you running a service node, we’re planning to have large incentives for staked OXEN during the swapping process.
Consultation
This is a proposal about what purpose OXEN serves and how it operates as a part of the wider network and project. We know many of you will have your own questions and contributions — we are opening this request for comment to invite all community members to participate in the process.
We know that there are still details we are finalising, but I hope this document will provide some clarity and insight into what we believe is the best way forward for the project.
The text was updated successfully, but these errors were encountered: