feat: update wonderland xyz domain (#107)

0xLukeDev · web-flow · commit ab3fd5fbfeb5 · 2025-11-04T14:24:48.000-03:00
- Replaced old defi.sucks links for wonderland.xyz
- Replaced old defi.sucks for wonderland.xyz in the 'Repo Readiness'
section.
diff --git a/sites/wonderland/blog/2022-12-26-oracle-manipulation-101-math-edition.md b/sites/wonderland/blog/2022-12-26-oracle-manipulation-101-math-edition.md
@@ -15,7 +15,7 @@ This article is divided into two.
 
 In the first part, we will present a quick refresher on how Uniswap works specifically tailored to the needs of computing manipulation costs. It'll explore how to move the spot price in an AMM to the desired target for Uniswap v2 and v3.
 
-The second part will show how we obtained the results from the ["Oracle Manipulation 101"](https://defi.sucks/insights/oracle-manipulation-101) article. To do so, we will present step-by-step an attack of a lending protocol in DeFi. This case can be later generalized to different types of markets.
+The second part will show how we obtained the results from the ["Oracle Manipulation 101"](https://wonderland.xyz/insights/oracle-manipulation-101) article. To do so, we will present step-by-step an attack of a lending protocol in DeFi. This case can be later generalized to different types of markets.
 
 You can follow along with the simulations provided in this [colab](https://colab.research.google.com/drive/1RwpF-lKq968mvsyL0jgyw9rO_cTqYxPl?usp=sharing).
 
@@ -265,11 +265,11 @@ You can gain more by playing around at [this link](https://colab.research.google
 
 ## Oracle Manipulation 101 Math
 
-In the [Oracle Manipulation 101 article](https://defi.sucks/insights/oracle-manipulation-101), we have presented a study case for an oracle manipulation analysis. In particular, we have explained how an attack on a lending market can become profitable. This section will show how many of the results we have presented were derived.
+In the [Oracle Manipulation 101 article](https://wonderland.xyz/insights/oracle-manipulation-101), we have presented a study case for an oracle manipulation analysis. In particular, we have explained how an attack on a lending market can become profitable. This section will show how many of the results we have presented were derived.
 
 As a brief rundown, attacks will likely happen if the profit from manipulation exceeds the cost of manipulation. Understanding this is fundamental to setting the parameters that allow for capital efficiency without adding new risks.
 
-The Cost of Manipulation refers to the capital used ti borrow + capital used to move an AMM's price to the desired target. The latter is what we deduced in the Uniswap Math section above, both for Uniswap v2 and v3. As mentioned in [Oracle Manipulation 101](https://defi.sucks/insights/oracle-manipulation-101), we will consider Full Range positions for this analysis, which is consistent with our previous claims about concentrated positions.
+The Cost of Manipulation refers to the capital used ti borrow + capital used to move an AMM's price to the desired target. The latter is what we deduced in the Uniswap Math section above, both for Uniswap v2 and v3. As mentioned in [Oracle Manipulation 101](https://wonderland.xyz/insights/oracle-manipulation-101), we will consider Full Range positions for this analysis, which is consistent with our previous claims about concentrated positions.
 
 We will exclude trading fees for simplicity of reading, but you can trivially add them to the analysis.
 
diff --git a/sites/wonderland/blog/2022-12-26-oracle-manipulation-101.md b/sites/wonderland/blog/2022-12-26-oracle-manipulation-101.md
@@ -104,7 +104,7 @@ Before PoS, for relevant enough markets, manipulating the price back to the init
 
 Let's assume that the attacker knows that arbitrage will happen and that the pool has a Full Range position with liquidity $L$. In this situation, the best plan is to borrow as much as possible (sell high) using the capital obtained from the manipulation. They could then swap the difference for a price close to $P_i$.
 
-> ✅ We showed in the [Math article](https://defi.sucks/insights/oracle-manipulation-101-math-edition) that this attack could be profitable only if the attack length is close to the length of the $TWAP$. This can be easily taken into account by setting the correct parameters.
+> ✅ We showed in the [Math article](https://wonderland.xyz/insights/oracle-manipulation-101-math-edition) that this attack could be profitable only if the attack length is close to the length of the $TWAP$. This can be easily taken into account by setting the correct parameters.
 >
 > Attacking a pool with healthy liquidity was extremely hard to do pre-PoS.
 
@@ -152,7 +152,7 @@ How would an optimal attack scheme look post-PoS for a validator with $n$ consec
 
 An attacker could also manipulate the TWAP without getting arbitraged if they propose several non-consecutive batches of blocks where they must sacrifice the final block of each batch to close the manipulation.
 
-> ⚠️ The [Math article](https://defi.sucks/insights/oracle-manipulation-101-math-edition) shows that this attack can easily reach profitability, even after considering the $TWAP$. Increasing the $TWAP$ parameters will require the attacker to have a more significant up-front capital (redeemable after the attack). The absence of arbitrage in this scenario makes everything smoother from the attacker's perspective.
+> ⚠️ The [Math article](https://wonderland.xyz/insights/oracle-manipulation-101-math-edition) shows that this attack can easily reach profitability, even after considering the $TWAP$. Increasing the $TWAP$ parameters will require the attacker to have a more significant up-front capital (redeemable after the attack). The absence of arbitrage in this scenario makes everything smoother from the attacker's perspective.
 
 ![img/blog-posts/oracle-manipulation-101/graph-2.jpg](/img/blog-posts-img/oracle-manipulation-101/graph-2.jpg)
 
diff --git a/sites/wonderland/blog/2023-04-05-a-mev-racing-story.md b/sites/wonderland/blog/2023-04-05-a-mev-racing-story.md
@@ -81,7 +81,7 @@ Although the recent patches have reduced the risk of attacks, it has not entirel
 
 ![](/img/blog-posts-img/a-mev-racing-story/meme.jpg)
 
-The chances of a malicious validator winning a race in the same block are “““low”””. However, multiblock attacks are a **very real and serious concern**. Validators from large validator pools, such as Coinbase, Binance, Lido, and Rocketpool, hold a significant portion of the validator power. There is a [high probability](https://alrevuelta.github.io/posts/ethereum-mev-multiblock) that stakers will propose multiple blocks in a row, and coordination among validators is also possible if the potential reward is significant. This was also one of the main reasons we built [PRICE](https://oracles.rip), an oracle that is able to detect and correct [TWAP multiblock manipulations](https://defi.sucks/insights/oracle-manipulation-101).
+The chances of a malicious validator winning a race in the same block are “““low”””. However, multiblock attacks are a **very real and serious concern**. Validators from large validator pools, such as Coinbase, Binance, Lido, and Rocketpool, hold a significant portion of the validator power. There is a [high probability](https://alrevuelta.github.io/posts/ethereum-mev-multiblock) that stakers will propose multiple blocks in a row, and coordination among validators is also possible if the potential reward is significant. This was also one of the main reasons we built [PRICE](https://oracles.rip), an oracle that is able to detect and correct [TWAP multiblock manipulations](https://wonderland.xyz/insights/oracle-manipulation-101).
 
 ## Attack breakdown
 
diff --git a/sites/wonderland/blog/2024-06-03-lc-bridges.md b/sites/wonderland/blog/2024-06-03-lc-bridges.md
@@ -34,7 +34,7 @@ So, what can we do? What is the trust-minimized solution to cross-chain?
 
 ### State proofs: an incomplete path
 
-In a [previous post](https://defi.sucks/insights/current-state-of-storage-proofs), we went deep on state proofs; they allow anyone to verify a claim about a VM’s state from a single cryptographic commitment—the state root. This allows for arbitrary claims about another chain’s state or transactions. Moreover, the same state root is sufficient for every cross-chain application, making it a more scalable solution than passing individual messages around.
+In a [previous post](https://wonderland.xyz/insights/current-state-of-storage-proofs), we went deep on state proofs; they allow anyone to verify a claim about a VM’s state from a single cryptographic commitment—the state root. This allows for arbitrary claims about another chain’s state or transactions. Moreover, the same state root is sufficient for every cross-chain application, making it a more scalable solution than passing individual messages around.
 
 As long as we trust the cryptographic primitives, falsifying a state proof is impossible. But this is only partially true: what if the root is not the right one? Who or how is the root uploaded? This has historically been the most painful point for cross-chain communication.
 
@@ -154,7 +154,7 @@ The problem is that there isn’t a pre-compile nor efficient implementation in
 
 Here is where ZK comes into play: we can create succinct arguments of knowledge (SNARKs) proving the correct execution of complex offchain computation.
 
-> Quoting from a previous post: https://defi.sucks/insights/current-state-of-storage-proofs
+> Quoting from a previous post: https://wonderland.xyz/insights/current-state-of-storage-proofs
 >
 > [Succinct](https://www.succinct.xyz/) developed a [contract](https://etherscan.io/address/0xaa1383ee33c81ef2274419dd5e0ea5cce4baf6cc#code) that verifies a zk-proof of consensus, where anyone can post a zkSNARK attesting that the sync committee has signed a block header. Their design also requires keeping track of the current sync committee, which is done via a zkSNARK. The protocol is deployed on Ethereum and other chains, but the light client updates are operating [frequently only on Goerli](https://explorer.telepathy.xyz/). Each update in Ethereum costs [300k in gas](https://etherscan.io/tx/0x6d608c89eb97b249f40fc1db4306fe0b5af4d0dec3e1db1b8872b3ddf8c5af75). They enable light client proofs of Ethereum and Gnosis to Ethereum, Gnosis, Arbitrum, Avalanche, Binance, Optimism and Polygon (find the address [here](https://docs.telepathy.xyz/resources/contract-addresses)).
 >
diff --git a/sites/wonderland/docs/development/research/research-overview.md b/sites/wonderland/docs/development/research/research-overview.md
@@ -6,7 +6,7 @@ sidebar_position: 1
 
 # Research Overview
 
-Welcome. This section explains how Research fits across the project lifecycle and how we create value (from background work to design reviews and post‑launch notes). If you’re new, skim the [Project Lifecycle](https://handbook.defi.sucks/docs/processes/project-lifecycle) first.
+Welcome. This section explains how Research fits across the project lifecycle and how we create value (from background work to design reviews and post‑launch notes). If you’re new, skim the [Project Lifecycle](https://handbook.wonderland.xyz/docs/processes/project-lifecycle) first.
 
 ## What's Inside
 - **Manifesto**: The core values we expect from the research team.
diff --git a/sites/wonderland/docs/processes/github/repo-readiness.md b/sites/wonderland/docs/processes/github/repo-readiness.md
@@ -30,11 +30,11 @@
     - Contributors footer
         
         ```markdown
-        PROJECT NAME was built with ❤️ by [Wonderland](https://defi.sucks).
+        PROJECT NAME was built with ❤️ by [Wonderland](https://wonderland.xyz).
         
         Wonderland is the largest core development group in Web3. Our commitment is to a financial future that's open, decentralized, and accessible to all.
         
-        [DeFi sucks](https://defi.sucks), but Wonderland is here to make it better.
+        DeFi sucks, but [Wonderland](https://wonderland.xyz) is here to make it better.
         ```
         
     - Add a SECURITY file.

Original file line number	Diff line number	Diff line change
`@@ -34,7 +34,7 @@ So, what can we do? What is the trust-minimized solution to cross-chain?`
`34`	`34`
`35`	`35`	`### State proofs: an incomplete path`
`36`	`36`
`37`		`-In a [previous post](https://defi.sucks/insights/current-state-of-storage-proofs), we went deep on state proofs; they allow anyone to verify a claim about a VM’s state from a single cryptographic commitment—the state root. This allows for arbitrary claims about another chain’s state or transactions. Moreover, the same state root is sufficient for every cross-chain application, making it a more scalable solution than passing individual messages around.`
	`37`	`+In a [previous post](https://wonderland.xyz/insights/current-state-of-storage-proofs), we went deep on state proofs; they allow anyone to verify a claim about a VM’s state from a single cryptographic commitment—the state root. This allows for arbitrary claims about another chain’s state or transactions. Moreover, the same state root is sufficient for every cross-chain application, making it a more scalable solution than passing individual messages around.`
`38`	`38`
`39`	`39`	`As long as we trust the cryptographic primitives, falsifying a state proof is impossible. But this is only partially true: what if the root is not the right one? Who or how is the root uploaded? This has historically been the most painful point for cross-chain communication.`
`40`	`40`
`@@ -154,7 +154,7 @@ The problem is that there isn’t a pre-compile nor efficient implementation in`
`154`	`154`
`155`	`155`	`Here is where ZK comes into play: we can create succinct arguments of knowledge (SNARKs) proving the correct execution of complex offchain computation.`
`156`	`156`
`157`		`-> Quoting from a previous post: https://defi.sucks/insights/current-state-of-storage-proofs`
	`157`	`+> Quoting from a previous post: https://wonderland.xyz/insights/current-state-of-storage-proofs`
`158`	`158`	`>`
`159`	`159`	> [Succinct](https://www.succinct.xyz/) developed a [contract](https://etherscan.io/address/0xaa1383ee33c81ef2274419dd5e0ea5cce4baf6cc#code) that verifies a zk-proof of consensus, where anyone can post a zkSNARK attesting that the sync committee has signed a block header. Their design also requires keeping track of the current sync committee, which is done via a zkSNARK. The protocol is deployed on Ethereum and other chains, but the light client updates are operating [frequently only on Goerli](https://explorer.telepathy.xyz/). Each update in Ethereum costs [300k in gas](https://etherscan.io/tx/0x6d608c89eb97b249f40fc1db4306fe0b5af4d0dec3e1db1b8872b3ddf8c5af75). They enable light client proofs of Ethereum and Gnosis to Ethereum, Gnosis, Arbitrum, Avalanche, Binance, Optimism and Polygon (find the address [here](https://docs.telepathy.xyz/resources/contract-addresses)).
`160`	`160`	`>`