Anatomía de una cartera

Máster fuente EN · P09-L01 · 45 minutos estimados · needs_review

Una página de cartera puede combinar una dirección, varias cuentas de tokens, llamadas a contratos y etiquetas de proveedor en una pantalla. Esa comodidad no los convierte en un único objeto del registro ni en una persona. Antes de leer el historial, definir qué representa realmente la página.

Mapearás los roles de cuenta y conciliarás las tenencias suministradas sin atribuir identidad. Es la competencia inicial del programa: toda afirmación posterior de financiación, antigüedad y relaciones depende de elegir la unidad de observación correcta.

Separar la interfaz del objeto

Una aplicación de cartera es una interfaz, mientras una cuenta es un objeto del registro; la documentación Ethereum explicita esta distinción [S09-ETHACCOUNTS]. Una interfaz puede mostrar múltiples cuentas y redes. Una cuenta puede ser accesible desde múltiples interfaces. Ninguna relación identifica a un ser humano único.

Usar red más dirección completa como identificador inicial. Una etiqueta abreviada no establece igualdad. El mismo texto mostrado en cadenas distintas no es un objeto contable compartido. La agrupación «cartera» de un proveedor puede incluir relaciones inferidas; inspeccionar su definición antes de tratarla como total de propietario.

En trabajo real, validar la codificación de dirección y registrar la red seleccionada. El ejercicio usa deliberadamente etiquetas inválidas, por lo que las comparaciones son solo educativas y ninguna transacción puede dirigirse a estos identificadores.

Identificar el rol de la cuenta

Las cuentas Solana almacenan estado en direcciones y tienen un campo de programa propietario [S09-ACCOUNTS]. Ese campo no es una identidad humana. Una cuenta de tokens registra por separado su mint y autoridad propietaria [S09-TOKENS]. No interpretar la propiedad base del Token Program como si el programa fuera beneficiario de cada saldo de tokens.

Una autoridad puede poseer múltiples cuentas de tokens de un mint. Agregar únicamente con mint exacto, contexto coincidente y campos de autoridad respaldados. Un saldo nativo y uno de tokens tienen unidades distintas. Nunca sumarlos como un activo único ni convertirlos a dólares sin fuente explícita de valoración.

Registrar si una dirección nombra un programa, una cuenta de tokens, un mint u otra cuenta de estado. El mismo grafo de relaciones puede contener todos estos tipos de nodo. Un grafo de cinco nodos no muestra cinco carteras, mucho menos cinco personas.

Entender la actividad controlada por programa

Las direcciones Solana derivadas de programa (PDA) se derivan de un ID de programa y semillas y no tienen clave privada; el programa que las deriva puede firmar por ellas mediante el mecanismo de ejecución [S09-PDA]. La derivación por sí sola no afirma que ya exista una cuenta asignada en esa dirección. Verificar tanto la relación de dirección como el estado relevante de cuenta.

No reducir firma de programa y firma humana a un campo único. Una autoridad mediada por programa puede servir a muchos usuarios. Las reglas de su aplicación determinan qué solicitudes la hacen actuar; una etiqueta PDA no establece un usuario individual ni control sin restricciones.

En redes EVM distinguir control ordinario por clave, lógica contractual y mecanismos de delegación compatibles. Una cuenta externa (EOA) está controlada por una clave privada; la delegación compatible puede determinar el código que ejecuta. EIP-7702 permite delegación de código de EOA en redes compatibles [S09-DELEGATION]. Por tanto, la presencia de código por sí sola no es una regla universal «esto no puede ser una EOA». Inspeccionar reglas de red y estado de cuenta en el contexto solicitado.

Una cuenta con código puede ejecutar instrucciones sin probar qué humano se beneficia. Un contrato multifirma puede representar varias cuentas firmantes, pero contar firmantes no prueba personas independientes. Separar mecanismo de control y atribución humana.

Construir un mapa de roles antes de uno de propiedad

Usar tipo de nodo, identificador exacto, red, contexto y localizador de evidencia. Usar aristas como propietario de cuenta de tokens, referencia de mint, derivación de programa y delegación de código. Tienen significados específicos. Una arista genérica «relacionado con» oculta por qué se enlazan los nodos.

No convertir cada arista en propiedad común. La referencia de mint conecta a todos los tenedores de un activo sin convertirlos en un controlador. La derivación de programa conecta una dirección con un mecanismo, no necesariamente con el inventario personal del operador del programa.

Las etiquetas de proveedor pertenecen a una anotación separada con procedencia y estado de verificación. «Servicio de custodia» puede ser una pista útil, pero hay que inspeccionar publicador, fecha de actualización y fundamento. Registrarla como afirmación del proveedor hasta una corroboración suficiente.

Conciliar las tenencias suministradas

El conjunto ofrece cuentas de tokens exhaustivas para la autoridad W y un mint objetivo en S0. Esa integridad es una hipótesis del ejercicio, no una capacidad afirmada de Wallet Intelligence. Sumar los dos saldos válidos solo tras confirmar propietario y mint.

Una tercera cuenta del mismo mint bajo una autoridad derivada de programa no es una tenencia de W solo porque aparece en la misma pantalla. Una tenencia de otro mint no entra en el total objetivo. Las unidades nativas permanecen separadas.

Si los registros reales son parciales, informar un total de saldos devueltos y su límite de cobertura. No promoverlo silenciosamente a «todas las tenencias». Una consulta fallida es evidencia no disponible, no inventario cero. Un importe cero suministrado es una medición bajo su alcance declarado.

Expresar los límites de forma constructiva

Un buen hallazgo anatómico puede decir «W es la autoridad suministrada para T1/T2 que contienen MINT-A; P1 es una autoridad separada mediada por programa. El control humano es desconocido». Responde la pregunta de cuenta sin resolver una pregunta de identidad sin respaldo.

La siguiente solicitud de evidencia debe corresponder a la laguna: enumeración completa propietario/mint para tenencias faltantes, registros de derivación/estado para clasificar una PDA y autorización de aplicación para control mediado. Pedir el nombre de una persona no sustituye estas verificaciones técnicas.

Ningún rol de cuenta produce una señal BUY/SELL. Tener un contrato, PDA o cuenta de tokens indica cómo se organizan las observaciones. No establece legitimidad, intención ni comportamiento futuro de mercado.

• Dirección: identificador delimitado por red.
• Cuenta: objeto de estado en una dirección.
• Interfaz de cartera: aplicación que muestra cuentas o interactúa con ellas.
• Autoridad propietaria: campo que gobierna una cuenta de tokens especificada.
• PDA: dirección derivada de programa con firma en ejecución.
• Delegación: relación de ejecución de cuenta, no afiliación personal.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A en S0 ficticio; saldos ya normalizados. Autoridad objetivo W, mint objetivo MINT-A. T1/T2 se estipulan exhaustivos para W/MINT-A.

A 7 es un ejemplo de una red separada. No se suministran registros de identidad, valoración, umbral de firmas ni autorización de aplicación.

OBSERVED en el conjunto: W es autoridad propietaria de T1/T2; P1 es una autoridad distinta derivada de programa para T4. El proveedor publica A 8.

INFERRED: las tenencias MINT-A suministradas de W suman 200 tokens. Sus 2 nativos y MINT-B50 son cantidades separadas.

UNKNOWN: identidad humana detrás de W/P1/E1, reglas de control de aplicación y propiedad beneficiaria.

INSUFFICIENT EVIDENCE: A 8 no establece la identidad de Alice. El mint compartido no fusiona W y P1. La delegación de código no establece afiliación con el publicador de LOGIC-D.

Tratar una interfaz de cartera como persona; confundir programa propietario base con autoridad propietaria de tokens; sumar unidades distintas; fusionar tenedores del mismo mint; aplicar una clasificación obsoleta código/sin código sin contexto de red.

Dibujar un mapa tipado de roles de A 1–A 7. Calcular las tenencias objetivo de W. Clasificar A 8 y explicar por qué T4 queda fuera del total de W. Identificar dos verificaciones faltantes de actividad controlada por programa.

• Seleccionar red exacta y unidad de observación.
• Tipar cada nodo y relación.
• Mantener separados saldos nativos y de mint.
• Agregar solo campos de propietario respaldados.
• Distinguir control por programa/clave/delegación.
• Conservar etiquetas como afirmaciones hasta corroborarlas.

La anatomía de cartera es un mapa de objetos del registro y mecanismos de control. Establece qué inspeccionar sin equiparar direcciones con personas.

Una interfaz no es una cuenta ni una persona. Las relaciones tipadas evitan agregaciones falsas. Las etiquetas de proveedor y el comportamiento del código no prueban identidad.

Dibujar nodos tipados W,T1,T2,T3,P1,T4 y mint con aristas etiquetadas de autoridad/mint/derivación. Destacar solo objetivo200. Aislar unidades nativas y MINT-B y separar delegación EVM. Poner A 8 en anotación de etiqueta no verificada.

Anatomía ilustrativa de cuenta; los nodos del grafo no son personas.

Usar SVG/HTML determinista o gráficos con unidades, localizadores de evidencia y alternativas textuales. Azul marino/negro con cian, azul eléctrico y violeta discretos; sin capturas decorativas o fabricadas de exploradores. A 390px apilar anotaciones; verificar 768px, escritorio y RTL árabe cuando se implementen los recursos. Mantener identificadores LTR y las direcciones fácticas de tiempo/aristas/ejes sin cambios. Usar únicamente la marca oficial BlockAssay suministrada. Ambos registros visuales siguen siendo especificaciones.

WALLET_INTELLIGENCE corresponde a la inspección de solo lectura de registros de direcciones públicas, relaciones y procedencia. Verificar red compatible, identificadores exactos, campos y cobertura antes de cualquier integración en ejecución; aquí no se afirma ninguna capacidad de proveedor en vivo. Usar el ejercicio sin conexión incluido si faltan datos o acceso de pago. No se requiere conexión de cartera, credenciales, clave privada, firma ni operación real de mercado. Los datos ausentes siguen desconocidos. El progreso Academy, estatus de creador, pagos y referidos nunca alteran la evidencia Radar.

• Cuentas Solana — Estado direccionado y campo de programa propietario. Comprobado el 2026-09-30.
• Activos Solana — Distinciones entre mint, cuenta de tokens y autoridad propietaria. Comprobado el 2026-09-30.
• Direcciones Solana derivadas de programa — Direcciones derivadas de programa y firma del programa; sin clave privada de PDA. Comprobado el 2026-09-30.
• Cuentas Ethereum — Distinción cuenta/interfaz y tipos de cuenta. Comprobado el 2026-09-30.
• EIP-7702: establecer código para EOA — Delegación de código de EOA; la presencia de código por sí sola no es una regla universal de clasificación de EOA. Comprobado el 2026-09-30.

Todos los registros de ejemplo son conjuntos originales ILLUSTRATIVE, no mediciones históricas/en vivo de la cadena. La documentación explica mecanismos, no importes ni etiquetas inventados. La cronología sintética está explícitamente delimitada; observedAt=null es intencional. OBSERVED en un ejercicio significa un registro suministrado del conjunto. Revisar nuevamente la documentación y la decodificación desplegada antes de publicar. Las etiquetas de proveedor no establecen identidad; el control de direcciones y la atribución humana requieren evidencias distintas.

P09-L02 después del ejercicio resuelto y la revisión de preguntas.