Eridanus 🚢

In the water @Harbor_DEX

[Eridanus 🚢 @eridanus_dev]

I’m excited to share that I am one of the founding engineers of @Harbor_DEX. Working with this team to reach this point has been incredible, and I’m fired up about everything we’re building toward. Before I get back to building, I want to share how I think about Harbor’s current work, longer-term vision, and why it’s important.

We built Harbor to serve the cross-chain swapping market, a space that often gives users a bad deal. Cross-chain swaps are:
- often slow (10-40 minutes sometimes for BTC swaps)
- price insensitive (slippage tolerances up to 300 bps): gives plenty of room for poor execution
- opaque in terms of quoting and execution: hard to know what is happening behind the scenes

These factors, coupled with the growing ubiquity of cross-chain aggregators, put liquidity providers in a classic race to the bottom to win volume. However, once the volume is won liquidity networks face little obligation to execute at their quoted price. With wide slippage tolerances available there is the incentive and opportunity for liquidity networks to “quote high, execute low”.

While we can’t fix the slow BTC block times, we can provide more transparency and better execution for cross-chain swappers. On Harbor, the network attempts to execute your swap at exactly the price you were quoted. If the market has moved, the network will slowly move your order towards your slippage tolerance, creating a mini dutch auction among Market Makers for each swap. Competition in this sense will yield the best possible execution for users.

Our current work centers on improving the cross-chain swapping space, but our larger mission at Harbor is to narrow the gap between CeFi and DeFi in liquidity, performance, and feature-set. As self-custodianship becomes more important, we aim to serve a secure and accessible backend that gives any private key access to transparent financial primitives.

I’m grateful to share a bit about what we’ve been working on and where we are heading, and I’m excited to engage more publicly with the community as we build toward this vision.

[Harbor 🚢 @Harbor_DEX]

Today, we are launching Harbor, a Layer 1 network with native asset vaults capable of custodying diverse assets, such as Bitcoin and its UTXO variants (Litecoin, Zcash), Ethereum and its respective L2s, Solana, and more. Harbor’s first application is a cross-chain order book, providing fast and efficient spot trading to service the burgeoning market of cross-chain swaps.

The network employs a dual-actor marketplace to ensure fair pricing and execution for cross-chain swaps. Existing solutions are susceptible to the flaws of solver-based designs, where an “all-or-nothing” approach incentivizes solvers to price quotes ever-higher in the hopes of earning business, but are free to execute wherever they please within a wallet’s price tolerance (usually 3%). Harbor solves this problem by having two separate entities that are naturally opposed to one another: the central limit order book (CLOB) and a smart order router.

The CLOB represents the interest of market makers: performant, programmatic trading APIs allow extremely tight pricing, usually within a single tick of the market’s best bid or ask, at meaningful size.

The smart order router represents the interests of swappers: placing limit orders at exactly the quoted amount, allowing market makers to compete to fill at that price, or regressing the order down the book until it fills or refunds due to price tolerance.

This design ensures that no single market maker is responsible for the execution quality of a swap. The swap is worked through the order book, ensuring the best possible pricing, utilizing liquidity provided by multiple makers, while preventing quotes higher than fillable orders.

We believe Harbor’s design— a hybrid DEX securing custody through threshold signature vaults and a decentralized validator set, paired with a high performance matching engine for speed and execution, along with the ability to support other purpose built “subnets” utilizing its vaults— positions Harbor as the best L1 design capable of delivering neutral, efficient, decentralized, native asset rails. Follow us for more details about our upcoming plans, intro blog post, whitepaper and more.

[Eridanus 🚢 @eridanus_dev]

order book go brrr

[Eridanus 🚢 @eridanus_dev]

Hot take of the day: if you can’t put the weights down lightly it doesn’t count as a rep

[Eridanus 🚢 @eridanus_dev]

@hosseeb The challenge we've seen with RFQ systems is the dislocation of quoting and execution creates perverse incentives for LPs to quote high and execute low. Will be curious to see how Variational addresses these concerns

[Eridanus 🚢 @eridanus_dev]

@yeluacaM @THORChain @yeluacaM @Cointelegraph please remove the malicious "refund portal" link from your article. This did not come from the official THORChain account (@THORChain).

[Eridanus 🚢 @eridanus_dev]

@noordy_ *DeFi is leaking $300 million to someone. Either way, it's a problem

[Eridanus 🚢 @eridanus_dev]

I don’t know how anyone expects all of the world’s financial assets to come on-chain when DeFi is leaking $300 million a month to North Korea

[Eridanus 🚢 @eridanus_dev]

Wishing the @THORChain team well. I'm sure the community will persist as always.

Every protocol handling exogenous capital needs to be doubling and tripling down on security. Everyone with a claude subscription is now an expert-level hacker. Stay safe.

[Eridanus 🚢 @eridanus_dev]

@theoblivionsage @PeckShieldAlert @THORChain I don't think this theory holds weight - new vault addresses are determined by TSS keygen, they aren't determined by any txs to old vaults

[Udi Wertheimer @udiWertheimer]

we’re seeing the same fake “adoption” patterns with agentic crypto payments that we saw with rather forced attempts like lightning payments in the past

there are some major providers who “support” x402 like AWS, vercel, etc, but actually none of them let agents pay *them* with crypto. they let other devs build apps payable with crypto but they don’t accept it themselves

there were a handful of medium-sized api providers focusing on agents that partnered with coinbase to accept x402 payments, like firecrawl for example, but most of those experiments seem to have been abandoned since then and the companies are focusing on traditional payments now

the economics of “agentic micro payments” sound cute on paper but in reality they make as little sense as “human micro payments” do. the agents that are economically interesting for API providers are agents that make millions of calls on a regular basis. those can (and do) use traditional billing. an agent that does a one-off API call for $0.0001 cents with x402 is not economically meaningful and even if you have a million of those it’s still not a business

the services that actually do accept x402 seem to mostly be crypto-related themselves. services that aren’t crypto related don’t seem to find it to be a viable payment method. it’s just crypto companies doing it when they try to market to other crypto bros

sorry

[Eridanus 🚢 @eridanus_dev]

I know at some point these humanoids are going to be impressive, but every demo thus far feels incredibly contrived

[Brett Adcock @adcock_brett]

Figure taught two robots to make a bed together - fully autonomous

Honestly, they’re better at it than most humans

[Eridanus 🚢 @eridanus_dev]

“Find a problem worth solving. Build the thing that tells you when it’s solved. Then get out of the way.” - great way to frame it.

I do think that software/code is less solved than people think, mostly because at scale it’s less verifiable (to use your framing). Yes you can easily determine if a single component is working correctly, but it’s much harder to verify that hundreds of components, across many independent services, operating on different infrastructure is in fact working as intended.

[Eridanus 🚢 @eridanus_dev]

Wow. Incredible L1 feature

[Tempo @tempo]

Per-customer deposit addresses are live on Tempo.

On most chains, giving every customer a unique deposit address means initializing, monitoring, and sweeping a real onchain wallet for each.

With virtual addresses, funds credit directly to a master wallet at the protocol layer.

[nicolas, 30 ans @nic_carter]

Sat down with @pluto_hbr for @OnTheBrinkCIV to talk KelpDAO, deep security in DeFi, Aave, LayerZero, Thorchain, Harbor, and where DeFi goes from here

https://t.co/kLwZRYHizh

[Eridanus 🚢 @eridanus_dev]

@bobsenz @lex_node @THORChain @ethereum I don’t think anyone is arguing that thorchain is THE issue. And yes, the first priority is to not get hacked. But again, if TC can do something to help, maybe they should.

[Eridanus 🚢 @eridanus_dev]

The more relevant question in play is: can @THORChain validators censor transactions?
https://t.co/eT0vktiJHB

The truth is, which thorchads may not like, that THORChain validators absolutely have the ability to censor transactions, but, to be fair, it would be undeniably messy and imperfect.

So, how would they do it?
Each validator has the ability/responsibility to observe inbound txs, but they also have the ability to ignore any particular deposit. So, validators could integrate with screening services such as elliptic, TRM, etc, query the sender and the destination address, and use the response to determine if the tx is too "risky" to process. If 32/95 validators ignore any inbound it would not be processed by the network (black-holed on the vault EOA).

However, if a deposit ends up reaching consensus (64/95 observe), those that ignored the deposit would be slashed, and they would lose a portion of their rewards for this churn period. So, unfortunately, there is an economic incentive for TC nodes to observe any valid inbound, whether it be from an exploit wallet or not. That is, unless, more than 33% of active nodes actively screen.

Additionally, screening services are historically imperfect. They may successfully flag an exploiter's address 90-95% of the time, but quick fan outs + deposits mean that sometimes funds get passed these services. Just look at Chainflip - they have network-wide screening in place, but several times had to pause eth/arb altogether as attacker txs were still getting through: https://t.co/kMCACwoAT4

Playing out the scenario where TC does successfully screen an inbound, the question becomes: what to do next? There's basically three options the validators have: manually refund the inbound, manually execute the swap, or do nothing an let the funds remain on the retiring vault forever.

So to summarize: actively censoring inbound txs is feasible for @THORChain, but it wouldn't be perfect, txs would still get through, and txs that are successfully screened would create further questions and operational overhead.

[Eridanus 🚢 @eridanus_dev]

Here's a brief @THORChain 101, from someone who was deep in that codebase for 4+ years.

THORChain has 95 active validators, which are organized into 5 different “asgard” vaults. Asgard vaults are simple EOAs that are operated by their validator membership (19 nodes per vault) via threshold signatures. Here’s the actual endpoints to hit to see the live membership/vaults:
nodes: https://t.co/Y605nk3Ngo
vaults: https://t.co/IMHHMqAU4R

THORChain “churns” every 3 days, some validators leave, some enter, new vaults are generated via keygen, and funds rotate from old to new.

A swap happens through 3 basic stages: Observation, Execution, and Outbound signing.

Observation
In order for a swap to happen on THORChain, a supermajority of ALL validators need to observe, sign, and agree on the inbound tx to one of the vaults. This means with today’s active set effectively 64/95 validators need to observe and sign off on the inbound. This inbound tx on ETH or BTC contains a memo instructing the network on what to do with it.

Execution
Once an inbound reaches consensus, the network begins executing the swap based on the instructions encoded in the memo. The memo contains the desired output asset, limit, and destination address. The swap occurs on THORChains AMM, and once complete, an outbound is scheduled to one of the 5 asgard vaults.

Outbound signing
The vault that is assigned to send the outbound goes through the keysign ceremony: each member validator signs the same onchain tx via TSS, and once a supermajority of that vault has signed the tx, it is broadcasted on chain (effectively a 13/19 threshold signature).

So, basically, 64/95 validators need to agree to process a transaction, need to agree on the execution/outbound, and 13/19 actually sign it out. If 32/95 validators refused to process an inbound it would be black-holed onto the vault EOA, the network would have no record of it, and nothing would happen with those funds without further intervention.

[Eridanus 🚢 @eridanus_dev]

@CatGdude @tayvano_ @THORChain Clearly!

[Eridanus 🚢 @eridanus_dev]

@bobsenz @lex_node @THORChain @ethereum If it’s an ethos thing, then the TC community needs to stop arguing that it can’t do something and simply say it won’t

[Eridanus 🚢 @eridanus_dev]

@SavcatEth @THORChain Yeah and to be clear I applaud Chainflip for taking action to the extent that it can. Was highlighting CF to show that screening is not a perfect solution

[Eridanus 🚢 @eridanus_dev]

Two responses:

1. just because someone else can do something, and doesn’t, doesn’t mean you shouldn’t do something if you can.
2. It would be many orders of magnitude easier for TC validators (who are all in the same discord) to coordinate a response, than it would be for ethereum validators (if at all possible).

[Eridanus 🚢 @eridanus_dev]

@tayvano_ @THORChain Agree that TC can and should do something

[Eridanus 🚢 @eridanus_dev]

Agree, easiest thing to do is pause the route (which TC validators do have the ability to do), but the question becomes how long do you keep the route paused? Theoretically the attackers can just wait it on ETH and resume the txs when things are unpaused. Then we are back to relying on screening, which yes, can easily catch 99% of txs, but may not catch all of them