1. Resumen
SAAVECORD es una cadena de bloques propia con moneda nativa identificada comercialmente como SVCD. Utiliza prueba de trabajo SHA256d, un modelo de transacciones con salidas no gastadas (UTXO) y carteras locales que controlan las claves de sus usuarios. Cada participante puede ejecutar un nodo y verificar las reglas de la cadena con el cliente publicado.
El proyecto tiene dos objetivos de uso: transferencias entre personas y pagos vinculados a la actividad inmobiliaria del fundador. La versión publicada permite generar direcciones, enviar SVCD y confirmar transferencias mediante minería. La integración con procesos comerciales inmobiliarios forma parte del desarrollo propuesto.
La apertura pública conserva su historial de desarrollo: 102 bloques posteriores al génesis y 5.100 SVCD asignados a carteras controladas por el fundador. El minero oficial también dirige sus recompensas posteriores a una cartera del fundador. La disponibilidad inicial, la minería observada y la web dependen de un solo VPS y operador; no existe una auditoría externa del proyecto.
La web oficial es https://saavecord.com/ y el explorador público es https://saavecord.com/explorador/. La distribución disponible es para Linux x86_64, preparada en Ubuntu 24.04. El código fuente modificado se distribuye dentro del paquete descargable y, desde el 25 de octubre de 2026, como snapshot v0.2 en https://github.com/1993marx/saavecord-core. El commit publicado es a252d4827f743cf7ae930723962ebd21f89945f7. El repositorio no incorpora el historial Git privado anterior. La publicación y la comprobación de integridad no constituyen una auditoría externa ni una firma de las versiones.
2. Utilidad y alcance
Transferencias entre personas
Un usuario puede crear una cartera dedicada, obtener una dirección de recepción y recibir SVCD de otro participante. El emisor firma una transacción; los nodos verifican su validez y los mineros pueden incluirla en un bloque. La aceptación comercial de un pago depende de las partes, del número de confirmaciones que acuerden y de las condiciones de la red.
El protocolo permite transferencias sin que la web custodie las claves. La disponibilidad del sitio no determina por sí sola la existencia de los fondos: las transacciones confirmadas pertenecen al historial que los nodos verifican.
Pagos vinculados a la actividad inmobiliaria
El segundo objetivo es ofrecer SVCD como posible medio de pago para servicios u operaciones comerciales vinculadas a la actividad inmobiliaria del fundador, cuando las partes lo acuerden. Esta intención no constituye evidencia de comercios que ya acepten SVCD ni de operaciones inmobiliarias pagadas con la moneda.
La implementación actual registra transferencias de moneda. No incorpora un registro de titularidad de inmuebles, tokens de propiedades, custodia de garantías, escrow comercial ni resolución de disputas. Los acuerdos sobre bienes, servicios, precios, comprobantes y condiciones comerciales se gestionan fuera del protocolo.
Para poner en funcionamiento este uso se propone desarrollar órdenes de pago, direcciones por operación, conciliación de importes y confirmaciones, y procedimientos para incidencias. Estos componentes comerciales todavía no forman parte de la publicación inicial.
3. Arquitectura publicada
El nodo deriva de Bitcoin Core v30.2, base de código identificada por el commit 4d7d5f6b79d4c11c47e7a828d81296918fd11d4d. Los cambios añaden la selección -chain=saavecord, identidad de red, génesis y parámetros propios. La implementación reutiliza estructuras de bloques, validación, scripts y carteras de la base original.
Las transacciones consumen salidas anteriores y crean nuevas salidas. Las claves de la cartera permiten autorizar el gasto conforme a los scripts correspondientes. El cliente comprueba, entre otras reglas heredadas, firmas, disponibilidad de entradas, importes y límites de recompensa. Las comisiones son la diferencia entre entradas y salidas de una transacción ordinaria y pueden incorporarse a la recompensa del minero.
La configuración activa BIP34, BIP65, BIP66, CSV y SegWit desde la altura 1; Taproot conserva activación permanente en los parámetros heredados. Esas características no implican compatibilidad monetaria con otras cadenas. Las direcciones, el génesis y los identificadores seleccionan una red independiente.
La operación inicial separa el nodo P2P público de un proceso privado que carga las carteras del operador. La administración RPC se enlaza a localhost y utiliza autenticación local. La web y el explorador consumen copias públicas de datos confirmados; el navegador no recibe acceso al RPC ni a los archivos de cartera.
4. Consenso e identidad de red
| Parámetro | Valor publicado |
|---|---|
| Selección de cadena | saavecord |
| Prueba de trabajo | SHA256d |
| Intervalo objetivo | 600 segundos |
| Intervalo de reajuste | 2.016 bloques |
| Período objetivo del reajuste | 1.209.600 segundos, equivalentes a 14 días |
| Subsidio inicial | 50 SVCD por bloque |
| Reparto v0.2, previsto desde la altura 200 | 20% del subsidio para el fundador; 80% para el minero, con redondeo en unidades base |
| Comisiones de transacciones | Íntegramente para el minero |
| Reducción del subsidio | Cada 210.000 bloques |
| Madurez de coinbase | 100 bloques |
| Unidad monetaria | 1 SVCD = 100.000.000 unidades base |
| Puerto P2P | 19333 |
| RPC predeterminado del cliente | 19332, privado |
| Identificador de mensajes | fa bf b5 db |
| Prefijos Base58 P2PKH / P2SH / WIF | 63 / 125 / 191 |
| Prefijo Bech32 | sc |
Un bloque debe satisfacer el objetivo de prueba de trabajo y las reglas de validación. Entre cadenas válidas, el nodo aplica la selección heredada basada en trabajo acumulado. El reajuste modifica el objetivo cada 2.016 bloques; el cálculo limita el período observado al rango entre una cuarta parte y cuatro veces el período objetivo y respeta el máximo permitido por powLimit.
No está habilitada la excepción que reduce automáticamente la dificultad por retraso de bloques de las redes de prueba. El reajuste está habilitado y enforce_BIP94 está desactivado. Los valores nMinimumChainWork y defaultAssumeValid se inicializan en cero para esta cadena. No se distribuyen semillas DNS ni semillas fijas; el cliente inicial incorpora el nodo 51.222.111.66:19333 como punto de conexión.
El objetivo máximo de PoW es 000000ffff000000000000000000000000000000000000000000000000000000; su representación compacta inicial es 0x1e00ffff. El génesis utiliza tiempo Unix 1792800000, nonce 4060877 y versión 1. Su hash es:
000000d5834ff77f43e6d8b2e5f1811bd47e0ed5ac486e49b57dbf9803eb0550
Su raíz de Merkle es:
cb12ebabd3fb6fd2faae02179790a172fcceff3d7538b7dfaa58f7eeb3bea342
El mensaje conserva literalmente SAAVECORD private testnet genesis 2026-10-24. Se mantuvo el mismo génesis y el historial al abrir el nodo al público. La etiqueta histórica describe su origen; no identifica una segunda moneda.
5. Emisión monetaria
El subsidio se calcula en unidades enteras mínimas. Para una altura h, se obtiene k = floor(h / 210000) y se desplaza a la derecha 5000000000 unidades por k bits. El redondeo trunca fracciones de la unidad mínima. El código devuelve cero cuando k >= 64; el subsidio ya se vuelve cero por redondeo a partir de la época 33.
| Alturas | Subsidio por bloque |
|---|---|
| 0 | 50 SVCD nominales en el génesis, no gastables |
| 1 a 209.999 | 50 SVCD |
| 210.000 a 419.999 | 25 SVCD |
| 420.000 a 629.999 | 12,5 SVCD |
| 630.000 a 839.999 | 6,25 SVCD |
| 6.720.000 a 6.929.999 | 0,00000001 SVCD |
| Desde 6.930.000 | 0 SVCD de subsidio |
MAX_MONEY = 21000000 * COIN fija un límite de validación de importes de 21.000.000 SVCD. El calendario de subsidios, su redondeo y el tratamiento del génesis determinan la emisión teórica; el límite de validación no significa que se emitan exactamente 21.000.000 SVCD.
La suma del subsidio teórico incluyendo la altura 0 es 20.999.999,97690000 SVCD. Al excluir los 50 SVCD del génesis, cuya salida no se incorpora al conjunto gastable, la emisión teórica máxima por subsidios es 20.999.949,97690000 SVCD, si todos los bloques futuros reclaman el subsidio completo. Subsidios no reclamados o salidas no gastables pueden reducir la cantidad utilizable. Las comisiones redistribuyen monedas existentes y no añaden nueva emisión.
Las reducciones dependen de alturas, no de fechas garantizadas. Los 600 segundos constituyen un objetivo estadístico de consenso. El minero oficial añade una política operativa: espera hasta la marca temporal del último bloque más 600 segundos antes de comenzar otra búsqueda; el tiempo de cálculo se añade a esa espera. Otros mineros no están obligados por el consenso a utilizar esa política de espera.
Reparto obligatorio v0.2 desde la altura 200
La regla se aplica únicamente a la cadena pública saavecord desde el bloque de altura 200, incluido. Hasta la altura 199 no exige este pago. No modifica el génesis, los bloques anteriores ni las reglas de reparto de Bitcoin, sus redes heredadas o saavecord-dev.
Para cada bloque activado, el importe obligatorio del fundador es floor(subsidio_programado_en_unidades_base / 5). El resto del subsidio, incluidos los residuos de redondeo, corresponde al minero; todas las comisiones de transacciones también corresponden al minero. El reparto divide el subsidio existente: no añade emisión ni modifica su calendario de reducciones.
| Alturas | Subsidio | Pago obligatorio al fundador | Subsidio restante para el minero, más todas las comisiones |
|---|---|---|---|
| 200 a 209.999 | 50 SVCD | 10 SVCD | 40 SVCD |
| 210.000 a 419.999 | 25 SVCD | 5 SVCD | 20 SVCD |
| 420.000 a 629.999 | 12,5 SVCD | 2,5 SVCD | 10 SVCD |
| 6.090.000 a 6.299.999 | 9 unidades base | 1 unidad base | 8 unidades base |
| 6.300.000 a 6.509.999 | 4 unidades base | 0 | 4 unidades base |
| 6.720.000 a 6.929.999 | 1 unidad base | 0 | 1 unidad base |
| Desde 6.930.000 | 0 | 0 | 0; quedan las comisiones |
La dirección beneficiaria fijada por consenso es sc1q8nhr9qhpmgm56mgwwrym6h276qlxuvvesgkrn3; su script de salida exacto es 00143cee3282e1da374d6d0e70c9bd5d5ed03e6e3199. Los nodos actualizados exigen que la suma de las salidas coinbase a ese script alcance al menos el importe obligatorio. Se permiten varios pagos que lo sumen y aportaciones voluntarias adicionales. Reclamar menos subsidio para el minero no reduce la obligación del fundador. Cuando el importe obligatorio es cero por redondeo o fin del subsidio, no se exige una salida de valor cero.
Ambas partes forman parte de la misma coinbase y deben alcanzar la madurez de 100 bloques antes de gastarse. El límite total de la coinbase sigue siendo el subsidio más las comisiones. El minero oficial genera dos salidas separadas para el reparto cuando corresponde; actualmente su dirección de minado coincide con la del fundador. Si ese minero produce un bloque de subsidio 50 SVCD y lo reclama completo, ambas partes siguen bajo control del fundador, además de las comisiones. Cuando lo produce un minero independiente, el reparto inicial es 10 SVCD para el fundador y 40 SVCD más comisiones para ese minero.
Los nodos y mineros deben usar v0.2 antes de la altura 200. Desde esa altura, un bloque sin el pago obligatorio será rechazado por los nodos actualizados. Un cliente anterior no valida la nueva restricción y puede seguir una cadena incompatible. La actualización requiere coordinación entre participantes; no reinicia el historial ni permite modificar retroactivamente las recompensas anteriores.
Este mecanismo entrega SVCD únicamente cuando se acepta un bloque que lo incluye. No existe un abono por reloj cada diez minutos, un precio garantizado ni conversión automática a dinero para pagar infraestructura. El mantenimiento depende de que el operador disponga de recursos o pueda acordar un uso o intercambio de sus SVCD; esta edición no acredita esos ingresos.
6. Distribución y control inicial
La apertura conserva 102 bloques minados durante el desarrollo y 5.100 SVCD correspondientes a sus subsidios. Las dos carteras usadas en la transferencia inicial eran controladas por el fundador. Esa transferencia sirvió para verificar el funcionamiento y no demuestra adopción por usuarios independientes.
El minero oficial posterior a la apertura paga sus recompensas a una dirección controlada por una cartera del fundador. Por tanto, los 5.100 SVCD previos no representan la totalidad de las recompensas que el fundador puede acumular. Los participantes que operen otros mineros pueden configurar sus propias direcciones. Desde la activación prevista de v0.2 en la altura 200, deben respetar el pago obligatorio del 20% del subsidio al fundador; el importe restante y todas las comisiones quedan para el productor del bloque.
Como referencia histórica de la edición v0.1, se observó la altura 107 y un total de 5.350,00000000 SVCD en el conjunto UTXO; el punto de captura se verificó durante la revisión del 25 de octubre de 2026, alrededor de las 00:08 de America/Lima. Ese total incluye salidas inmaduras y no equivale a fondos inmediatamente gastables. La cadena continúa cambiando; el explorador muestra una lectura más reciente.
La publicación inicial no añade un mecanismo de vesting para los fondos del fundador. Las salidas coinbase conservan la madurez de 100 bloques y las demás condiciones de gasto que imponga su script. No se afirma una distribución entre operadores independientes, una preventa ni una asignación comunitaria que no se haya ejecutado y documentado.
7. Carteras y experiencia del usuario
Cada participante puede crear una cartera propia con el cliente Linux y obtener direcciones Bech32 que empiezan por sc1. Sus claves se almacenan en el equipo o servidor donde crea la cartera. El minero debe utilizar una dirección cuyo control corresponda al receptor de las recompensas; la cartera del operador inicial no es una cartera compartida de todos los usuarios.
El cliente incluye daemon, CLI e interfaz gráfica Qt para Linux. Algunas etiquetas, nombres de ejecutables y mensajes todavía utilizan Bitcoin o BTC. Las versiones de claves extendidas tpub y tprv se conservan de la base testnet; es necesario utilizar carteras y descriptores dedicados a SAAVECORD. No se ha publicado un cliente propio para Windows, una aplicación móvil ni una cartera web de custodia.
Las copias de seguridad y la protección de las claves corresponden a quien controla cada cartera. El explorador permite consultar bloques y transacciones confirmadas. Actualmente no calcula saldos por dirección, estado de gasto, comisiones ni transacciones pendientes. Las confirmaciones se presentan respecto de la última altura observada por el nodo del operador.
8. Operación y seguridad
La resistencia a reorganizaciones y al doble gasto depende del trabajo real dedicado a esta cadena, su distribución y las decisiones de confirmación de sus usuarios. La publicación inicial depende de un VPS, un operador y un minero oficial con capacidad CPU limitada. No se ha demostrado una distribución independiente del hash rate ni existe una medición independiente de la seguridad económica de la red.
La configuración publicada tiene una dificultad inicial que permite generar bloques con la herramienta CPU de arranque. La seguridad del proyecto no se puede deducir únicamente de utilizar SHA256d. Una incorporación importante de potencia de cálculo puede alterar la dinámica de producción y de reajuste; ese comportamiento necesita observación y revisión técnica.
Los servicios propios de nodo, minería y publicación se administran por separado. El RPC de las carteras y del nodo público permanece en localhost. El sitio publica un subconjunto de información confirmada mediante archivos JSON; no ofrece un proxy general de comandos del nodo. El explorador conserva la última lectura válida ante fallos y marca las lecturas antiguas.
El minero oficial utiliza como máximo dos hilos, prioridad baja y una cuota de CPU del 150% de un núcleo equivalente. Solicita plantillas, comprueba nuevamente el hash y el objetivo y presenta bloques al nodo. Esa herramienta no constituye una integración verificada con ASIC, Stratum ni pools de terceros.
La base de código conserva componentes y parámetros heredados de su origen de desarrollo, incluidos formatos y opciones de prueba. No existe una auditoría externa del consenso, génesis, carteras, minería o despliegue. La revisión independiente y la operación por terceros son prioridades antes de buscar integraciones institucionales.
9. Verificación realizada
En la publicación inicial se compilaron nodo, CLI, utilidades y Qt. De las 148 pruebas registradas, 147 pasaron y script_assets_tests quedó omitida.
Los resultados anteriores describen la verificación registrada de la publicación inicial. Para v0.2 se ejecutó un ensayo con dos nodos temporales enlazados solo por localhost, usando una copia del historial público y bloques privados posteriores. Se comprobó la frontera 199/200, nueve propuestas válidas e inválidas, el rechazo independiente de un bloque con PoW válido que omitía el pago obligatorio, y la aceptación de un bloque de altura 200 con 40 SVCD al minero y 10 SVCD al fundador. Ambos nodos conservaron ese bloque tras reiniciar y cerraron limpiamente. Esos bloques privados no se enviaron a la red pública.
La compilación v0.2 terminó correctamente para nodo, CLI e interfaz Qt. Sus pruebas específicas de PoW y reparto pasaron. CTest registró 149 pruebas: 148 se ejecutaron y pasaron, incluida la de Qt en modo sin pantalla; script_assets_tests quedó omitida. No se registraron fallos.
Quince pruebas de serialización del minero comprobaron además las plantillas con comisiones, la separación de pagos cuando los scripts coinciden, el compromiso SegWit, Merkle, los halvings, el redondeo y el rechazo de metadatos incorrectos. El ensayo de activación no incluyó una transacción que pagase comisiones; esa parte del reparto se comprobó con las plantillas de las pruebas. Los informes incluidos en el paquete precisan los binarios, resultados y alcance. Estas comprobaciones no constituyen una auditoría externa.
Se realizó un ensayo de dos nodos con directorios separados y una transferencia de 10 SVCD confirmada en el bloque 102. Ambas carteras estaban bajo control del operador del proyecto. El ensayo verificó recepción, madurez de coinbase, conservación del estado tras reinicio y cierre limpio; no fue una evaluación de adopción comercial ni una auditoría externa.
La transacción utilizada fue:
bc5976fc9ff3f89994a04ee9dd6ec09ee58b3f8bd29e1d534dc5149d730f8d94
También se comprobaron sincronización desde el nodo público, HTTPS, integridad de descargas y P2P externo. El explorador se verificó con importes exactos, reorganizaciones simuladas, publicación atómica y búsquedas en navegador. Los informes delimitan el alcance de estas pruebas.
10. Desarrollo propuesto
| Prioridad | Resultado propuesto | Estado de esta edición |
|---|---|---|
| Identidad y documentación | Documento técnico público y definición de símbolo comercial | Edición documental v0.4; símbolo SVCD y logo elegidos; software v0.2 |
| Revisión técnica | Auditoría independiente y resolución de hallazgos | Pendiente |
| Operación distribuida | Nodos y mineros de operadores independientes | No demostrada |
| Pagos entre personas | Mejoras de uso, respaldos y soporte de carteras | Transferencias básicas implementadas |
| Uso inmobiliario | Órdenes, direcciones por operación y conciliación de pagos | Propuesto; sin integración publicada |
| Mantenimiento abierto | Repositorio público y evolución documentada | Snapshot v0.2 publicado en GitHub; historial Git privado anterior no incluido; seguimiento de nuevas versiones pendiente |
| Distribución de software | Versiones firmadas y ampliación de plataformas | Linux disponible; firma y otras plataformas pendientes |
| Adopción y mercados | Métricas verificables de usuarios, actividad y liquidez | Sin evidencia independiente publicada |
Las prioridades no constituyen fechas de entrega comprometidas. Los cambios en consenso, génesis, emisión o identidad de red deben explicarse y revisarse antes de proponerse a los participantes. Esta edición documenta la nueva restricción de reparto de v0.2 prevista desde la altura 200; el código actualizado la aplica sin reiniciar la cadena ni alterar el calendario de emisión.
11. Límites, identidad y plataformas externas
SVCD es el símbolo comercial elegido para SAAVECORD. Las ediciones anteriores utilizaron SC para la misma moneda; no se crea otro activo ni se requiere cambiar, convertir o trasladar los fondos. Una unidad SVCD sigue equivalendo a 100.000.000 unidades base. Las direcciones conservan el prefijo sc1 y la selección de cadena sigue siendo saavecord. Los binarios publicados v0.2 y sus materiales históricos pueden conservar etiquetas SC, Bitcoin o BTC. La nueva identidad comercial no modifica el génesis, el historial, el calendario de emisión ni el reparto obligatorio del subsidio. La elección no reserva el símbolo en plataformas externas ni implica aceptación por Binance.
La inclusión en un exchange depende de su evaluación y de su decisión. No existe en esta edición una aprobación de listado para SAAVECORD, una cotización garantizada, una promesa de liquidez ni una garantía de valor. El documento tampoco acredita que terceros hayan aceptado SVCD como medio de pago.
La arquitectura publicada transfiere una moneda nativa. Cualquier servicio inmobiliario, acuerdo de pago o tratamiento económico requiere condiciones específicas entre las partes; el protocolo no sustituye esos acuerdos ni representa por sí mismo la titularidad de un bien.
12. Referencias y trazabilidad
- Sitio y documentación del proyecto: https://saavecord.com/documentacion/.
- Explorador de bloques y transacciones: https://saavecord.com/explorador/.
- Paquete Linux v0.2 con código fuente e informes: https://saavecord.com/descargas/saavecord-public-linux-x86_64-v0.2-20261025.tar.gz.
- SHA-256 del paquete v0.2:
1a888f97bdd79b68da3a6537c8b6ac7cf3ab399be4febfcd622dc20be08a9110. - Sumatoria SHA-256 del paquete: https://saavecord.com/descargas/saavecord-public-linux-x86_64-v0.2-20261025.tar.gz.sha256.
- Repositorio público, snapshot v0.2 publicado el 25 de octubre de 2026: https://github.com/1993marx/saavecord-core.
- Commit del snapshot publicado: https://github.com/1993marx/saavecord-core/commit/a252d4827f743cf7ae930723962ebd21f89945f7. No incorpora el historial Git privado anterior.
- PDF de esta edición: https://saavecord.com/descargas/saavecord-documento-tecnico-v0.4.pdf.
- PDF histórico v0.3: https://saavecord.com/descargas/saavecord-documento-tecnico-v0.3.pdf. Edición de identidad SVCD anterior a la actualización documental del estado del repositorio público.
- PDF histórico v0.2: https://saavecord.com/descargas/saavecord-documento-tecnico-v0.2.pdf. Describe el mismo consenso con la denominación comercial anterior SC.
- PDF histórico v0.1: https://saavecord.com/descargas/saavecord-documento-tecnico-v0.1.pdf. Sus reglas de reparto son anteriores a la actualización v0.2.
- Base upstream: Bitcoin Core v30.2, commit
4d7d5f6b79d4c11c47e7a828d81296918fd11d4d. En el paquete, revisarsource/saavecord-source.tar.gzysource/changes.patch. - Archivos de referencia del código:
src/kernel/chainparams.cpp,src/validation.cpp,src/consensus/amount.h,src/consensus/consensus.hysrc/pow.cpp. - Binance, criterios y vías de solicitud de listado, anuncio del 17 de diciembre de 2025: https://www.binance.com/en/support/announcement/detail/305c55a531004eb094b838ba7740c98a.
- Binance, identificación de Siacoin con símbolo SC: https://www.binance.com/en/price/siacoin. Consulta para esta edición: 25 de octubre de 2026; no se utiliza su cotización como cotización de SAAVECORD.
Esta versión debe revisarse cuando cambien software, operación, distribución de fondos, integraciones o compromisos del proyecto. El código y la cadena observada permiten contrastar las afirmaciones técnicas de esta edición.
SAAVECORD · Documento técnico · Edición documental 0.4
La información técnica debe contrastarse con el código de la versión publicada y los datos de la cadena.