Revised Proposal: Enhancing $SYN Utility through Network Security and Staking

fool · 2023-09-29T00:52:01+02:00

Objective: Enhance the utility of $SYN by emphasizing its role in network security and staking, rather than merely as a gas token. Update official documenta...

yncsankyo92

$SYN as security bond with burning buyback lets go

Walther

Hope this is achievable 🙏

skya

Very bullish If this is doable

suksescoindo

I represent a crypto community that believes in a bright future with $SYN, support this proposal as it will give a lot of utility to $SYN. both option #1 or #2 are good.

0xbottomseller

Some rather disorganized thoughts rather than strongly held opinions:

"Retain Ethereum as the primary gas token for both L1 and L2 in SIN and Synchain" - From my understanding SIN doesn't require gas to operate. SIN is a network of offchain actors?
SYN's price fluctuates too much in value, it could go down to a point where it would be cheaper for guards and notaries to be dishonest and lose their stake over being honest and worry about their staked SYN. Something like ETH or stakedETH makes sense, SYN is too risky to use IMO. However, am curious to know if something like SYN-ETH LP could be used for that, if that is a technical feasibility?
Tips: I think protocol will make ETH. ETH can be converted into SYN and be used to 1) pay offchain actors in syn AND 2) buy back and burn or send to treasury for future expenses like marketing or developer onboarding or even creating more community managed multisig notaries and guards (am not clear if the latter is technically feasible /if notaries and guards can be multisigs)

fool

0xbottomseller

Thank you for sharing your insights. They are indeed valuable points of discussion and moves us further along.

You're right regarding SIN. It operates off-chain and doesn't necessitate gas fees. The primary reference should indeed be to Synchain. As we progress toward a conclusive proposal, we'll ensure the appropriate corrections are made to reflect this understanding.
The concerns you raised about the fluctuating value of $SYN are noteworthy. It'd be insightful to have @aurelius and @Chi_Squared share their perspectives on this, especially considering the optimistic security principle of our network where one fraud report is enough to invalidate transaction; the design is fundamentally different from other chains that suffer issues with byzantine-fault tolerance. If there's potential risk, perhaps an SYN-ETH combination could be an answer. However, I believe that relying entirely on ETH for both staking and fees could inadvertently diminish $SYN's utility beyond governance.
Your suggestion about ETH serving as the protocol's gas and subsequently being converted to $SYN for each transaction is intriguing. But there's a potential caveat: if all converted ETH becomes $SYN, we might encounter a similar issue we've seen with SYN-ETH LP providers in Sushi pools. They typically liquidate their $SYN rewards, which doesn't necessarily benefit the overall $SYN value. If agents convert their $SYN yields back to $ETH, we're essentially in the same spot as the previous proposal ($SYN as gas fees) where there is no net-value added to $SYN. While the DAO treasury might benefit from such conversions, $SYN holders might not see direct advantages, which is reminiscent of our current state with bridge fees.

Tagging a few others to see if we can get more input @Googly @socrates @Moses

socrates

Thanks for the proposal @fool. I like a lot of the ideas brought up here. My personal opinion from a security perspective is to wait until Synapse Chain and SIN are in mainnet before making decisions like this.

Some data I'd like to see first:

Relative size of bonds between Notaries and Guards. Bond sizes should improve economic security and prevent griefing.
Tip size and allocation between Notaries, Executors, and Guards. What are apps willing to pay for different use cases?

Think it'll be hard to implement these changes technically without having a clearer idea of the data.

fool

socrates Thanks so much for your input. I think that's valid that it's hard to get a sense of realities until mainnet launches. Had some follow up questions to the data and your suggestions:

Is it possible we can collect this data during a devnet launch? I presume we'd need to have the off-chain agents tested and running properly in devnet before the mainnet launch which creates opportunity to answer your questions.
Can we revisit some of the concepts in this proposal by @aurelius https://forum.synapseprotocol.com/d/7-implement-syn-staking-in-preparation-of-pos-synapse-chain-launch? It seemed at some point here he suggested launching a single-sided staking program before a mainnet launch which I presume should be possible in this new SIN/Synchain architecture. Do you think there are parallels to this proposal two years ago and some of the things we are trying to bring forward in this proposal?

Synapsefox

How are other protocols addressing this issue? Is there any model that creates some sort of value to the native token while keeping Eth as main gas fee token and being compliant with any legal regulations not classifying SYN as a security? IMO many protocols are facing same issue. As time goes on we will all understand that tokens with no utility were simply deployed to finance the vision of revenue generated protocol where fees will go founders and investors. Example Uniswap. And the other protocols where fees are in native token and not Eth will most likely have no users with the exception of any outliers. There are some new novel ideas that have been implemented this past year where value is shared among community and the team/investors. That said thanks to @fool for taking on this, the price of SYN has been painful to endure. Communities can make investors money and they can be the exit liquidity too but time has shown no protocol without a strong community and positive social sentiment has succeeded. Hopefully @aurelius and the team make this right and bring back the SYN image as it once was. Having the team
In constant communication via twitter i think now is crucial as many believe the project is slowly dying when in contrary the team has shipped more then in the past. In the end the protocol will need users and crypto users follow the narrative. Let’s try our best to keep the SYN narrative positive going forward and keep the community excited on what is about to come.

suksescoindo

protocol makes ETH, then converts to SYN to buyback and burn also some to treasury. i love any use case that makes SYN deflate

feyo

Thanks for the write-up @fool and for kickstarting the debate around SYN utility. TLDR this discussion will remain very hypothetical in nature until the team provide some feedback on the various trade-offs of certain proposals. My quick & dirty thoughts below.

ETH vs SYN for gas: I'd recommend using ETH as the primary gas token. Using SYN for gas would impact the relative attractiveness of the protocol and slow down adoption as there is currently no spot demand for SYN (other than for speculative purposes). You could introduce an auto-conversion feature like the one Chainlink is implementing, allowing users to pay in ETH/stables which then auto-convert to SYN. That could however lead to a reflexive farm & dump dynamic so IMO the value accrual derived from certainty on tx costs through the use of a high liquidity/low volatility gas token likely far outweighs the potential net demand for SYN from using it as the primary gas token.
SYN as a security bond: similar to the previous point, I think preference should ideally be given to a prime collateral asset which has high liquidity, low volatility and some form of monetary premium/spot demand. That being said, the design of SIN's security model in which a single honest actor is enough to safeguard the system may somewhat reduce the reliance on economic security and could therefore provide some flexibility on this point. Perhaps a dual-track approach could make sense here: allow Agents/Notaries/Guards to post a bond in ETH, SYN or a combination thereof (the SYN portion being overcollateralized and ETH-denominated). This would mitigate any concerns on the part of node operators that don't want exposure to SYN liquidity/volatility.
DAO revenue share: redirecting a portion of fees to the DAO treasury, effectively mirroring the current "admin fee", probably makes the most sense to me from a value accrual/utility standpoint as it achieves a number of goals: i) it creates a sustainable source of funding for all aspects of the protocol's development, ii) it diversifies the treasury into a quality exogenous asset (ETH), iii) it anchors the value of SYN to Synchain's growth and iv) strengthens the notion of SYN’s intrinsic value with a right to ETH denominated cash flows. As the protocol matures and builds up a strong treasury over time, it can start to return excess funds to token holders. This value can flow back to token holders in variety of ways optimizing for capital efficiency, tax and regulatory matters (buyback & burn, buyback & make to improve on-chain liquidity, stake to underwrite additional protocol risk (e.g. insurance fund) & earn yield). There are a variety of trade-offs that will need to be discussed at length here but that discussion feels pre-mature right now given the nascency of SIN/Synchain.

Another aspect the community needs to consider in relation to point 2 is what is the minimum APR required to attract A/N/G into the network? Fee generation at launch will presumably not suffice to allow node operators to clear the minimum return and the delta might have to be plugged with SYN emissions until node operators can live off organic revenue alone. This could have major implications on SYN supply and tokenomics but without the team’s input/guidance on the minimum/optimal number of A/N/G required to run the network it will be very difficult to have any kind of informed debate on this topic. I would argue this last point applies to the whole discussion around SYN utility where I’m sure a number of technical/design choices by the team will drive a preference for one or the other solution.