yearn-protocol
turbo-geth
Our great sponsors
yearn-protocol | turbo-geth | |
---|---|---|
36 | 58 | |
395 | 2,938 | |
- | 7.3% | |
4.1 | 9.9 | |
over 2 years ago | 5 days ago | |
Solidity | Go | |
GNU Affero General Public License v3.0 | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
yearn-protocol
-
What's your favourite ecosystem outside of Terra?
Well, I would be way off my knowledge comfort zone since I personally cannot absorb ETH gas fees in DeFi. So I cannot help you more than that. I believe YearnFinance is one of the well respected DeFi solution on Ethereum, and probably the place I would start with.
-
How would YOU put $970K worth of ETH to work for you while you HODL it?
Also interested in any kind of robot auto-investment of ETH, some system where you deposit funds and they are managed on your behalf following the market and trends. I *think* this is what https://yearn.finance is trying to do, but they are in beta. Has anyone built a fully operational and proven auto ETH investment platform?
-
If you had invested $1000 in USDT a year ago , your current value would be $1050 by staking it. The "neutral" side of investing into Crypto which no one talks about.
The latter is how you see big yields that wouldn't make much sense otherwise. The thing is that the value of those governance tokens can fluctuate a LOT more than your base assets, so unless you sell them immediately, your rewards could lose value. That's where yield aggregators (also known as auto-compounders) like yearn.finance come in. They automatically convert the rewards back into the base assets so that you don't have to hold those governance tokens.
-
How to know a use case is a good use case?
Curve DAO, dYdX, yearn.finance and any of its ilk - wealth management tools
-
I'm now the proud owner of a Solana-based dogcoin. :)
Seriously. If we've learnt anything from other hypes like yearn.finance last year it's this:
-
Coinbase offering 1% APR staking rewards on USDC
check this link for some of the yields, u can get on yearn.finance. theirs other ones but this ones pretty straight forward to use
-
can't locate $yvWFTM
I recently put some $WFTM in beta.yearn.finance, to then take the $yvWFTM to abracadabra. All went well. Today I wanted to put in more wFTM into that same yearn vault. After doing so, I can't seem to locate the receipt token. Anyone have any idea where to find it? It's not in my Metamask and I can't find it on yearn.finance either...
-
ELI5- Yearn.finance value
yearn.finance is a DeFi yield-farming aggregator service. This means that the protocol finds the best yields across platforms like Aave, Compound, and dYdX, mostly across Ethereum, to earn in-kind yields based on the aforementioned protocols.
-
Why are yield rates on CeFi so much higher than DeFi and how sustainable is this?
During one of their AMA's a while back Alex mentioned that the reason Celsius' rates are so high is because they use all the defi apps like AAVE, Compound, etc and switch amongst them to get the best rates. Never really questioned that answer too much, but today I was looking at yearn.finance and that is what they claim to do (aggregate other defi rates and switch to the best one), but yearn is offering between 2% and 4%. Most defi apps like curve also offer around 2.5% or so on stablecoins. Just wondering how Celsius is able to offer 8.88% yield (and BlockFi is able to offer 8.25%), which is more than twice any rates I was able to find on defi? Still learning here so forgive me if I am missing something.
- آندره کرونژ کیست و چه اقداماتی در حوزه ارزهای دیجیتال انجام داده است؟
turbo-geth
-
AMD EPYC 7C13 Is a Surprisingly Cheap and Good CPU
To be clear, it was a CPU fault that doesn't occur at all when running e.g. stress-ng, but only (as far as I know) when running our particular production workload.
And only after several hours of running our production workload.
But then, once it's known to be provokeable for a given machine, it's extremely reliable to trigger it again — in that it seems to take the same number of executed instructions that utilize the faulty part of the die, since power on. (I.e. if I run a workload that's 50% AES-NI and 50% something else, then it takes exactly twice as long to fault as if the workload was 100% AES-NI.)
And it isn't provoked any more quickly, by having just provoked it with the last hard-fault — i.e. there's no temporal locality to it. Which would make both "environmental conditions" and "CPU is overheating / overvolting" much less likely as contributing factors.
> There have been enough of them in private hands for long enough that if there were widespread issues they would be well-known.
Our setup is likely a bit unusual. These machines that experienced the faults, have every available PCIe lane (other than the few given to the NIC) dedicated to NVMe; where we've got the NVMe sticks stuck together in software RAIDO (meaning that every disk read fans in as many almost-precisely-parallel PCIe packets contending for bus time to DMA their way back into the kernel BIO buffers.) On top of this, we then have every core saturated with parallel CPU-bottlenecked activity, with a heavy focus on these AES-NI instructions; and a high level of rapid allocation/dellocation of multi-GB per-client working arenas, contending against a very large and very hot disk page cache.
I'll put it like this: some of these machines are "real-time OLAP" DB (Postgres) servers. And under load, our PG transactions sit in WAIT_LWLOCK waiting to start up, because they're actually contending over acquiring reader access to the global in-memory pg_locks table in order to write their per-table READ_SHARED locks there (in turn because they're dealing with wide joins across N tables in M schemas where each table has hundreds of partitions and the query is an aggregate so no constraint-exclusion can be used.) Imagine the TLB havoc going on, as those forked-off query workers fight for time.
It's to the point that if we don't either terminate our long-lived client connections (even when not idle), or restart our PG servers at least once a month, we actually see per-backend resource leaks that eventually cause PG to get OOMed!
The machines that aren't DB servers, meanwhile — but are still set up the same on an OS level — are blockchain nodes, running https://github.com/ledgerwatch/erigon, which likes to do its syncing work in big batches: download N blocks, then execute N blocks, then index N blocks. The part that reliably causes the faults is "hashing N blocks", for sufficiently large values of N that you only ever really hit during a backfill sync, not live sync.
In neither case would I expect many others to have hit on just the right combination of load to end up with the same problems.
(Which is why I don't really believe that whatever problem AMD might have seen, is related to this one. This seems more like a single-batch production error than anything, where OVH happened to acquire multiple CPUs from that single batch.)
> It's possible that AMD didn't order enough capacity from TSMC to meet demand, and couldn't get more during the COVID supply chain issues.
Yes, but that doesn't explain why they weren't able to ramp up production at any point in the last four years. Even now, there are still likely some smaller hosts that would like to buy EPYC 7xxxs at more-affordable prices, if AMD would make them.
You need an additional factor to explain this lack of ramp-up post-COVID; and to explain why the cloud providers aren't still buying any 7xxxs (which they would normally do, to satisfy legacy clients who want to replicate their exact setup across more AZs/regions.) Server CPUs don't normally have 2-year purchase commitments. It's normally more like 6.
Sure, maybe Zen4c was super-marketable to the clouds' customers, so they negotiated with AMD to drop all their existing spend commitments on 7xxx parts purchases in favor of committing to 9xxx parts purchases. (But why would AMD agree to that, without anything the clouds could hold over their head? It would mean shutting down many of the 7xxx production lines early, translating to the CapEx for those production lines not getting paid off!)
-
erigon sync log correct?
consensus client/execution client -> ERIGON v2.45.2 and NIMBUS v23.5.1
-
Can anyone share updated Erigon Grafana dashboard json file?
This file (https://github.com/ledgerwatch/erigon/blob/devel/cmd/prometheus/dashboards/erigon.json) is outdated. Many panels are not working. Would appreciate if someone can share the json with all the useful panels.
-
Syncing an erigon node
48 hours - currently on stage 7 - https://github.com/ledgerwatch/erigon/blob/devel/eth/stagedsync/README.md
-
Ethereum's pending withdrawals total $1.34 billion after Shapella
https://github.com/ledgerwatch/erigon 696 contributors
-
Daily General Discussion - April 12, 2023
Erigon 2.41.0 does come with Shanghai for mainnet though so as long as people are running 2.41.0 or 2.42.0 they will be all set.
-
How Client Architecture applies to decentralization & security in Crypto
— Erigon ***(~10.8% of all clients)***A fork of Geth client (also in the GO programming language) that is focused on maximizing the efficiency of storage for archive nodes.
-
Current known issues with Shapella clients
Github issue tracking it, likely to be fixed on Erigon side
- Erigon v2.41.0 is out. Ready to Shanghai upgrade for Ethereum mainnet
- Erigon v2.40.1 released
What are some alternatives?
harvest-strategy - The Hardhat environment for strategy development
besu - An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu
GLM-stake-pool - Yield farming opportunity for Golem's GLM token holders. (By staking uniswap-LP tokens that is a pair between GLM and ETH into the stake pool)
protocols - A zkRollup DEX & Payment Protocol
awesome-solidity - ⟠ A curated list of awesome Solidity resources, libraries, tools and more
vyper - Pythonic Smart Contract Language for the EVM
ethereum2-docker-compose - Run different kind of Ethereum 2 staking nodes with monitoring tools and own Ethereum 1 node out of the box!
curve-contract - Vyper contracts used in Curve.fi exchange pools.
go-ethereum - Go implementation of the Ethereum protocol
contracts-v2 - V2 Contracts for the Dracula Protocol
awesome-ethereum - :zap: Awesome Ethereum Resources