> For the complete documentation index, see [llms.txt](https://minara.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://minara.ai/docs/minara-handbook/es/tecnologia/dmind/sovereign-architecture.md).

# Arquitectura soberana

DMind-3 está construido como un sistema de tres capas llamado la pila soberana Edge-Local-Cloud. Cada capa es un modelo distinto, se ejecuta en un lugar distinto y tiene una función distinta. El diseño separa el trabajo crítico para la seguridad del trabajo de estrategia y del trabajo a escala de mercado, de modo que cada parte pueda tener el tamaño adecuado y ejecutarse en el entorno correcto.

## Las tres capas

| Capa  | Modelo              | Dónde se ejecuta             | Función                                                    |
| ----- | ------------------- | ---------------------------- | ---------------------------------------------------------- |
| Borde | DMind-3-Nano (270M) | Navegador, billetera, móvil  | Verificaciones deterministas de seguridad de transacciones |
| Local | DMind-3-Mini (4B)   | Dispositivo del usuario      | Razonamiento privado de estrategia e investigación         |
| Nube  | DMind-3 (21B)       | API en la nube o VPC privada | Análisis entre mercados y entre cadenas                    |

## Borde: cortafuegos determinista de intención

Cuando un usuario está a punto de firmar una transacción, DMind-3-Nano analiza localmente el calldata y lo compara con un conjunto fijo de patrones de alto riesgo: aprobaciones ilimitadas, transferencias a contratos recién desplegados, llamadas delegate sospechosas, interacciones con direcciones de phishing conocidas.

La comprobación se basa en reglas y no en probabilidades. Un pequeño modelo en el dispositivo es muy adecuado para este tipo de reconocimiento de patrones fijos, y el modelo nunca envía los datos de la transacción a ningún lugar. Si la red está caída o el servicio en la nube no está disponible, Nano sigue funcionando.

{% hint style="warning" %}
La razón por la que esta capa importa: una transacción firmada en la cadena no puede deshacerse. No hay contracargo, no hay ticket de soporte, no hay período de reflexión de 24 horas. La seguridad tiene que ocurrir antes de la firma, no después.
{% endhint %}

## Local: motor de razonamiento privado

DMind-3-Mini se ejecuta en el dispositivo de un usuario y se encarga de tareas que tocan información privada: analizar las tenencias de una billetera, redactar una estrategia en torno a posiciones específicas, leer investigación usando la cartera del usuario como contexto.

Mini se entrena para cuestionar sus propias respuestas (véase [Métodos de entrenamiento](/docs/minara-handbook/es/tecnologia/dmind/training-methods.md) para el método C³-SFT). Para cada pregunta, genera una respuesta inicial y luego entra en un paso de reflexión en el que busca errores en su propio razonamiento antes de producir una respuesta final. Esto reduce el modo de fallo en el que un modelo pequeño afirma con seguridad algo incorrecto.

## Nube: oráculo para todo el mercado

DMind-3, el modelo en la nube de 21B, tiene la visión global. Se ejecuta en la nube o en una VPC privada y se encarga del trabajo que necesita contexto a escala de mercado:

* Análisis del flujo de capital entre cadenas en Ethereum, Solana, Cosmos y los principales L2.
* Detección del régimen de mercado, prediciendo transiciones entre estados de volatilidad, entornos de tasas de financiamiento y condiciones de liquidez.
* Modelado del riesgo sistémico, simulando rutas de liquidación en cascada a través de protocolos DeFi.
* Informes de investigación extensos sobre protocolos, tokenomics y posicionamiento competitivo.
* Orquestación de flotas de agentes, donde muchas instancias locales de Mini y Nano se coordinan a través del Oráculo.

El Oráculo tiene una ventana de contexto de 256k tokens. Esto importa porque un solo informe de auditoría DeFi puede llegar a 100.000 tokens antes de añadir cualquier material de comparación.

## Cómo se enrutan las solicitudes

Las solicitudes se enrutan entre las capas en función de dos preguntas: qué tan sensible es esto desde el punto de vista de la privacidad y cuánta confianza tiene el modelo local.

Una solicitud que toca información privada (saldos de la billetera, intención de trading, identidad) se mantiene local. Incluso si Mini tiene incertidumbre, los datos no salen del dispositivo. Una solicitud que no es sensible para la privacidad pero que necesita contexto a escala de mercado va al Oráculo, con los detalles personales eliminados antes de enviarla. Una solicitud que no es sensible para la privacidad y sobre la que Mini tiene confianza se mantiene local de todos modos, porque no hay razón para hacer un viaje de ida y vuelta a la nube.

Esto invierte el modelo habitual centrado primero en la nube. El valor predeterminado es local. La nube es un ayudante restringido para las cosas que realmente necesitan una visión global.

## La puerta de políticas

Cualquier respuesta que devuelva el Oráculo tiene que volver a pasar por la capa Edge antes de poder desencadenar una acción de la billetera. La nube no tiene permiso para firmar nada directamente. Nano ejecuta sus comprobaciones de seguridad sobre cualquier transacción que sugiera la nube, y el usuario firma solo después de que esa puerta se haya superado.

La autoridad de ejecución reside en el borde.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://minara.ai/docs/minara-handbook/es/tecnologia/dmind/sovereign-architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.