#GALI DIGITAL SAS
En este post hacemos referencia a los documentos técnicos básicos referidos a la tecnología por la que optan los accionistas de GALI DIGITAL SAS.
También son documentos ficticios que a efectos demostrativos y como indicio de la posible complejidad que tienen, se incorporan a este elenco que realizamos con propósitos de enseñanza y divulgación.
Se trata de:
1 reglamento interno de decisiones electrónicas, es un documento general;
2 documentación técnica de smart contracts, cada uno de los cuales debe estar descripto precisamente en sus aspectos de cumplimiento;
3 documentación de firma electrónica;
4 documentacion de protección de datos.
Se acompaña modelo básico en el caso de los ítems 1 y 2, realizados a partir de documentos obtenidos con la IA DeepSeek.
2.° DOCUMENTACIÓN NECESARIA PARA LA GOBERNANZA MEDIANTE BLOCKCHAIN Y SMART CONTRACTS
PRIMERO. Reglamento interno de decisiones electrónicas
(Necesaria aprobación por la asamblea de accionistas, a modo de reglamentación de asamblea y debida publicidad como tal)
Debe contener lo siguiente.
1 Red blockchain utilizada: tipo (pública, privada o híbrida), protocolo, criterios de selección y nodos autorizados.
2 Procedimiento de convocatoria electrónica: plazos, mecanismo de envío, acuse de recibo y constancia de notificación.
3 Mecanismo de votación: cómo se emite el voto, cómo se verifica la identidad del votante, cómo se computan las mayorías.
4 Registro de decisiones: estructura del libro societario electrónico, contenido mínimo de cada entrada (hash del acta, fecha, identidad de votantes, resultado).
5 Relación entre el acta formal y el registro blockchain: cuál prevalece en caso de discrepancia (el acta formal, conforme a derecho).
6 Contratos inteligentes autorizados: listado de actos que pueden ejecutarse automáticamente (pago de dividendos, distribución de regalías, instrucciones de pago).
7 Gestión de claves criptográficas: quién custodia las claves, cómo se resguarda el acceso, qué ocurre en caso de pérdida o compromiso.
8 Plan de contingencia: qué sucede ante falla técnica, caída de la red o imposibilidad de acceso. Debe prever un mecanismo de degradación a medios convencionales.
9 Derecho de auditoría: cómo los accionistas acceden al registro y verifican su integridad.
MODELO DE REGLAMENTO INTERNO
GALI DIGITAL SAS - Modelo base de Reglamento Interno de Decisiones Electrónicas
CAPÍTULO I - DISPOSICIONES GENERALES
Artículo 1. Objeto
El presente Reglamento se dicta en el marco de la Ley N° 19.820 (Ley de SAS) y del Decreto N° 399/019, y tiene por objeto regular el procedimiento de adopción de decisiones de la Asamblea de Accionistas y del órgano de administración de GALI DIGITAL SAS (en adelante, "la Sociedad") por medios electrónicos, así como el uso de redes blockchain, smart contracts y mecanismos de registro y verificación digital.
Artículo 2. Marco legal
Las decisiones electrónicas se adoptan al amparo del artículo 24 de la Ley N° 19.820, que permite que las decisiones de la Asamblea, del órgano de administración o de los órganos de control se adopten mediante declaración escrita de los integrantes, pudiendo dicha conformidad ser transmitida por medios electrónicos, sin necesidad de certificación. Asimismo, el artículo 23 de la misma ley habilita la celebración de reuniones en el domicilio social o en cualquier otro lugar, así como por videoconferencia u otros medios de comunicación simultánea.
Artículo 3. Definiciones
A los efectos del presente Reglamento:
- Red blockchain : infraestructura de registro distribuido utilizada para registrar, verificar y dar fe de los hashes de las decisiones;
- Smart contract : programa informático desplegado en la red blockchain que ejecuta automáticamente operaciones predefinidas;
- Decisión electrónica : decisión de Asamblea o del órgano de administración adoptada por medios electrónicos conforme a este Reglamento;
- Hash de decisión : huella digital única generada mediante función criptográfica sobre el texto de la decisión;
- Servicio de sellado de tiempo : servicio de certificación del momento exacto de un evento.
CAPÍTULO II - RED BLOCKCHAIN E INFRAESTRUCTURA
Artículo 4. Red blockchain designada
Se designa como red principal: [nombre de la red, p. ej. "Polygon PoS" o "Ethereum mainnet"]. Se designa como red de respaldo: [nombre de la red de respaldo].
El órgano de administración podrá cambiar o ampliar la red designada, previa aprobación por resolución ordinaria de la Asamblea, cuando concurran cambios técnicos relevantes.
Artículo 5. Nodos y accesos
La Sociedad mantendrá, directamente o por terceros, al menos un nodo blockchain que garantice la accesibilidad y verificabilidad de los registros. Los accionistas y administradores accederán mediante identidades digitales autenticadas. La asignación y revocación de accesos será dispuesta por el representante de la Sociedad o por el administrador del sistema designado por el órgano de administración.
Artículo 6. Registro de hashes on-chain
Cada decisión electrónica adoptada conforme a este Reglamento generará un hash mediante SHA-256, que se registrará en la red blockchain designada junto con la marca temporal. El registro on-chain incluirá:
- el hash de la decisión;
- la fecha y hora del registro;
- el tipo de decisión (Asamblea / administración / otro);
- el número de decisión (correlativo interno).
El registro on-chain no contendrá el texto íntegro de la decisión, a efectos de preservar la confidencialidad comercial.
CAPÍTULO III - SMART CONTRACTS
Artículo 7. Despliegue y autorización
La Sociedad podrá desplegar smart contracts para:
- automatizar el cómputo de votos;
- verificar automáticamente las condiciones de aprobación;
- disparar automáticamente el registro on-chain;
- otras funciones de gobernanza automatizada aprobadas por el órgano de administración.
El despliegue de smart contracts requerirá resolución del órgano de administración y auditoría de su código fuente por al menos un auditor independiente con capacidad técnica en blockchain.
Artículo 8. Modificación y desactivación
La modificación, actualización o desactivación de smart contracts requerirá resolución del órgano de administración y se registrará en la red blockchain.
CAPÍTULO IV - PROCEDIMIENTO DE DECISIONES ELECTRÓNICAS
Artículo 9. Tipos de decisiones aplicables
Podrán adoptarse electrónicamente:
- resoluciones ordinarias y extraordinarias de la Asamblea;
- resoluciones del órgano de administración;
- resoluciones de otros órganos sociales autorizados por el estatuto o la ley.
No se aplicará el procedimiento electrónico a decisiones de disolución, liquidación, fusión o escisión, ni a la reforma integral del estatuto (salvo autorización estatutaria expresa), ni a aquellas materias que la ley o el estatuto exijan tratar en reunión.
Artículo 10. Propuesta de decisión
Cualquier accionista o administrador con derecho a voto podrá proponer un proyecto de decisión, que deberá contener:
- el texto íntegro de la decisión;
- la regla de votación aplicable (mayorías, derechos de veto, etc.);
- el plazo de votación (si correspondiere).
El proyecto se remitirá electrónicamente a todos los integrantes con derecho a voto.
Artículo 11. Mecanismos de votación
La votación se emitirá mediante:
- Comunicación electrónica : correo electrónico, mensaje electrónico autenticado o funcionalidad de votación de la plataforma de la Sociedad, dirigida a la dirección designada, que permita identificar inequívocamente al votante y su sentido de voto.
- Votación on-chain (si aplicare): mediante dirección de wallet autenticada, cuando el smart contract esté desplegado y autorizado. La validez del voto on-chain surgirá del registro blockchain.
Artículo 12. Plazo de votación
El plazo será el indicado en la propuesta y no podrá ser inferior a tres (3) días hábiles, salvo disposición legal o estatutaria distinta, o que todos los integrantes con derecho a voto acuerden abreviarlo.
Artículo 13. Aprobación
La decisión se tendrá por aprobada cuando:
- haya vencido el plazo de votación;
- se haya alcanzado la mayoría legal o estatutaria;
- no exista ejercicio válido de veto ni vicio procedimental.
Aprobada la decisión, el representante o el designado generará el hash del texto final y lo registrará en la red blockchain dentro de las veinticuatro (24) horas.
Artículo 14. Registro y notificación
Aprobada la decisión, la Sociedad notificará electrónicamente a todos los accionistas y administradores, incluyendo:
- el texto íntegro de la decisión;
- el hash y la ubicación on-chain (hash de transacción o altura de bloque);
- el cómputo de votos (a favor, en contra, abstenciones).
CAPÍTULO V - FIRMA ELECTRÓNICA E IDENTIDAD
Artículo 15. Firma electrónica
La conformidad transmitida electrónicamente podrá emitirse sin certificación, conforme al artículo 24 de la Ley N° 19.820. No obstante, la Sociedad podrá exigir firma electrónica avanzada u otro mecanismo de autenticación admitido, para mayor seguridad.
Artículo 16. Autenticación
La plataforma o los canales electrónicos adoptarán medidas razonables de autenticación, incluyendo:
- correo corporativo;
- certificado digital registrado;
- autenticación multifactor;
- dirección de wallet blockchain autorizada.
CAPÍTULO VI - CONSERVACIÓN Y VALOR PROBATORIO
Artículo 17. Conservación
La Sociedad conservará por al menos diez (10) años:
- el texto íntegro de cada decisión electrónica;
- los registros de las comunicaciones de voto;
- el hash y los registros de transacciones blockchain;
- la documentación de los smart contracts (si aplicare).
Artículo 18. Valor probatorio
El hash y el sellado de tiempo registrados en blockchain conforme a este Reglamento constituyen prueba prima facie del contenido y del momento de adopción de la decisión. Cualquier interesado podrá verificar independientemente dicho registro mediante un explorador de bloques público.
CAPÍTULO VII - SEGURIDAD Y CONTINGENCIA
Artículo 19. Medidas de seguridad
La Sociedad adoptará medidas técnicas y organizativas razonables para preservar la integridad, confidencialidad y disponibilidad del sistema de decisiones, incluyendo control de accesos, cifrado en tránsito y auditorías periódicas de seguridad.
Artículo 20. Procedimiento de contingencia
Si la red blockchain o la plataforma devinieran inoperativas, el órgano de administración podrá disponer que el procedimiento se complete temporalmente por medios electrónicos tradicionales (p. ej., correo electrónico), completándose el registro on-chain una vez restablecido el sistema. La propia decisión de contingencia será registrada.
CAPÍTULO VIII - DISPOSICIONES FINALES
Artículo 21. Modificación
Este Reglamento se modificará por resolución extraordinaria de la Asamblea de Accionistas.
Artículo 22. Vigencia
El presente Reglamento entrará en vigencia a partir de su aprobación por la Asamblea de Accionistas.
SEGUNDO. Documentación técnica de smart contracts
Debe contener lo siguiente.
1 Especificación funcional: documento que describe qué hace cada contrato inteligente, qué condiciones activan su ejecución y qué resultados produce.
2 Código fuente del smart contract: con comentarios y versión identificada mediante hash.
3 Informe de auditoría técnica: emitido por un tercero independiente, que verifique que el código hace lo que dice hacer y que no contiene vulnerabilidades.
4 Mapeo jurídico-técnico: tabla que vincula cada cláusula del contrato social con la función del smart contract que la ejecuta. Esto es clave para demostrar que la automatización respeta el estatuto.
5 Protocolo de actualización: cómo se modifica un smart contract si cambia el estatuto o la ley aplicable.
MODELO DEMOSTRATIVO DE DOCUMENTOS TÉCNICOS
# Documentación de Smart Contracts para GALI DIGITAL SAS
Naturaleza del documento : Borrador Técnico-Jurídico Simulado
Jurisdicción aplicable : República Oriental del Uruguay
Ley aplicable : Ley N° 19.820 (SAS), Ley N° 18.600 (Firma Electrónica)
## UNO - Cinco Formulaciones de Smart Contracts Operativos
Formulación 1: Registro de Obras y Derechos (Contrato de registro y titularidad)
Función : Escribir en un registro on-chain el hash SHA-256 de obras literarias digitalizadas, la identidad del autor y las cuotas de derechos (expresadas en basis points). Cada registro genera una prueba de titularidad con marca de tiempo inmutable.
Condición de activación : El Administrador o una cuenta autorizada llama a `registerWork(contentHash, authorAddress, rightsShares[])`.
Resultado : Se genera on-chain un `workId` único, asociado a las direcciones de los titulares y sus cuotas, disponible para su invocación por los contratos de licencia posteriores.
Formulación 2: Licenciamiento Automatizado (Contrato de emisión automática de licencias)
Función : Según plantillas de licencia predefinidas (por ejemplo: uso único, licencia temporal, restricción territorial), emitir automáticamente un certificado digital de licencia al licenciatario tras recibir el pago.
Condición de activación : El usuario llama a `purchaseLicense(workId, licenseType)` acompañando el pago suficiente (ETH o stablecoin).
Resultado : El contrato verifica el pago → valida la vigencia del tipo de licencia → acuña/asigna al llamador un NFT de licencia no transferible o un registro de licencia on-chain → actualiza en tiempo real el contador de uso.
Formulación 3: Distribución de Regalías (Contrato de distribución automática de regalías)
Función : Dividir automáticamente los ingresos de cada licencia según los rightsShares registrados y depositarlos en el saldo retirable de cada titular de derechos.
Condición de activación : Tras confirmar el cobro, el contrato de licencia envía una llamada `distribute(workId, amount)` al contrato de distribución.
Resultado : Se calcula la cantidad correspondiente a cada parte según los basis points → se actualiza `pendingRoyalties[address]` → el titular puede llamar a `withdraw()` en cualquier momento para retirar.
Formulación 4: Gobernanza Societaria Simplificada (Contrato de gobernanza societaria)
Función : Registrar y ejecutar las "resoluciones por consentimiento escrito" permitidas por el artículo 24 de la Ley 19.820. Los accionistas envían su voto mediante firma criptográfica y el contrato registra automáticamente el resultado de la resolución cuando se alcanza la mayoría legal.
Condición de activación : Un accionista llama a `castVote(proposalId, voteHash, signature)`.
Resultado : Cuando los votos favorables alcanzan la mayoría prevista en el estatuto (resolución ordinaria: mayoría del capital integrado; modificación de cláusulas relacionadas con arts. 19, 41, 44: 100%) → el contrato emite el evento `ResolutionPassed` → activa automáticamente las operaciones on-chain relacionadas (por ejemplo, modificación de parámetros de condiciones de licencia).
Limitación legal : Este contrato actúa únicamente como herramienta auxiliar de registro y ejecución ; la eficacia externa de la resolución requiere aún la elaboración de un Acta conforme a la ley y la práctica de la inscripción registral.
Formulación 5: Actualización Paramétrica por Reforma Estatutaria (Contrato de actualización de parámetros por reforma estatutaria)
Función : Cuando una modificación del estatuto altera las condiciones de licencia, los porcentajes de regalías o los parámetros de gobernanza, actualizar los parámetros configurables en el contrato lógico mediante el patrón de contrato proxy, en lugar de redesplegar.
Condición de activación : Tras completar off-chain el procedimiento de modificación estatutaria conforme al artículo 35 de la Ley 19.820 (resolución de accionistas + inscripción), la dirección del Administrador llama a `updateParameters(newParams)`.
Resultado : La dirección `implementation` del contrato proxy apunta al nuevo contrato lógico, la capa de almacenamiento permanece inalterada; el contrato lógico antiguo queda deshabilitado.
## DOS - Documentación Técnica de Smart Contracts
1 Especificación Funcional
Contrato A: IPRegistry.sol
Elemento | Descripción |
Qué hace | Registra el hash de obras literarias digitalizadas, las direcciones de los autores y las cuotas de derechos; ofrece interfaz de consulta de titularidad |
Condiciones de activación | El rol `Administrador` o `Registrar` llama a `registerWork(bytes32 contentHash, address[] rightsHolders, uint256[] sharesBps)` |
Resultados | Genera `workId`; almacena `Work{contentHash, rightsHolders, sharesBps, timestamp, active}`; emite el evento `WorkRegistered(workId, contentHash)` |
| Restricciones | `contentHash` no puede repetirse; la suma de `sharesBps` debe ser igual a 10000 (100%) |
Contrato B: LicenseManager.sol
Elemento | Descripción |
Qué hace | Gestiona tipos de licencia, procesa pagos y emite certificados de licencia |
Condiciones de activación | El usuario llama a `purchaseLicense(uint256 workId, uint8 licenseType)` acompañando `msg.value >= licenseFee` |
Resultados | El pago se transfiere a `RoyaltyDistributor`; el llamador obtiene `License{workId, licensee, licenseType, expiry, active}`; se emite el evento `LicensePurchased(workId, licensee, licenseType)` |
Dependencias | Requiere `IPRegistry.workExists(workId) == true`; requiere que `licenseType` esté habilitado para esa obra en `IPRegistry` |
Contrato C: RoyaltyDistributor.sol
Elemento | Descripción |
Qué hace | Recibe los ingresos de licencias y los distribuye entre los saldos retirables de cada titular según las cuotas registradas |
Condiciones de activación | `LicenseManager` llama a `distribute(uint256 workId)` (payable) |
Resultados | Recorre `IPRegistry.getRightsHolders(workId)`; calcula `share = msg.value * sharesBps / 10000`; actualiza `pendingRoyalties[holder] += share`; emite el evento `RoyaltiesDistributed(workId, totalAmount)` |
Extracción | El titular llama a `withdraw()` para retirar su saldo |
Contrato D: SimpleGovernance.sol
Elemento | Descripción |
Qué hace | Registra las votaciones de resoluciones por consentimiento escrito conforme al artículo 24 de la Ley 19.820 |
Condiciones de activación | Una dirección de accionista con derecho a voto llama a `castVote(uint256 proposalId, bytes32 voteHash, bytes signature)` |
Resultados | Registra el voto; cuando los votos favorables alcanzan `requiredMajority` (basado en el capital integrado), establece `proposal.executed = true` y emite `ProposalExecuted` |
Nota legal | La ejecución on-chain es solo registral; la modificación estatutaria externa requiere aún completar el procedimiento de inscripción |
2 Código Fuente del Smart Contract (ejemplo: IPRegistry.sol)
```solidity
// SPDX-License-Identifier: MIT
// Versión: 1.0.0
// Hash de compilación: [sha256 del bytecode compilado - completar tras compilación]
// Red objetivo: Ethereum Mainnet / Polygon (a definir según decisión del Administrador)
pragma solidity ^0.8.20; /
* @title IPRegistry
* @notice Registro de obras literarias digitalizadas y derechos de autor
* @dev Operado por GALI DIGITAL SAS. Los shares se expresan en basis points (10000 = 100%)
*/ contract IPRegistry {
address public administrador; // Dirección del Administrador de GALI DIGITAL SAS
struct Work {
bytes32 contentHash; // SHA-256 del archivo digitalizado
address[] rightsHolders; // Direcciones de los titulares
uint256[] sharesBps; // Basis points por titular (suma = 10000)
uint256 timestamp; // Bloque de registro
bool active; // Estado de la obra }
mapping(uint256 => Work) public works;
mapping(bytes32 => bool) public hashRegistered; // Prevención de duplicados
uint256 public nextWorkId;
event WorkRegistered(uint256 indexed workId, bytes32 contentHash, uint256 timestamp);
event WorkDeactivated(uint256 indexed workId);
modifier onlyAdministrador() {
require(msg.sender == administrador, "Solo Administrador"); _; }
constructor() { administrador = msg.sender; } /
* @notice Registra una nueva obra digital
* @param contentHash Hash SHA-256 del archivo
* @param rightsHolders Array de direcciones de titulares
* @param sharesBps Array de basis points (suma debe ser 10000)
*/
function registerWork(
bytes32 contentHash,
address[] calldata rightsHolders,
uint256[] calldata sharesBps
) external onlyAdministrador returns (uint256) {
require(!hashRegistered[contentHash], "Obra ya registrada");
require(rightsHolders.length == sharesBps.length, "Longitud inconsistente");
require(rightsHolders.length > 0, "Sin titulares");
uint256 totalShares = 0;
for (uint256 i = 0; i < sharesBps.length; i++) {
totalShares += sharesBps[i]; }
require(totalShares == 10000, "Shares deben sumar 10000");
uint256 workId = nextWorkId++;
works[workId] = Work({
contentHash: contentHash,
rightsHolders: rightsHolders,
sharesBps: sharesBps,
timestamp: block.timestamp,
active: true });
hashRegistered[contentHash] = true;
emit WorkRegistered(workId, contentHash, block.timestamp);
return workId; } /
* @notice Obtiene los titulares y shares de una obra
*/ function getRightsHolders(uint256 workId) external view returns (
address[] memory,
uint256[] memory )
{ Work storage w = works[workId];
return (w.rightsHolders, w.sharesBps); }
function workExists(uint256 workId) external view returns (bool) {
return works[workId].active; }
Hash de versión : `[placeholder]` - Debe generarse al momento de la compilación final y publicarse en el repositorio de auditoría.
3 Informe de Auditoría Técnica (marco estructural)
Informe de Auditoría - [Nombre de Firma Auditora Independiente]
| Sección | Contenido requerido |
| Alcance | Contratos: IPRegistry.sol, LicenseManager.sol, RoyaltyDistributor.sol, SimpleGovernance.sol |
| Metodología | Análisis estático (Slither/Mythril), pruebas unitarias (Hardhat), revisión manual de lógica |
| Verificación de Especificación | Confirmar que cada función ejecuta exactamente lo declarado en la Sección 1.1 |
| Vulnerabilidades encontradas | Reentrancy en `withdraw()`; Overflow en cálculos de shares; Control de acceso en `registerWork` |
| Mitigaciones aplicadas | ReentrancyGuard; SafeMath (o Solidity 0.8+ nativo); modifier `onlyAdministrador` |
| Limitaciones | La auditoría no verifica la validez legal de la operativa societaria ante la Ley 19.820; solo verifica corrección técnica |
| Conclusión | Los contratos ejecutan las funciones especificadas sin vulnerabilidades críticas identificadas |
| Fecha y versión del código | [Fecha] - Hash: `[sha256]` |
Advertencia : La auditoría técnica no sustituye el asesoramiento legal sobre la oponibilidad de las operaciones blockchain frente a terceros ni la inscripción registral requerida por el artículo 35 de la Ley 19.820.
4 Mapeo Jurídico-Técnico
| Cláusula del Estatuto (referencia tipo) | Función del Smart Contract | Contrato | Estado de conformidad |
| Artículo X - Objeto social : gestión de derechos de autor de obras digitalizadas | `registerWork()`, `purchaseLicense()` | IPRegistry / LicenseManager | ✅ Alineado |
| Artículo Y - Capital y acciones : acciones escriturales | Tokenización opcional de acciones (fuera del alcance de este documento) | - | ⚠️ Requiere decisión separada |
| Artículo Z - Administración : Administrador único con facultades de registro | `onlyAdministrador` controla `registerWork()` | IPRegistry | ✅ Alineado |
| Artículo W - Asamblea : resoluciones por consentimiento escrito (Art. 24 Ley 19.820) | `castVote()` registra y computa votos electrónicos | SimpleGovernance | ⚠️ El cómputo es auxiliar; la validez formal requiere acta |
| Artículo V - Distribución de utilidades / regalías | `distribute()` / `withdraw()` | RoyaltyDistributor | ✅ Alineado operativamente |
| Artículo U - Reforma estatutaria (Art. 35 Ley 19.820: mayoría del capital integrado; 100% para arts. 19/41/44) | `updateParameters()` vía proxy | Proxy de actualización | ⚠️ Requiere finalización del procedimiento registral previo |
| Artículo T - Restricciones a transferencia de acciones | - | - | ❌ No implementado on-chain (decisión del Administrador) |
Nota crítica : El mapeo demuestra que la automatización respeta las facultades estatutarias en la medida en que el Administrador humano mantenga el control final sobre las operaciones vinculantes y los actos inscribibles se realicen fuera de la cadena.
5 Protocolo de Actualización (protocolo de upgrade)
Principio general : Los smart contracts desplegados en blockchain son inmutables por diseño ; su modificación requiere patrones arquitectónicos específicos.
Mecanismo adoptado: Proxy Transparente (Transparent Proxy Pattern)
| Paso | Acción | Responsable |
| 1 Detección de necesidad | Cambio en el Estatuto (Art. 35 Ley 19.820) o cambio normativo que afecte parámetros on-chain | Asesoría legal de GALI DIGITAL SAS |
| 2 Resolución societaria | Aprobación por asamblea según mayoría legal; 100% si afecta arts. 19/41/44 | Accionistas |
| 3 Registro | Inscripción del testimonio del acta en el Registro de Personas Jurídicas (Sección Registro Nacional de Comercio) | Escribano / Administrador |
| 4 Desarrollo de nuevo Logic Contract | Nueva versión del contrato con parámetros actualizados; conserva el mismo storage layout | Desarrollador / Auditor |
| 5 Auditoría | Revisión independiente del nuevo contrato antes del despliegue | Firma auditora externa |
| 6 Despliegue del nuevo Logic Contract | Se despliega la nueva dirección de implementación | Administrador (multisig recomendado) |
| 7 Ejecución de Upgrade | Llamada al `ProxyAdmin.upgrade(newImplementation)`; Time-lock de 48–72 horas para transparencia | Multisig (2-de-3 mínimo) |
| 8 Verificación post-upgrade | Confirmar que el storage anterior persiste y las funciones operan correctamente | Auditor / Administrador |
Salvaguardas de seguridad requeridas :
- Multisig Wallet : La facultad de upgrade no debe residir en una sola clave privada.
- Time-lock : Retraso obligatorio entre la propuesta de upgrade y su ejecución para permitir revisión.
- Evento on-chain obligatorio : `Upgraded(address newImplementation)` para trazabilidad.
- Registro off-chain : Documentar cada upgrade en el Libro de Actas del Administrador.
Limitación legal fundamental : Ninguna actualización on-chain puede sustituir la inscripción registral exigida por el Art. 35 para la oponibilidad frente a terceros. La blockchain registra la ejecución técnica; el Registro Público registra la validez jurídica.
TERCERO. Documentación de firma electrónica, ley n. 18.600.
Debe contener lo siguiente.
1 Declaración del tipo de firma utilizada: firma electrónica avanzada, que emitida por prestador acreditado, tiene presunción legal de validez equivalente a la firma manuscrita certificada.
2 Certificado del prestador de servicios de certificación: debe estar acreditado ante la Unidad Reguladora de Servicios de Comunicaciones (URSEC) o el organismo que corresponda.
3 Política interna de uso de firma electrónica: quiénes pueden firmar, con qué tipo de firma, cómo se valida, qué ocurre en caso de disputa.
4 Manual de usuario para accionistas y administradores sobre el uso de la firma digital.
CUARTO. Documentación de protección de datos, ley n.° 18.331
Debe contener lo siguiente.
1 Inscripción de la base de datos ante la Unidad Reguladora y de Control de Datos Personales (URCDP).
2 Modelo de consentimiento informado para autores y titulares de derechos, conforme a los principios de consentimiento libre, previo, expreso e informado.
3 Política de privacidad y tratamiento de datos.
4 Documento de medidas de seguridad: debe explicar cómo se compatibiliza la inmutabilidad de blockchain con el derecho de supresión (derecho al olvido). Práctica habitual: almacenar datos personales off-chain y en la cadena solo el hash.
5 Registro de actividades de tratamiento (si corresponde por volumen o sensibilidad).
Imagen Public Domain Review, Lorenza Stoer s. XVI
https://publicdomainreview.org/collection/the-geometric-landscapes-of-lorenz-stoer-1567/
No hay comentarios:
Publicar un comentario