Educación independiente. Sin afiliación con Binance ni BNB Chain.
BNB.info English

Práctica / Evidencia onchain

Revisá contratos de BNB Chain y evaluá una dApp sin conectar

Compará red, emisor y contrato; inspeccioná una dApp o memecoin ficticia con evidencia pública sin conectar una billetera ni tratar una etiqueta de verificación como veredicto de seguridad.

Vas a aprender

  • Identificar red y contrato sin confiar en un ticker.
  • Separar coincidencia de código, lógica proxy y evaluación de seguridad.
  • Interpretar To, Transfer y decimales en un recibo ficticio.
  • Registrar concentración por dirección y riesgos pendientes de una dApp sin conectar una billetera.

Antes de empezar

Leé redes, evidencia y permisos de tokens. No necesitás conectar billetera, cuenta ni fondos para el ejercicio.

Identificá el objeto que estás investigando

Empezá con una pregunta acotada: ¿qué contrato y red involucraría esta acción? Registrá aplicación prevista, activo y dirección completa desde la documentación del emisor o proyecto correspondiente. Un ticker conocido, un logo o un resultado destacado del buscador no demuestran identidad. Una inclusión en un exchange tampoco prueba que admita todas las representaciones onchain con nombre parecido.

Es una investigación de sólo lectura, no una auditoría ni una instrucción para usar la aplicación. BSC mainnet tiene chain ID 56. La misma dirección textual en otra red puede tener otro código y estado. Anotá red y dirección juntas. Si la documentación no identifica claramente el objeto, el resultado útil es dejar pendiente esa identidad antes de autorizar cualquier acción.

Evidencia: BSC network data · BEP20 token-contract interface specification

Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

Secuencia de inspección de sólo lectura

  1. Abrí el explorador correcto desde una fuente comprobada por separado.

    Buscá la dirección completa del contrato en vez de elegir un token sólo por su nombre. Compará la dirección del explorador con la documentada que anotaste. No pegues claves privadas, frases o códigos de autenticación en el buscador. La consulta habitual de registros públicos no necesita esos datos.

  2. Separá información de token e información de contrato.

    La página del token puede mostrar símbolo, decimales, movimientos y holders. La vista de contrato puede mostrar código y verificación. Registrá qué objeto describe cada campo. La estimación de valor de mercado es una afirmación diferente de la existencia del contrato o del saldo que devuelve.

  3. Mantené la lectura y anotá qué sigue sin resolverse.

    Este ejercicio no utiliza Connect to Web3, Write Contract ni solicitudes de firma. Serían otras operaciones. Si una vista ofrece una consulta de lectura, identificá primero contrato y función. El resultado aporta información de ese contrato; no garantiza de manera independiente lo que promete un emisor o servicio.

Evidencia: Explorer interpretation · ERC-20 specification

Este artículo de Binance Academy orienta sobre BscScan; no verifica afirmaciones sobre un token, holder, precio, bloqueo de liquidez o contrato real.

La verificación de código tiene un alcance limitado

La verificación relaciona código publicado y código desplegado mediante un proceso de coincidencia concreto. La documentación del explorador distingue tipos con coberturas diferentes. Leé el alcance mostrado en lugar de tratar todas las etiquetas de colores como iguales. Poder leer el código habilita más análisis; no demuestra respaldo económico, identidad del equipo ni ausencia de comportamientos dañinos en todas las rutas de ejecución.

No se espera que un principiante audite código arbitrario por abrir una pestaña. Buscá documentación sobre controles administrativos, actualizaciones, restricciones y revisiones de seguridad. Compará contrato, versión y fecha de esa revisión con el objeto real. La información faltante debe seguir como pregunta. “Código publicado disponible; comportamiento no evaluado” es más preciso que “verificado, por lo tanto seguro”.

Evidencia: Source-code match scope · Contract security · Explorer interpretation

Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

La guía de ethereum.org describe conceptos generales de seguridad de contratos; no evalúa un contrato, token o aplicación particular de BNB Smart Chain.

Este artículo de Binance Academy orienta sobre BscScan; no verifica afirmaciones sobre un token, holder, precio, bloqueo de liquidez o contrato real.

Una dirección estable puede delegar en otra lógica

Un proxy puede reenviar llamadas a una implementación separada. Importa al comparar código, auditoría y dirección que utiliza una app. Registrá proxy e implementación cuando explorador y documentación los identifiquen. Leer solamente el código corto del proxy puede no explicar el comportamiento que ejecuta la llamada delegada. La detección y las etiquetas del explorador también tienen límites propios.

Preguntá quién puede cambiar la implementación o ejercer roles administrativos y dónde se documentan esas reglas. No deduzcas que no existen poderes porque no encontraste una función con nombre familiar. Esta guía no decide si un mecanismo particular de actualización resulta aceptable. Si no identificás lógica o autoridad relevantes, detenete en esa incertidumbre documentada en lugar de firmar para ver qué ocurre.

Evidencia: Proxy and implementation · Contract security

Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

La guía de ethereum.org describe conceptos generales de seguridad de contratos; no evalúa un contrato, token o aplicación particular de BNB Smart Chain.

Leé un recibo de tokens completamente ficticio

Registro ficticio de identidad: la documentación del emisor identifica [CONTRATO_ABC] en BSC, con seis decimales. Otro contrato, [COPIA_ABC], tiene el mismo símbolo y una etiqueta visible de código verificado. Símbolo y etiqueta no convierten esa segunda dirección en el activo documentado. El ejercicio mantiene separados los objetos. Ninguna etiqueta entre corchetes es una dirección real ni se inspeccionó un contrato real para este ejemplo.

Supongamos ahora un recibo hipotético de [CONTRATO_ABC] con Success, To [CONTRATO_ABC], valor nativo de 0 BNB y un evento Transfer de [PAGADOR] a [RECEPTOR] con cantidad cruda de 12.500.000. Con los seis decimales indicados, el importe legible es 12,5 ABC: 12.500.000 dividido por 1.000.000. Cero valor nativo no significa cero movimiento de tokens; el evento describe una transferencia del token de contrato.

La interpretación establece un resultado sólo dentro del modelo ficticio: el contrato elegido informa esa transferencia a ese receptor. No demuestra acreditación de exchange, valor de mercado ni ausencia de otros riesgos. En una investigación real, compará contrato emisor del evento, metadata, estado y destinatario antes de utilizar el importe formateado. El gas es una comisión nativa separada, no la cantidad del token en ese evento.

Ejercicio ficticio de concentración, no es un token ni una observación real de la red: MIMI-FICT muestra un supply total de 100.000 unidades. Tres direcciones visibles tienen 42.000, 18.000 y 12.000. Suman 72.000; 72.000 ÷ 100.000 = 72 %. La frase defendible es “estas tres direcciones visibles representan el 72 % de la captura hipotética del supply”. No demuestra que sean tres personas, un titular coordinado, un pool bloqueado, una venta futura ni seguridad. Las cifras son inventadas deliberadamente para practicar el cálculo.

Evidencia: ERC-20 specification · BEP20 token-contract interface specification · Contract-call input · Transaction model

Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

No conviertas indicadores distintos en un veredicto

Muchos holders no implican necesariamente muchas personas independientes. Un saldo grande no explica las obligaciones de su titular. La estimación de precio del explorador no garantiza un valor canjeable. Una etiqueta de código no reemplaza una revisión de seguridad con alcance definido. Preguntá qué demuestra específicamente cada indicador antes de utilizarlo para concluir algo sobre una aplicación.

La app también puede pedir autorización para un gastador distinto del token o implementación que inspeccionaste primero. Antes de una decisión posterior de permisos, identificá esa contraparte por separado. Leer la página de un token no revisa automáticamente cada router, puente, vault o mecanismo de firma utilizado. La guía de permisos aborda esa siguiente pregunta; esta investigación no autorizó realizarla.

Evidencia: Explorer interpretation · Token approvals

Este artículo de Binance Academy orienta sobre BscScan; no verifica afirmaciones sobre un token, holder, precio, bloqueo de liquidez o contrato real.

MetaMask describe su billetera y conceptos generales de aprobación de tokens; otros proveedores e implementaciones pueden diferir.

Evaluá una dApp o memecoin con evidencia pública

Mantené esto como revisión de sólo lectura. Empezá desde documentación del proyecto o emisor consultada por una vía independiente, registrá red y contrato exactos y comparalos con el explorador. Un nombre conocido, una publicación social, la posición en el buscador o un logo coincidente no demuestran que el dominio o token pertenezcan al proyecto real. Si la cadena de identidad se contradice, detenete y anotá el conflicto; no conectes una billetera para averiguar más.

Para una dApp, anotá los contratos que declara utilizar, relaciones proxy o de actualización visibles, poderes administrativos documentados y alcance, versión y fecha de cualquier revisión que mencione. Para un token, registrá supply total y las direcciones más visibles sólo si el explorador expone esos datos en un momento indicado. Revisá qué identifica concretamente una afirmación de liquidez “bloqueada”: una etiqueta de dirección no prueba que la liquidez esté bloqueada, pueda retirarse o se administre como se anuncia. Una página pública no permite ver cada solicitud futura que podría mostrar la app.

Mantené las conclusiones descriptivas: el código coincide o no; un poder está documentado o sigue sin resolver; una lista visible de holders tiene cierta concentración. Ningún punto de esta lista es auditoría, garantía ni recomendación de compra o venta. Si no podés explicar qué demuestra una evidencia y qué deja abierto, marcala pendiente.

  1. Escribí la tupla de identidad.

    Anotá proyecto/dominio, afirmación del emisor, nombre y chain ID de la red, dirección completa del token o contrato de la app, fuente de esa asociación y fecha de consulta. No uses el ticker como identificador.

  2. Separá evidencia de código y de control.

    Registrá alcance de coincidencia del código, proxy e implementación si están identificados, roles administrativos o de actualización y contrato, versión y fecha exactos de cualquier informe. “No encontrado” significa pendiente, no inexistente.

  3. Describí concentración sin identificar personas.

    Si hay cifras de supply y holders, anotá la captura, sumá los saldos de las direcciones elegidas y dividí por el supply total mostrado. Decí “direcciones” salvo que la evidencia permita establecer otro tipo de titular; etiquetá una dirección como exchange, pool o vesting sólo con respaldo.

  4. Enumerá lo que no pudiste verificar.

    Para liquidez, respaldo, bloqueos, auditorías, identidad del equipo, condiciones de retiro y permisos de la app, anotá fuente y brecha pendiente. No firmes ni conectes sólo para convertir una duda en resultado.

Registro de revisión de sólo lectura; no es un veredicto de seguridad
PreguntaEvidencia pública para registrarQué no demuestra
IdentidadDocumentación del emisor/proyecto, red y dirección completa del contratoQue el emisor sea honesto o que un exchange admita esa representación
Código y controlAlcance de coincidencia, proxy/implementación, administración o actualizaciones, alcance/fecha de revisiónQue un código legible o coincidente sea inocuo o que una revisión cubra la lógica desplegada actual
ConcentraciónSupply y saldos por dirección con fecha; cálculo reproducibleLa cantidad o identidad de personas, distribución futura o resultado de inversión
Liquidez y permisosContrato y condiciones documentadas del pool/bloqueo; token, gastador y detalles de solicitud si están documentados públicamenteQue una etiqueta pruebe un bloqueo exigible, que se puedan retirar activos o qué haría una solicitud de billetera aún no vista

Evidencia: Explorer interpretation · BEP20 token-contract interface specification · Source-code match scope · Proxy and implementation · Contract security · ERC-20 specification · Token approvals

Este artículo de Binance Academy orienta sobre BscScan; no verifica afirmaciones sobre un token, holder, precio, bloqueo de liquidez o contrato real.

Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

La guía de ethereum.org describe conceptos generales de seguridad de contratos; no evalúa un contrato, token o aplicación particular de BNB Smart Chain.

MetaMask describe su billetera y conceptos generales de aprobación de tokens; otros proveedores e implementaciones pueden diferir.

Escribí un resultado que otra persona pueda reproducir

Terminá con red, dirección completa del objeto, fuente primaria de identidad, alcance de verificación, relación proxy/implementación cuando exista, campos de recibo observados o ficticios, fecha y dudas pendientes. Separá lo documentado de lo que realmente observaste. Esta lección utilizó documentación y ejemplos rotulados, no una billetera ni una prueba de transacción real para confirmar esos resultados.

Un resultado defendible sería: “Coinciden red y contrato documentados; el código es legible, pero siguen pendientes autoridad de actualización y cobertura de revisión actual”. Es un registro de lectura terminado con límites, no una recomendación de depositar. Si un sitio exige firmar para revelar evidencia pública o muestra una alerta, detené la interacción e investigá mediante una fuente oficial apropiada.

Evidencia: Security and scam prevention

Comprobá lo aprendido

En un ejemplo ficticio, tres direcciones tienen el 72 % del supply de un token. ¿Eso demuestra que tres personas controlan el 72 % o que el token es inseguro?

Ver explicación

No. Es una cifra de concentración de tres direcciones en la captura indicada. Las direcciones pueden corresponder a contratos, exchanges u otros arreglos; la cifra no prueba por sí sola quiénes son los titulares efectivos ni una conclusión de seguridad o inversión. Registrá red, método y fecha, y separá otros riesgos y dudas.

Fuentes primarias

  1. What is a token approval?MetaMask Help Center · 2026-10-25

    MetaMask describe su billetera y conceptos generales de aprobación de tokens; otros proveedores e implementaciones pueden diferir.

  2. BEP20: Tokens on BNB Smart ChainBNB Chain · 2026-10-26

    Se usa sólo para la interfaz de contratos BEP20 y los métodos/eventos nombrados en la especificación. No demuestra que un contrato desplegado concreto cumpla el estándar, sea auténtico, seguro, emitido por una entidad determinada, respaldado por reservas o equivalente a un activo en otra red. El archivo contiene una referencia histórica a Beacon Chain que no se toma como guía de migración actual.

  3. Types of contract verificationEtherscan Information Center · 2026-10-26

    Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

  4. Smart contract securityethereum.org · 2026-10-26

    La guía de ethereum.org describe conceptos generales de seguridad de contratos; no evalúa un contrato, token o aplicación particular de BNB Smart Chain.

  5. ERC-20: token standardEthereum Improvement Proposals · 2026-10-26
  6. What is BscScan and how to use it?Binance Academy · 2026-10-26

    Este artículo de Binance Academy orienta sobre BscScan; no verifica afirmaciones sobre un token, holder, precio, bloqueo de liquidez o contrato real.

  7. Understanding transaction input dataEtherscan Information Center · 2026-10-25

    Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

  8. Proxy contractsEtherscan Information Center · 2026-10-26

    Esta fuente describe Ethereum/Etherscan. Apoya el concepto EVM indicado, no tarifas o confirmaciones de BSC ni que todos los exploradores tengan etiquetas idénticas.

  9. BNB Smart Chain JSON-RPC endpointsBNB Chain · 2026-10-26
  10. Ethereum security and scam preventionethereum.org · 2026-10-25
  11. Transactions: technical documentationethereum.org · 2026-10-25