> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/es/conceptos-basicos/choose-your-core.md).

# Elige tu núcleo

Una aplicación de doble carril puede mantener su lógica principal del lado de Solidity o del lado nativo de Solana. Es una decisión de criterio: sopesa lo que importa para tu aplicación.

La mayoría de las apps de Rome son de doble carril: un estado compartido, accesible tanto para usuarios de MetaMask (EVM) como de Phantom (Solana). Puedes construir una con dos formas especulares, que difieren en **qué lado alberga la lógica central.** No hay una regla rígida sobre cuál elegir: es una decisión flexible basada en lo que importa para *tu* app: el código y los recursos que ya tienes, la experiencia de tu equipo, tu postura de seguridad, las herramientas que prefieres, el rendimiento y cómo usará cada audiencia la aplicación.

## (a) Núcleo en Solidity; usuarios de Solana mediante un emisor sintético

Tu lógica es un contrato de Solidity. La firma de Solana de un usuario de Phantom se ejecuta como una transacción EVM desde su identidad derivada de Rome (la `external_auth` PDA); nunca necesitan una clave EVM. Suele encajar bien cuando ya tienes un contrato de Solidity (especialmente uno endurecido o auditado), quieres herramientas EVM estándar (Hardhat / Foundry / viem), o la lógica es sencilla.

*Lee:* [aerarium](https://github.com/rome-protocol/aerarium) — un mercado de préstamos de Compound v3 (núcleo en Solidity) que comparten los usuarios de EVM y de Solana.

## (b) Núcleo de programa nativo de Solana; usuarios de EVM mediante un enrutador CPI ligero

Tu lógica es un programa nativo de Solana; un enrutador ligero en Solidity permite a los usuarios de EVM acceder a él vía CPI. Suele encajar bien cuando ya tienes un programa de Solana, o cuando ejecutar el núcleo de forma nativa importa para lo que estás construyendo.

*Lee:* [rome-dex](https://github.com/rome-protocol/rome-dex) — un AMM nativo (núcleo de Solana) con un enrutador EVM, de modo que ambos carriles operan en un mismo pool.

## Por ejemplo: rendimiento

El rendimiento es una de las cosas que *podría* inclinar la decisión; considéralo solo como un ejemplo. La ejecución nativa en Solana puede ser considerablemente más barata que el intérprete de EVM para lógica pesada: un swap que medimos salió aproximadamente 6× más barato de forma nativa. Si tu app tiene una ruta crítica y exigente en cómputo, una diferencia así podría importarte; si no la tiene, probablemente no determine la decisión. Tómalo como una señal entre muchas, no como una regla.

## Elijas la que elijas

Mantén el núcleo **agnóstico respecto a la autoridad** — actúa sobre la autoridad que firme, para que el llamador pueda ser una clave pública de Solana *o* un PDA de un usuario de EVM — mantén el conjunto de cuentas ligero y compatible con ALT para que el carril EVM siga siendo barato, y **prueba ambos carriles.**

## Qué sigue

* [Llamar a Solana desde EVM](/es/guias-para-desarrolladores/call-solana-from-evm.md) — la mecánica de CPI para la forma (b) y cualquier llamada de Solidity→Solana.
* [Presupuesto de cómputo](/es/conceptos-basicos/compute-budget.md) — más sobre el coste de ejecución.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/es/conceptos-basicos/choose-your-core.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.