TL;DR: Curvy built a proof-of-concept where an AI agent discovers yield opportunities via LI.FI Earn, then deposits and withdraws privately through Curvy’s ZK shielded pool, on mainnet, across any supported chain and token. Vault discovery is public by design. The deposits and withdrawals are not. An observer sees a random address with no prior history moving funds through LI.FI into a DeFi protocol with no way to tell who owns the funds or where they came from.

---

We were running the agent through a full yield farming flow on mainnet. The agent picked a vault, deposited, withdrew, and the only thing visible on-chain was a fresh address with no history moving USDC through LI.FI. No identity. No strategy. No connection to whoever was running the agent. That’s the thing we actually set out to build, and this is how it works.

The Stack

CROPS.cash is a CLI and npm package built on the Curvy SDK. It’s the interface layer that lets an AI agent interact with Curvy’s shielded pool using natural language commands via a skill definition: check balances, discover yield opportunities, deposit, check positions, withdraw. No UI, no manual transaction signing.

Curvy is the ZK privacy layer underneath. Funds sit in a shielded pool as encrypted Notes, invisible to any external observer. When the agent needs to act, Curvy unshields a specific amount to a fresh one-time address with no prior on-chain history. That address is used once and never again. Whether generation happens client-side or gets absorbed into the Curvy backend as the protocol matures, the privacy property holds either way.

LI.FI handles the other half: vault discovery via the Earn API across supported protocols on any chain, and actual deposit routing via LI.FI Diamond. Any token supported by both LI.FI and Curvy Protocol works here.

Transactions are gasless. The one-time address has no ETH because gas is covered at the protocol level so the agent never has to manage a funding wallet or pre-load gas on a fresh address.

What the AI Agent Actually Does

The full flow, driven through Claude Code reading the crops.cash skill definition:

No UI after initial onboarding. No transaction signing prompts. No ETH needed for gas. The agent queried live vaults, picked one, deposited, then withdrew. Two transactions on Arbitrum mainnet:

• Deposit: 0xbe3e…b1f2
• Withdraw: 0x7021…8376

An observer looking at those transactions sees a fresh address with no history, USDC moving through LI.FI Diamond into a DeFi vault, then back out. The amount and vault are visible but the origin of funds is broken at the ZK level.

Why the Privacy Model Works Here

Two things break the link between the agent’s actions and any identity.

ZK-sourced funds. The USDC came from Curvy’s shielded pool, where funds exist as encrypted Notes. No external party can see balances, ownership, or movement history. When Curvy unshields to the one-time address, the withdrawal is provably valid but reveals nothing about which note it came from or who owns it.

One-time addresses. Each position uses a fresh address with no prior transaction history and no on-chain connection to anything the user controls. Used once, then gone.

What remains visible is the amount, the vault, and the timing. That’s the honest part of the privacy model, and it’s worth stating clearly. The origin of funds and the identity behind the agent are what’s actually hidden. For most threat models, that’s the part that matters.

The Fee Structure

Total round-trip on the privacy and yield layer: approximately 0.8%. As we learn how agents actually use this in practice, the economics will be tuned to fit real usage patterns rather than assumed ones.

Why AI Agents Need Privacy

A trading agent running a strategy on a public wallet is permanently readable. Competitors can front-run, MEV bots can target recurring patterns, and anyone can reconstruct the strategy from historical transactions. Most agent builders know this but treat it as a future problem. It isn’t.

Yield strategies have the same exposure, just slower. An agent depositing into vaults at regular intervals is broadcasting that strategy. The deposit patterns, vault choices, and timing create a fingerprint linkable across positions even when the underlying wallet rotates. Privacy at the fund source level is what prevents that fingerprint from forming in the first place, and it has to be baked in at the infrastructure layer because there’s no fixing it once the trail exists.

There’s a receiver side to this too. A merchant or protocol accepting payments from agents gets a payment origin tied to a specific identity: pricing can be gamed, volume analyzed, counterparties profiled. Curvy breaks the link on both ends.

This isn’t about hiding from regulators. It’s the same operational security any fund manager takes for granted when routing orders through a prime broker: your counterparties don’t need to know your full book.

What Comes Next

The next step is pulling ephemeral address generation into the Curvy core protocol rather than being handled at the CLI layer. The key property (a fresh address with no linkable history per position) stays intact regardless of where generation happens, and owning that primitive at the protocol level is the right place for it.

On the distribution side, the crops.cash skill file is already structured so any agent can read it and act on it without additional integration work. The infrastructure is there. The surface area for agents to build on top of it is already open – github.com/0xCurvy/crops.cash

You Can Try It Now

On-chain agents are going to manage real money at scale. The infrastructure needs to be built for that from the start.

LI.FI handles discovery and routing. Curvy handles the privacy layer. Together they make it possible for an agent to earn yield without broadcasting the strategy, the position size, or who’s behind it.

Try CROPS.cash: crops.cash

LI.FI Earn docs: docs.li.fi

For most of crypto’s history, the industry has focused on making transactions possible.

First it was sending assets. Then came smart contracts. Then bridges, rollups, intent systems, and increasingly sophisticated infrastructure for moving value across chains.

Each wave made crypto more usable. Assets became easier to transfer, applications became easier to build, and liquidity became easier to access.

But as the industry optimized for efficiency, scalability, and interoperability, another question received far less attention:

What information becomes visible every time a transaction takes place? As crypto evolves from a speculative asset class into a foundation for real economic activity, that question is becoming increasingly important.

Cross-Chain Swaps Got Easier. Privacy Didn’t.

Cross-chain swaps have come a long way. A few years ago, moving assets between ecosystems was often frustrating, expensive, and risky. Today, we have bridges, aggregators, intent systems, and increasingly polished user experiences. For the most part, the industry has figured out how to move value between chains.

What it hasn’t figured out is privacy.

Every swap leaves behind a trail. Not just of where funds came from and where they ended up, but of how you use crypto. Which chains you prefer, when you move assets, how often you trade, and which protocols you interact with. Over time, those activities become patterns, and those patterns become profiles.

Most people don’t think much about this because public blockchains have conditioned us to accept transparency as the default. The assumption is that if transactions are verifiable, then everything about them should be visible. But those are two different ideas.

The Real Problem Isn’t Transparency

One of the most important innovations introduced by blockchains is the ability to independently verify state. Anyone can audit transactions, verify balances, and validate that the system behaves as expected. That transparency creates trust at the network level.

The problem is that transparency at the network level often spills over into the user experience.

As crypto becomes less about speculation and more about real economic activity, that distinction starts to matter. Businesses don’t want every treasury movement exposed. Individuals don’t necessarily want their financial behavior mapped forever. Future AI agents acting on behalf of users will generate even larger amounts of transactional activity, making execution data increasingly valuable to observe and analyze.

Verifiability vs. Visibility

The question is no longer whether systems should be verifiable. The question is whether every action performed inside those systems needs to become part of a permanent public record.

This is where our thinking around privacy has gradually shifted.

Many privacy discussions focus on balances. Can someone see how much I own? Can someone identify my wallet? Those questions matter, but they don’t fully capture the problem.

Execution Reveals More Than Balances

In practice, execution often reveals far more than balances ever could.

When someone performs a swap, their goal is simple: they want one asset to become another. They don’t necessarily want the route, timing, counterparties, chain preferences, and execution details to become publicly observable in the process. Yet this is exactly how most cross-chain infrastructure works today.

The Thinking Behind Curvy Swap

If we’re building infrastructure for private and compliant transaction execution, swaps are a natural place to apply it.

But as we started thinking about the product, we found ourselves asking a different question. Why does almost every swap begin by asking users to connect a wallet?

In most cases, the user hasn’t even defined what they’re trying to do yet. The first interaction is immediately technical: connect a wallet, approve permissions, switch networks, sign transactions, and only then begin the actual process.

We wanted to explore a different approach.

Start With Intent, Not Wallets

With Curvy Swap, the process starts with intent. Users choose what they’re sending, what they want to receive, and where the funds should ultimately arrive. Once those details are known, Curvy generates a one-time deposit address for the transaction.

The user deposits funds, and everything else happens in the background.

Routing. Shielding. Swapping. Delivery.

The objective isn’t to remove complexity from the system. The objective is to remove complexity from the user experience.

Users shouldn’t need to understand privacy sets, aggregation mechanisms, bridge routes, or zero-knowledge proofs. They should simply be able to define an outcome and let the infrastructure handle the work required to get there.

That’s the experience we wanted to build.

What Actually Happens During a Curvy Swap?

The flow is intentionally simple.

A user selects the asset they’re sending, the asset they want to receive, and the destination address where the funds should ultimately arrive. Based on those inputs, Curvy generates a one-time deposit address.

Step 1: Deposit

Once funds are deposited, the transaction moves through several stages behind the scenes.

First comes the deposit. Funds enter Curvy’s privacy infrastructure and are committed into the shared privacy set.

Step 2: Shielding

Next comes shielding. At this stage, the relationship between the deposit and the eventual destination is separated from the public execution path.

Step 3: Validation

A zero-knowledge proof is then used to validate the transaction without revealing a direct source-to-destination link.

Step 4: Routing and Swapping

Once the transaction has been validated, Curvy performs the required routing and swap operations. Depending on the assets and chains involved, this may involve bridging, asset conversion, or multiple execution steps happening behind the scenes.

Step 5: Delivery

Finally, the assets are delivered to the destination address specified at the beginning of the process.

The User Experience

From the user’s perspective, the flow looks like this:

1. Select the asset you’re sending.
2. Select the asset you want to receive.
3. Enter the destination address.
4. Deposit funds to the generated address.
5. Receive the swapped assets.

The complexity still exists. It simply lives inside the infrastructure rather than inside the user experience.

Privacy Should Be Part of the Infrastructure

Over the years, privacy has often been treated as a separate category of product. Something users need to consciously seek out, configure, and manage themselves. In practice, that approach rarely scales beyond a relatively small group of highly motivated users.

We think privacy works better when it becomes part of the infrastructure itself.

Not a special mode. Not a separate application. Not an advanced setting hidden behind additional complexity.

Just a property of how transactions are executed.

What Comes Next?

Curvy Swap is one example of what that looks like in practice. The more interesting question is what comes next.

Beyond Swaps

Swaps are only one type of transaction. The same execution challenges increasingly appear in payments, treasury operations, business workflows, and eventually agent-driven financial systems.

Privacy as Infrastructure

As more economic activity becomes automated, privacy can no longer be treated as an optional feature sitting on top of the stack.

It becomes part of the stack itself.

Curvy Swap Is Live

Curvy Swap is now live: https://swap.curvy.box

Introduction

Agentic payments on Base are becoming a practical pattern for apps that need delegated wallets, social recovery flows, and automated payouts. This post explains what agentic payments mean on Base, how settlement typically works, and practical steps you can take to keep payment data private while minimizing gas and complexity.

What are agentic payments on Base?

In simple terms, agentic payments happen when an ‘agent’—a delegated or programmatic wallet—initiates or facilitates a payment on behalf of an end user. On Base, many projects employ agent wallets for operations like batched payouts, subscription billing, or assisted transactions for users who don’t manage private keys directly.

Agent wallets often operate with signatures from a controller account or via account abstraction patterns. The goal is to make flows seamless while preserving user control and compliance where needed.

How settlement works on Base

Settlement is the process by which the economic obligations created by agent transactions are reconciled on-chain. On Base, settlement typically involves these building blocks:

Relayers and meta-transactions

Agents can use relayer services to submit transactions on behalf of users. A meta-transaction contains intent and signature data; a relayer pays gas and posts the transaction. This model reduces friction for end users and centralizes gas payment to trusted services.

Batching and gas optimization

Batching multiple agent payments into a single transaction reduces per-payment gas costs. Smart contract wallets and payment aggregator contracts can collect instructions off-chain, then execute a single batch on-chain. On Base, batching is inexpensive compared with many Layer 1 chains, but optimization still matters for high-volume activity.

Privacy-preserving patterns

Keep payment metadata off-chain where possible. Use encrypted payloads, hashed identifiers, or ephemeral references stored in private storage to avoid exposing recipient identities or amounts in public transaction calldata. Where on-chain proof is required, consider revealing only the minimum required data and keeping supporting metadata in private databases.

Practical steps to settle agent payments on Base

Follow these steps to implement a robust, private settlement flow:

• Design agent authority carefully: Limit what agent keys can do. Prefer scoped, time-limited delegation to full custody.
• Use relayers or paymasters: Offload gas handling to a relayer, or implement a paymaster-like service that abstracts gas payment while recording minimal on-chain data.
• Batch settlements: Aggregate many payouts into one transaction where feasible to save gas and reduce on-chain footprint.
• Keep metadata off-chain: Store recipient details, amounts, and reasons in encrypted storage and reference them with a short on-chain hash or identifier.
• Audit trails: Maintain signed receipts and cryptographic proofs so you can verify settlements without publishing full details publicly.
• Test with small volumes first: Validate the flow on Base testnets and simulate failure modes before moving to mainnet.

Security and privacy best practices

Security and privacy are complementary goals for agentic payments on Base. Implement multi-layer protections:

• Use hardware-backed keys or secure enclaves for agent key storage.
• Rotate agent keys and use role-based access control for backend services.
• Encrypt all off-chain payment records and restrict database access via least-privilege principles.
• Log only what’s necessary on-chain; avoid embedding personally identifiable information in calldata.

Integration example and tools

Many teams combine a relayer, a smart contract wallet, and a private ledger to manage agentic payments. For teams that prefer a ready interface for settlement flows, consider a tool that simplifies batch settlement and relayer coordination; one practical option is the Crops settlement tool, which can reduce integration time while supporting private off-chain records.

Conclusion

Agentic payments on Base provide a flexible way to deliver delegated, automated, or assisted payments while keeping user experience simple. Focus on careful authority design, batching, and keeping sensitive data off-chain to preserve privacy. Start with a tested relayer and small batches, then iterate to scale. If you want to explore a practical settlement interface, try the Crops settlement tool to speed up development and keep data private.

Introduction

Agentic payments on Solana describe a pattern where autonomous agents, services, or smart contracts settle value quickly and cheaply on behalf of users or applications. This model prioritizes speed, low fees, and composability — traits that align closely with Solana’s high-throughput design. In this article we explain how agentic payments work on Solana, the trade-offs to watch for, and where Curvy Protocol can introduce meaningful privacy protections for these flows.

What are agentic payments?

Agentic payments occur when an intermediary (an agent) executes payments, transfers, or batched settlements for other parties. Agents can be relayers, custodial services, automated market makers, or programmable bots that handle frequent micro-payments, payroll disbursements, or cross-service reconciliations. The agent model reduces friction for end users by abstracting on-chain complexity while enabling richer off-chain workflows.

Why Agentic Payments on Solana Matter

Solana provides several characteristics that make it attractive for agent architectures:

• Low latency: Near-instant block production reduces settlement time for agent actions.
• Low fees: Minimal transaction cost supports high-frequency, low-value transfers without prohibitive overhead.
• High throughput: Agents can process many concurrent settlements thanks to Solana’s parallelized runtime.
• Composability: On-chain programs and SPL tokens allow agents to interact with diverse protocols in a unified environment.

Common use cases

• Micro-payments and streaming wages where frequent small settlements are required.
• Batch reconciliation for marketplaces and multi-merchant platforms.
• Liquidity routing and automated treasury management across protocols.

Privacy challenges with agentic payments

While Solana’s performance is a major advantage, the public ledger exposes transactional metadata that can reveal relationships between agents and users. Common privacy risks include transaction linkability, address clustering, and transparent settlement amounts. For businesses and users who require confidentiality — for competitive, regulatory, or personal reasons — these risks can be material.

Where Curvy Protocol adds privacy

Curvy Protocol can be layered on top of agentic payment flows to reduce on-chain traceability and protect user privacy. Rather than changing the underlying settlement guarantees of Solana, Curvy focuses on obscuring which participants are transacting and how payments are routed. This can be especially valuable for agents that handle many client accounts or sensitive flows.

To explore Curvy’s privacy layer for agent settlements, visit Curvy’s privacy layer.

How a privacy layer helps

• Linkability reduction: Aggregating or reordering agent transactions makes it harder to trace payment origins.
• Metadata minimization: Limiting on-chain exposure of account relationships reduces clustering risks.
• Operational confidentiality: Agents can reconcile off-chain while submitting privacy-enhanced commitments on-chain.

Practical considerations for developers

Implementing agentic payments with privacy on Solana involves a few engineering choices:

1. Payment batching: Aggregate multiple micro-transfers into fewer on-chain operations to save fees and obscure single-user activity.
2. Timelocks and randomization: Introduce controlled timing and ordering variance to reduce pattern detection.
3. Off-chain reconciliation: Use secure off-chain channels for detailed accounting and commit only the necessary aggregated proofs on-chain.
4. Auditing and compliance: Ensure privacy measures are balanced with regulatory requirements; provide selective disclosure capabilities for authorized audits.

Real-world scenarios

Consider a payroll agent that issues daily micro-payments to contractors. On plain Solana, every contractor’s address and amounts are visible. By combining batching, privacy commitments, and a protocol layer like Curvy, the payroll agent can settle on-chain while keeping individual payment patterns private, yet still prove correct totals to auditors when required.

Conclusion

Agentic payments on Solana unlock efficient, low-cost settlement models that work well for high-frequency and programmatic flows. However, public ledgers expose metadata that can undermine confidentiality. Adding a privacy layer such as Curvy Protocol helps agents reduce linkability and protect sensitive payment relationships without sacrificing Solana’s speed and cost advantages. If you manage agent-based settlements, evaluate privacy options early so you can balance operational transparency, compliance, and user confidentiality.

Call to action: Learn more about integrating privacy into your Solana agent flows and evaluate whether a privacy layer fits your operational needs.

Introduction

Agentic payments on Arbitrum are an emerging way to combine privacy, scalability, and interoperability for on-chain transactions. Curvy Protocol’s privacy aggregator leverages Arbitrum to enable private settlements while allowing users and services to move funds across chains. This article explains how agentic payments work on Arbitrum, how agents settle payments, and practical steps to bridge funds from other networks.

What are agentic payments on Arbitrum?

Agentic payments are a model where specialized off-chain or semi-off-chain agents coordinate and execute private transfers on behalf of users. On Arbitrum, these agents interact with smart contracts and privacy layers provided by Curvy Protocol to obscure sender-receiver links while still settling final balances on-chain. The result is faster, cheaper, and more private transactions compared with on-chain-only mixing or single-chain privacy solutions.

Key benefits

• Privacy: Agents aggregate and shuffle transactions, breaking direct links between sender and recipient.
• Scalability: Leveraging Arbitrum’s rollup architecture reduces gas costs and improves throughput.
• Interoperability: Agents can coordinate cross-chain movement and settlement mechanisms.

How agents settle payments on Arbitrum

Settlement on Arbitrum follows a clear pattern designed for privacy and accountability. Agents act as orchestrators: they collect encrypted instructions from users, batch these into aggregated commitments, and submit succinct settlement proofs or commitments to the Arbitrum smart contracts. The contracts then update on-chain balances and allow recipients to withdraw funds privately.

Settlement workflow

1. User deposit: A user deposits funds into Curvy Protocol’s privacy aggregator contract on Arbitrum.
2. Instruction submission: The user sends an encrypted transfer instruction to an agent off-chain.
3. Aggregation: The agent batches many instructions, mixing outputs to disrupt traceability.
4. Commitment: The agent submits a settlement commitment or proof to the Arbitrum contract.
5. On-chain update: The contract updates internal state or merkle roots reflecting the new anonymous balances.
6. Withdrawal: Recipients withdraw funds using private proofs handled by the aggregator.

This sequence keeps sensitive linking data off-chain while retaining a verifiable on-chain settlement record on Arbitrum, combining privacy with the security of rollups.

Bridging funds from other chains

Many users will start on other chains and need to bring funds into Arbitrum for private settlements. Bridging requires care to preserve privacy and reduce fees. To move funds from another chain into Arbitrum for private settlement, use the Crops cross-chain bridge as a secure and efficient option. After bridging, deposit into Curvy Protocol’s aggregator on Arbitrum to enable agentic privacy handling.

Bridge considerations

• Timing: Bridges introduce delay; plan deposits with time buffers for batch settlements.
• Fees: Choose bridges with favourable fees on both source and destination chains to minimize cost.
• Privacy leakage: Avoid patterns that link bridging transactions to subsequent withdrawals; use the aggregator promptly after bridging.

Security and best practices

Agentic payment systems rest on both cryptographic proofs and smart contract security. Follow these best practices:

• Use audited aggregator contracts and review agent reputation and uptime.
• Split large deposits into multiple batches to avoid single-point tracking.
• Prefer time windows where many users transact to maximize anonymity set.
• Keep private keys secure and use hardware wallets where possible.

What users should expect

Users can expect faster finalization and lower gas costs thanks to Arbitrum, combined with stronger unlinkability thanks to agent aggregation. While privacy is improved, absolute anonymity is difficult; consider threat models and use additional privacy hygiene when necessary.

Conclusion

Agentic payments on Arbitrum provide a practical path to private, scalable, and interoperable on-chain transactions. By combining off-chain agent aggregation with Arbitrum’s rollup security, Curvy Protocol enables private settlements that are efficient and verifiable. If you plan to move funds from another chain, remember to bridge carefully and deposit into the aggregator to benefit from agentic privacy and lower costs. Explore the recommended cross-chain bridge to get started and evaluate the aggregator documentation for the best practices.

Call to action: Bridge your funds and try private settlements to experience agentic payments on Arbitrum for yourself.

In decentralized services, agents and relayers often operate across multiple blockchains. Multichain agent payments remove the friction of being tied to a single network by enabling payouts in the chains agents actually use. This post explains how multichain agent payments work, the practical benefits for operators and agents, and how Curvy Protocol approaches cross-network payouts.

Why multichain agent payments matter

Agents, validators, and relayers are frequently spread across different chains for performance, cost, or user reach. Forcing every agent to accept payments only on one network creates unnecessary onboarding friction, higher conversion costs, and delays. Multichain agent payments prioritize flexibility, reduce conversion steps, and improve operational resilience.

How multichain agent payments work

The core idea is simple: the system that owes funds to an agent detects the agent’s preferred network and issues the payout on that network or in a token that the agent can readily use. Implementations vary, but the main components include:

• Agent identity and preferred payout method — agents register wallet addresses or payment rails for each supported chain.
• Cross-chain liquidity — bridges, wrapped assets, or liquidity pools enable value movement between networks.
• Routing and fee management — payment engines choose the cheapest, fastest route while honoring agent preferences and covering bridge or swap fees.
• On-chain settlement — final settlement occurs on the target chain so the agent receives native or usable assets without extra steps.

Technical approaches

There are a few common approaches to enable multichain payouts:

• Bridge-native payouts — the system mints or releases wrapped tokens on the agent’s chain via a bridge and settles once confirmation completes.
• Atomic swaps and DEX routing — automated exchange and routing convert one token to another on the target chain immediately before or during payout.
• Multi-custodial liquidity pools — a network of custodians or liquidity providers holds assets across chains, enabling instant local payouts while reconciling net positions off-chain.

Practical benefits for operators and agents

• Lower friction — agents don’t need to maintain complex on-ramps or perform costly token conversions.
• Faster onboarding — support for preferred chains speeds agent recruitment and reduces support requests.
• Cost optimization — payout routing can minimize aggregate fees by choosing the most economical path at the time of settlement.
• Resilience — if one chain is congested or broken, payments can be routed to alternatives without pausing operations.

How Curvy Protocol spans networks

Curvy Protocol is designed to work across the networks agents actively use. By integrating cross-chain liquidity mechanisms and configurable routing rules, Curvy reduces the operational overhead of paying agents and ensures payouts land where they are most useful. For teams exploring practical agent payout systems, check agent payout platform for an example of an integrated approach that simplifies cross-network settlements.

Security and compliance considerations

Any multichain payment solution must account for security risks around bridges, custody, and swaps. Best practices include multi-signature custody for pooled liquidity, on-chain finality checks before releasing funds, and transparent reconciliation processes. Compliance depends on jurisdictions; operators should design flows that support KYC/AML where required without compromising decentralization goals.

Implementing multichain agent payments: practical steps

1. Survey the chains your agents use and prioritize support based on volume and cost.
2. Choose a liquidity strategy: bridges, pools, or atomic swap integrations.
3. Implement configurable payout preferences so agents can add or update preferred addresses per chain.
4. Automate routing and fee calculation to present net payout amounts and expected settlement times.
5. Monitor and audit settlements, keeping robust logs for dispute resolution and accounting.

Conclusion

Multichain agent payments are no longer optional for projects that rely on a distributed set of operators. They eliminate friction, lower costs, and improve reliability by meeting agents where they already work. If you operate a network of agents or relay providers, consider multichain payout strategies now to stay competitive and reduce operational overhead.

Call to action: Explore Curvy Protocol’s cross-network capabilities and evaluate options that will let your agents receive payments on the chains they prefer.