0xngmi

The request for the Realms Of Ether really comes from me, the creator of the wrapper contract

The repository used to create the wrapper can be found in https://github.com/0xngmi/fortresses

0xngmi

• arbitrum nova 0x1c5771e96C9d5524fb6e606f5B356d08C40Eb194
• arbitrum 0xA7caC4207579A179c1069435d032ee0F9F150e5c
• avax 0xbACEB8eC6b9355Dfc0269C18bac9d6E2Bdc29C4F
• boba 0x2f686751b19a9d91cc3d57d90150bc767f050066
• bsc 0xD75F5369724b513b497101fb15211160c1d96550
• ethereum 0x044b75f554b886A065b9567891e45c79542d7357
• fantom 0x3e603C14aF37EBdaD31709C4f848Fc6aD5BEc715
• fuse 0x2f686751b19a9d91cc3d57d90150Bc767f050066
• gnosis 0x145d82bCa93cCa2AE057D1c6f26245d1b9522E6F
• moonbeam 0x1838b053E0223F05FB768fa79aA07Df3f0f27480

0xngmi

async function detectPush0Support(rpcs) {
    return (await Promise.all(rpcs.map(async rpc => {
        try {
            const res = await fetch(rpc, {
                method: "POST",
                headers: {
                    "Content-Type": "application/json"
                },
                body: JSON.stringify({
                    "method": "eth_call",

0xngmi

Introduction

EigenLayer introduces the possibility of re-using ethereum consensus, and IMO the most interesting usecase for that would be building a decentralized two-way and security-optimal bridge between Bitcoin and Ethereum.

All bridges rely on the security of the two chains they connect and the security of the custodian^[1] used for bridging, since if the security of any of those 3 were to fail, it would be possible to drain the bridge (eg: if its possible to double-spend on any of the two chains an attacker can redeem the same coin multiple times).

However, if a significant amount of the total ETH staked were to be restaked securing this bridge, the custodian would be piggybacking on ethereum security, so those two become the same and thus you'd remove the custodian from your list of dependencies and you're left with only having to depend on the security of the two chains, which is the theoretical ceiling of security. In other words, you'd achieve the best possible security.

But not just that, you

0xngmi

Optimized lending protocol for redeemable assets

Currently a significant portion of usage across all lending markets comes from carry trades between an asset and their derivatives.

To explain how this works let's assume that on AAVE borrowing ETH costs 1%, but stETH yields 3%. This opens up a trade where you deposit stETH, borrow ETH, swap it for stETH and repeat the trade again, looping the position and arbing the rates. In this position you earn 3% but pay only 1%, so you're earning 2% net.

Some examples of these trades in the wild are:

• Flux finance, a compound fork purely focused on borrowing stablecoins against treasuries for carry trades
• AAVE, which has a 5.8bn stETH and ~1bn weETH, both used for looping against ETH. Together, these account for ~45% of aave's TVL
• Morpho, which hosts users looping sUSDe against DAI
• Compound, which hosted large arb trades against cbETH

0xngmi

Background

In the current market, yield farmers have only 2 options: either deposit into a yield aggregator that completely manages their money for them, making all the risk assessments and moving their money between protocols, or just run everything on their own, moving their money continuously between protocols, at most using an auto-compounder on a single vault for some automation.

However, not everyone has the same risk profile and thus fully managed aggregators won't fit everyone, while on the other hand there's a big market of people that don't like constantly having to manage their positions and shuffle their funds. These two options are the 2 extremes, either fully managed or DYI.

Because of this I believe there's a market for users that want some automation while being able to set their own risk profile.

Idea

I propose a protocol where users deposit funds along with policies on how those funds can be deployed, and then the protocol optimizes their position within those boundaries and automat

0xngmi

One shot signatures as a solution to Bitcoin's security budget

There's significant concern about the long term security of the Bitcoin network, since BTC rewards, which currently account for most miner revenue, keep dwindling at an exponential rate over time, and if total miner revenue gets low enough it becomes possible to exploit the bitcoin network to double-spend.

Proposed solutions to this usually involve either BTC price increasing to maintain security budget even with less rewards or an increase of onchain activity and, along with it, fees paid to miners, which has the side-effect of increasing fees for all other bitcoin users as well.

But what if there was another solution? One-shot signatures is a cryptography construction that enables the creation of public keys for which only a single signature can be generated, after which the keys self-destruct.

Now imagine every wallet stored a set of genesis UTXOs, and then when somebody paid you they would send you

0xngmi

List of domains that are registered with squarespace and thus could be vulnerable:

celer.network
pendle.finance
karak.network
compound.finance
hyperliquid.xyz
dydx.exchange
thorchain.com
threshold.network