
{"id":13835,"date":"2026-02-03T13:36:16","date_gmt":"2026-02-03T16:36:16","guid":{"rendered":"https:\/\/moderniza.me\/casadainformatica\/?p=13835"},"modified":"2026-10-11T20:51:00","modified_gmt":"2026-10-11T23:51:00","slug":"mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks","status":"publish","type":"post","link":"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/","title":{"rendered":"MEV Protection on UniswapX: How Solvers Prevent Front-Running and Sandwich Attacks"},"content":{"rendered":"<p>A cryptocurrency trader submits a swap order worth $500,000 on a decentralized exchange. Within seconds, before the trade executes, a bot detects the pending transaction and places its own order ahead, driving up the price. When the original trade settles, it receives fewer tokens than expected. The bot then sells its position for a profit, having extracted value directly from the legitimate trader. This scenario describes maximal extractable value\u2014MEV\u2014and it has cost Ethereum users billions of dollars since the network&#8217;s inception. Traditional automated market makers like Uniswap V2 and V3 broadcast transactions to the public mempool, where they become visible to searchers and validators who can reorder them for profit.<\/p>\n<p>UniswapX represents a fundamental shift in how decentralized trading can work. Rather than broadcasting swap requests to a public mempool where front-runners operate, the protocol uses an intent-based architecture where traders express what they want in a signed message, then specialized participants called solvers compete to find the best execution without access to ordering power. This design removes the direct visibility and temporal arbitrage that enable front-running and sandwich attacks. Understanding how this mechanism works\u2014and its limitations\u2014is essential for traders choosing where to execute large or sensitive orders. The architecture is not perfect, but it demonstrates how MEV protection on UniswapX changes the fundamental threat model that users face.<\/p>\n<p><img src=\"https:\/\/sites.google.com\/sitesv-images-rt\/AMxu72unrZ1-f7S_dQse5LMI32sYKMtvR1pDO4wB_kYrM77TUzUAzGHpQo-ftgMosvIbp5gTS7L8Rkxw81wHtyUOQgCVbX8IfJyBE2uWQdDHln4-ALK2haysnAZQIf2IwMgXzMpiF7V9QScMi36Z7n1nQdzyNxNEJh6qhsfGWc7tty9s9FhKSyT6pAGr_4SvfSubYRoKBiFJS1tAC1Llj2LQ\" alt=\"Diagram showing the intent-based solver architecture of UniswapX compared to traditional mempool-based AMM execution, illustrating how solvers compete to fulfill signed orders without front-running opportunities.\" \/><\/p>\n<h2>Why traditional Uniswap versions remain vulnerable to MEV<\/h2>\n<p>Uniswap V2 and V3 operate through the public mempool model: a user constructs a swap transaction, signs it, and broadcasts it to the network. Every node, validator, searcher, and bot sees that transaction before it is included in a block. This visibility window is where MEV attacks thrive. A searcher monitoring the mempool spots a $100,000 swap order and recognizes an opportunity. They submit their own transaction with a higher gas price, ensuring it executes first. The searcher&#8217;s trade moves the price in the pool, making the user&#8217;s swap execute at a worse rate. The searcher then submits a third transaction to exit the position and pocket the difference. This three-step attack\u2014front-run, sandwich, and profit extraction\u2014is so common on Uniswap that experienced traders expect to lose 0.5% to 2% of transaction value to MEV on medium-sized orders during normal market conditions.<\/p>\n<p>The problem compounds during periods of volatility or when trading large positions. A $5 million swap on Uniswap V3 may trigger dozens of competing searchers and bots, each trying to extract value. The user submits what looks like a simple trade but instead triggers a cascade of transactions that move prices significantly. The slippage displayed in the wallet interface often underestimates the real cost because it cannot account for all the reordering that will occur between mempool broadcast and actual settlement. Network congestion makes the problem worse; the longer a transaction sits waiting for inclusion, the higher the chance that conditions change and that front-runners find profitable opportunities.<\/p>\n<p>Uniswap V3&#8217;s concentrated liquidity design introduced tighter spreads and more efficient capital use, but it did not solve MEV. If anything, tighter liquidity makes price movements more visible and therefore more exploitable. A large trade that moves the concentrated liquidity range becomes a clear signal to searchers that they should reposition their own capital or sandwich the order. The protocol functions correctly from a technical standpoint; the economic incentives simply favor extraction of MEV once a swap is broadcast to the mempool.<\/p>\n<p>This is not a flaw unique to Uniswap. Any protocol that relies on the public mempool faces the same attack surface. The solution requires changing when and how the protocol learns about user intent. Rather than broadcasting complete swap details and letting searchers react, a different model keeps the user&#8217;s order private until execution is guaranteed\u2014or at least until the user has received a binding commitment on price.<\/p>\n<h2>How UniswapX uses intent-based architecture to prevent front-running<\/h2>\n<p>UniswapX inverts the traditional order flow model. Instead of submitting a transaction to the mempool, a user signs an intent: a cryptographic commitment to swap from one token to another under specified conditions. This intent is not broadcast publicly. Rather, it is sent to a private order pool where specialized participants called solvers can see it. A solver&#8217;s job is to take on the obligation to fulfill the intent at the promised price, then arrange execution on-chain in whatever way maximizes their profit\u2014as long as the user receives at least the agreed output amount.<\/p>\n<p>The economic incentive shifts from front-runners to solvers, but in a way that benefits users. A solver earns profit only by fulfilling the intent at or better than the committed price, then executing their own arbitrage or liquidity provision at a tighter margin than the user receives. If three solvers are bidding to fulfill the same order, they compete on price quality rather than on gas price and transaction ordering. The solver that bids the tightest spread wins the right to execute. Critically, this competition happens off-chain before the user&#8217;s transaction is ever broadcast to the public mempool. By the time settlement occurs on-chain, the price and terms are already locked in. A searcher or front-runner cannot see the swap in advance because it is not in the mempool yet.<\/p>\n<p>Users access UniswapX gasless swaps through the same interface where they would use traditional Uniswap. The trade flow is straightforward: sign the intent, select a preferred solver or let the system choose, and receive confirmation once a solver has committed to fulfillment. The &#8220;gasless&#8221; element comes because the solver pays the on-chain transaction cost; the user&#8217;s only out-of-pocket expense is the bid-ask spread, which is built into the intent&#8217;s guaranteed output.<\/p>\n<p>The MEV protection is not absolute. Solvers themselves could theoretically sandwich the order they have committed to fulfilling, but this would cause them to violate the intent contract terms and lose the ability to compete for future orders. Reputation and repeat business incentivize honest execution. Additionally, solvers may use various execution strategies\u2014routing through multiple pools, splitting orders, coordinating with liquidity providers\u2014all designed to keep the user&#8217;s true trade patterns hidden until the moment of settlement. A MEV-aware solver might deliberately obscure the trade&#8217;s size or timing to prevent other market participants from learning about it in ways that could affect the user&#8217;s exit price.<\/p>\n<h2>Solver competition and the real cost of intent-based execution<\/h2>\n<p>UniswapX&#8217;s economic model depends on solvers competing to fulfill intents profitably. This competition is the mechanism that protects users and provides price improvement over traditional Uniswap. When only one solver bids for an order, the user may receive less favorable terms than if five solvers were competing. When no solver bids because the order is too large, too illiquid, or the market is too uncertain, the intent may fail to execute, leaving the user without a trade.<\/p>\n<p>This represents a different trade-off than mempool-based execution. Traditional Uniswap offers certainty: a trade will execute at the slippage you set, subject only to pool liquidity and gas price. UniswapX offers MEV protection and the possibility of price improvement, but introduces the risk that no solver will bid. A solver&#8217;s decision to bid depends on their inventory, risk appetite, market outlook, and operational costs. During volatile markets or when trading unusual token pairs, solver participation may drop significantly. A user who is accustomed to guaranteed execution on Uniswap might experience failed or delayed intents on UniswapX, requiring them to fall back to traditional swap methods.<\/p>\n<p>The spread the user receives also reflects solver competition and their cost of capital. A solver who takes on the obligation to deliver tokens at a specific price is exposed to market risk between the moment they commit and the moment they execute. If the market moves against them, they may lose money or at least recover less profit. They price this risk into their bid. A highly competitive market where solvers have abundant liquidity may produce tight spreads and good user execution. A market where fewer solvers are active, or where uncertainty is high, may produce wider spreads. The user does not directly pay &#8220;MEV&#8221; to an attacker, but they may pay a larger spread to compensate the solver for their risk and cost.<\/p>\n<p>Understanding this trade-off is important for choosing when to use UniswapX versus traditional Uniswap. For a routine trade of major token pairs during normal market conditions, traditional Uniswap may actually be cheaper if MEV is low and you use proper slippage controls. For a large order during volatile conditions, or for a sensitive token where you want to minimize information leakage, UniswapX&#8217;s MEV protection and solver competition may justify a wider bid-ask spread. The choice depends on what you are trading, how much size you have, and whether privacy of order information is important to you.<\/p>\n<h2>Gasless swaps and the solver subsidy model<\/h2>\n<p>A defining feature of UniswapX is that users pay no on-chain transaction fees\u2014solvers cover the gas cost. This is valuable because Ethereum transaction fees can easily exceed $20\u201350 on the mainnet during busy periods, and Layer 2 fees, while lower, still add friction. A gasless swap removes this cost, lowering the barrier to execute small to medium trades that would otherwise be too expensive relative to the trade amount.<\/p>\n<p>The subsidy works because solvers are willing to pay gas costs if the profit from executing the order covers those costs. For a tiny trade worth $100, a solver might lose money on gas fees and thus decline to bid. For a $5,000 order, a solver may bid at a profitable level even after covering gas. The threshold varies by market conditions and network. On Arbitrum or Optimism, where gas costs are measured in cents or fractions of a cent, solvers can profitably execute much smaller orders. On Ethereum mainnet, gasless swaps work best for medium to large orders where the spread is fat enough to cover $20\u201350 in gas.<\/p>\n<p>The gasless subsidy also changes the economics of order routing. A traditional Uniswap trade might route through three pools to find the best price, but each hop adds gas cost. On UniswapX, a solver may route through more pools, split the order across more venues, or use sophisticated algorithms\u2014all without increasing the user&#8217;s cost. This can produce better execution than the user would get on Uniswap V3 even if they paid the gas themselves. For users executing trades on <a href=\"https:\/\/sites.google.com\/uniswap-dex.app\/uniswap-trade-crypto\/\">uniswap<\/a>, understanding whether the interface is routing through the traditional protocol or through UniswapX&#8217;s intent-based system is key to anticipating the cost and execution characteristics.<\/p>\n<h2>Limits of UniswapX protection: Collusion, latency, and liquidity constraints<\/h2>\n<p>No MEV protection system is perfect. UniswapX&#8217;s intent-based architecture solves the front-running problem by keeping orders out of the public mempool, but it introduces new risks that deserve attention. The first is solver concentration. If a small number of solvers capture most order flow, or if solvers collude with each other, they can effectively coordinate to offer poor prices. Users benefit from competition among solvers, which means a fragmented solver ecosystem is actually protective. Regulatory barriers to entry for solvers, or economic conditions that favor incumbent solvers over new entrants, could erode this protection.<\/p>\n<p>The second limitation is latency and timing. Although the intent is not broadcast to the public mempool, solvers still need time to execute the on-chain settlement. If market conditions move quickly, or if a solver delays settlement, a user&#8217;s committed price may become unfavorable even though the user received the agreed amount. The user is protected against front-running, but not against the simple passage of time and market movement. This is why UniswapX includes time limits on intents; after a certain block height, the order expires and can no longer be filled.<\/p>\n<p>The third limitation is that UniswapX cannot protect a user who is using it simultaneously with other trading. If a user submits an intent to buy ETH via UniswapX while also submitting a direct swap for the same token pair on traditional Uniswap, searchers might use the information from the Uniswap broadcast to infer something about the user&#8217;s intent and extract value another way. MEV protection is only effective if the user is not leaking information about their trading intent through other channels.<\/p>\n<p>Liquidity is another constraint. UniswapX relies on solvers having or being able to source the tokens needed to fulfill intents. For major tokens like USDC, ETH, USDT, and DAI, solver liquidity is abundant. For less-traded or new tokens, solvers may have no inventory and no ability to obtain it quickly. A trade intended for an obscure altcoin might fail to attract solver bids, forcing the user to execute on traditional Uniswap where liquidity pools exist. This is not a security flaw, but it is a practical limitation on where the MEV protection actually applies.<\/p>\n<h2>Network deployment and cross-chain MEV challenges<\/h2>\n<p>Uniswap operates on Ethereum mainnet and multiple Layer 2 networks including Arbitrum, Optimism, Base, and Polygon. UniswapX is deployed on these same networks, but with different MEV characteristics on each. Ethereum mainnet is where MEV is most visible and damaging because validators and searchers are most sophisticated and competition for order flow is highest. MEV attacks are measurable and common. Layer 2s like Arbitrum and Optimism have different validator and sequencer models that can alter MEV dynamics. On Arbitrum, the sequencer can extract some MEV, but the transparent ordering and time-delay on batches mean that front-running windows are smaller. On Optimism&#8217;s sequencer model, similar dynamics apply. Base inherits properties from its shared sequencer arrangement with Optimism.<\/p>\n<p>Polygon uses a different consensus model (Proof of Stake with validators) and has its own MEV landscape, which is less studied than Ethereum&#8217;s. The practical consequence is that MEV protection on UniswapX is most valuable on Ethereum mainnet, where the stakes are highest and the attacks are most severe. On Layer 2s, MEV is often lower anyway due to faster finality and tighter validator competition, so UniswapX&#8217;s protection is less critical. However, as Layer 2s grow in volume and economic value, the incentive for MEV extraction on them will increase, making intent-based protection increasingly relevant.<\/p>\n<p>Cross-chain trades present a separate challenge. If a user wants to swap tokens on two different chains\u2014for example, USDC on Ethereum for USDT on Polygon\u2014traditional Uniswap requires using a bridge protocol, which introduces its own MEV and execution risks. UniswapX&#8217;s current architecture handles single-chain intents; multi-chain swaps still require composition of multiple protocols and therefore expose users to MEV on each leg. This is an area where UniswapX&#8217;s MEV protection is incomplete and remains an open problem for the broader DEX ecosystem.<\/p>\n<h2>Practical guidance for choosing MEV protection<\/h2>\n<p>A trader deciding between traditional Uniswap and UniswapX should evaluate four factors: order size, market conditions, token liquidity, and sensitivity to execution timing. For routine trades under $10,000 on major token pairs during calm markets, Uniswap V3 with appropriate slippage tolerance is often sufficient. MEV on these trades is typically small relative to the transaction value, and the guaranteed execution may be preferable to the risk of failed solver bids. For larger trades\u2014$100,000 or more\u2014or trades during volatile periods, UniswapX&#8217;s MEV protection becomes compelling. The spread may be wider, but it is better to accept a known bid-ask spread than to lose a percentage of the order to front-runners.<\/p>\n<p>Trading less-liquid token pairs should drive you toward Uniswap because solver liquidity may not exist for obscure tokens, whereas Uniswap pools, even with poor liquidity, offer at least guaranteed execution. Trading highly sensitive or large positions should push you toward UniswapX because the privacy benefit of keeping the order out of the public mempool has real value. If you are using Uniswap on a Layer 2 like Arbitrum, the MEV already tends to be lower, so the marginal benefit of UniswapX&#8217;s protection is smaller.<\/p>\n<p>From a security perspective, using UniswapX requires trusting that solvers will execute intents honestly. This is not a cryptographic trust\u2014it is an economic and reputational trust. Reputable solvers have incentives to execute orders correctly because their future business depends on maintaining good performance. New or anonymous solvers carry higher risk. Understanding which solver is executing your order and their track record is worth doing for large positions. On smaller orders where the MEV protection is less critical, less scrutiny of the solver is warranted.<\/p>\n<div class=\"faq\">\n<h2>Frequently asked questions<\/h2>\n<div class=\"faq-item\">\n<h3>How is MEV protection on UniswapX different from using Uniswap with a private relay?<\/h3>\n<p>Uniswap&#8217;s traditional design relies on public mempool broadcast, and private relays only hide the transaction from searchers temporarily. Once the transaction is included in a block, the ordering and MEV extraction can still occur. UniswapX&#8217;s intent-based model is fundamentally different: it keeps the user&#8217;s order details off the mempool entirely and allows solvers to compete off-chain to fulfill it, which prevents front-running rather than just delaying it.<\/p>\n<\/p><\/div>\n<div class=\"faq-item\">\n<h3>What happens if no solver bids on my UniswapX intent?<\/h3>\n<p>If no solver accepts your intent within the specified time limit, the order expires and does not execute. You will need to either resubmit the intent with less strict terms (wider slippage tolerance or a lower amount), or fall back to executing the trade on traditional Uniswap or another DEX. This is more likely for small orders, illiquid token pairs, or during periods of extreme market volatility when solvers are risk-averse.<\/p>\n<\/p><\/div>\n<div class=\"faq-item\">\n<h3>Is UniswapX truly gasless, and who pays the transaction cost?<\/h3>\n<p>Yes, UniswapX&#8217;s gasless feature means you pay no on-chain transaction fees as a user. The solver pays the gas cost as part of their operational expense, which they recover through the spread between the price they commit to you and the price they actually achieve. For small trades, this subsidy may not cover the solver&#8217;s gas cost, so you might see no solver bids. For larger trades, the spread is fat enough that solvers accept the gas cost as part of doing business.<\/p>\n<\/p><\/div>\n<\/div>\n<p><!--wp-post-meta--><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A cryptocurrency trader submits a swap order worth $500,000 on a decentralized exchange. Within seconds, before the trade executes, a bot detects the pending transaction and places its own order ahead, driving up the price. When the original trade settles, it receives fewer tokens than expected. The bot then sells&hellip; <\/p>\n","protected":false},"author":711,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"jetpack_featured_media_url":"","yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v15.7 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>MEV Protection on UniswapX: How Solvers Prevent Front-Running and Sandwich Attacks - Casa da Inform\u00e1tica<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MEV Protection on UniswapX: How Solvers Prevent Front-Running and Sandwich Attacks - Casa da Inform\u00e1tica\" \/>\n<meta property=\"og:description\" content=\"A cryptocurrency trader submits a swap order worth $500,000 on a decentralized exchange. Within seconds, before the trade executes, a bot detects the pending transaction and places its own order ahead, driving up the price. When the original trade settles, it receives fewer tokens than expected. The bot then sells&hellip;\" \/>\n<meta property=\"og:url\" content=\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/\" \/>\n<meta property=\"og:site_name\" content=\"Casa da Inform\u00e1tica\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-03T16:36:16+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-11T23:51:00+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/sites.google.com\/sitesv-images-rt\/AMxu72unrZ1-f7S_dQse5LMI32sYKMtvR1pDO4wB_kYrM77TUzUAzGHpQo-ftgMosvIbp5gTS7L8Rkxw81wHtyUOQgCVbX8IfJyBE2uWQdDHln4-ALK2haysnAZQIf2IwMgXzMpiF7V9QScMi36Z7n1nQdzyNxNEJh6qhsfGWc7tty9s9FhKSyT6pAGr_4SvfSubYRoKBiFJS1tAC1Llj2LQ\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\">\n\t<meta name=\"twitter:data1\" content=\"15 minutos\">\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/#website\",\"url\":\"https:\/\/moderniza.me\/casadainformatica\/\",\"name\":\"Casa da Inform\\u00e1tica\",\"description\":\"Compre Online de Lojas Locais\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/moderniza.me\/casadainformatica\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/#primaryimage\",\"inLanguage\":\"pt-BR\",\"url\":\"https:\/\/sites.google.com\/sitesv-images-rt\/AMxu72unrZ1-f7S_dQse5LMI32sYKMtvR1pDO4wB_kYrM77TUzUAzGHpQo-ftgMosvIbp5gTS7L8Rkxw81wHtyUOQgCVbX8IfJyBE2uWQdDHln4-ALK2haysnAZQIf2IwMgXzMpiF7V9QScMi36Z7n1nQdzyNxNEJh6qhsfGWc7tty9s9FhKSyT6pAGr_4SvfSubYRoKBiFJS1tAC1Llj2LQ\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/#webpage\",\"url\":\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/\",\"name\":\"MEV Protection on UniswapX: How Solvers Prevent Front-Running and Sandwich Attacks - Casa da Inform\\u00e1tica\",\"isPartOf\":{\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/#primaryimage\"},\"datePublished\":\"2026-02-03T16:36:16+00:00\",\"dateModified\":\"2026-10-11T23:51:00+00:00\",\"author\":{\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/#\/schema\/person\/0f237803d5c7d4c49331a2d1419b1d80\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/moderniza.me\/casadainformatica\/mev-protection-on-uniswapx-how-solvers-prevent-front-running-and-sandwich-attacks\/\"]}]},{\"@type\":\"Person\",\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/#\/schema\/person\/0f237803d5c7d4c49331a2d1419b1d80\",\"name\":\"casadainformatica\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/moderniza.me\/casadainformatica\/#personlogo\",\"inLanguage\":\"pt-BR\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/6bc73cf3ddcdb43711feae1a002c533e?s=96&d=mm&r=g\",\"caption\":\"casadainformatica\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/posts\/13835"}],"collection":[{"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/users\/711"}],"replies":[{"embeddable":true,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/comments?post=13835"}],"version-history":[{"count":1,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/posts\/13835\/revisions"}],"predecessor-version":[{"id":13836,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/posts\/13835\/revisions\/13836"}],"wp:attachment":[{"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/media?parent=13835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/categories?post=13835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/moderniza.me\/casadainformatica\/wp-json\/wp\/v2\/tags?post=13835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}