#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/
