> 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/pt-br/conceitos-principais/choose-your-core.md). # Escolha seu núcleo Um aplicativo de duas vias pode manter sua lógica principal no lado Solidity ou no lado nativo da Solana. É uma decisão de julgamento — avalie o que importa para o seu app. A maioria dos apps Rome é de duas vias: um único estado compartilhado, acessado tanto por usuários da MetaMask (EVM) quanto da Phantom (Solana). Você pode criar um em duas formas espelhadas, que diferem em **qual lado contém a lógica principal.** Não existe uma regra rígida sobre qual escolher — é uma avaliação subjetiva com base no que importa para *seu* app: o código e os ativos que você já tem, a expertise da sua equipe, sua postura de segurança, as ferramentas de sua preferência, o desempenho e como cada público vai usá-lo. ## (a) núcleo em Solidity; usuários Solana por meio de um remetente sintético Sua lógica é um contrato em Solidity. A assinatura Solana de um usuário da Phantom é executada como uma transação EVM a partir da identidade derivada do Rome desse usuário (o `external_auth` PDA) — eles nunca precisam de uma chave EVM. Costuma ser uma boa opção quando você já tem um contrato em Solidity (especialmente um endurecido ou auditado), quer as ferramentas padrão do EVM (Hardhat / Foundry / viem) ou quando a lógica é simples. *Leia:* [aerarium](https://github.com/rome-protocol/aerarium) — um mercado de empréstimos Compound v3 (núcleo em Solidity) compartilhado por usuários EVM e Solana. ## (b) núcleo de programa nativo da Solana; usuários EVM por meio de um roteador CPI fino Sua lógica é um programa nativo da Solana; um roteador Solidity fino permite que usuários EVM o acessem via CPI. Costuma ser uma boa opção quando você já tem um programa na Solana ou quando executar o núcleo nativamente é importante para o que você está construindo. *Leia:* [rome-dex](https://github.com/rome-protocol/rome-dex) — um AMM nativo (núcleo Solana) com um roteador EVM, para que ambas as vias negociem em um único pool. ## Por exemplo: desempenho Desempenho é uma coisa que *pode* influenciar a escolha — considere isso como um exemplo. A execução nativa na Solana pode ser consideravelmente mais barata do que o interpretador EVM para lógica pesada: um swap que medimos rodou aproximadamente 6× mais barato nativamente. Se o seu app tem um caminho quente, com uso intenso de computação, esse tipo de diferença pode importar para você; se não tiver, provavelmente isso não vai determinar a decisão. Trate isso como apenas um entre vários fatores, não como uma regra. ## Independentemente da escolha Mantenha o núcleo **agnóstico em relação à autoridade** — aja com base em qualquer autoridade que assine, para que o chamador possa ser uma pubkey da Solana *ou* um PDA de um usuário EVM — mantenha o conjunto de contas enxuto e amigável a ALT para que a via EVM continue barata, e **teste as duas vias.** ## O que vem a seguir * [Chamar Solana a partir da EVM](/pt-br/guias-do-desenvolvedor/call-solana-from-evm.md) — os mecanismos de CPI para a forma (b) e qualquer chamada de Solidity para Solana. * [Orçamento de computação](/pt-br/conceitos-principais/compute-budget.md) — mais sobre custo de execução. --- # 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/pt-br/conceitos-principais/choose-your-core.md?ask=&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.