dCorps Hub
DevCo Testnet Fundación Auditoría Mainnet Adopción

Corporación privada estándar

Qué es

CORP-PRIVATE-STD es la configuración estándar de empresa privada en dCorps para equipos con múltiples propietarios. Crea un perfil público de la empresa, el conjunto básico de carteras y vínculos de roles que separan autoridad administrativa, tesorería y aprobaciones. Varios propietarios cofirman acciones protegidas para que ningún cartera controle todo, mientras la vista pública se mantiene clara y fácil de verificar en la blockchain.

Código de modelo

Código de modelo: CORP-PRIVATE-STD. Esta etiqueta mantiene el modelo consistente entre apps, enlaces y vistas públicas.

Control compartido

Un entity_id con múltiples carteras de propietarios que comparten autoridad; las acciones protegidas requieren aprobaciones de cofirma.

Unidades compartidas

Las unidades de propiedad se reparten entre titulares, y las transferencias siguen reglas de aprobación por diseño.

Tipos de carteras estándar

Los tipos de carteras estándar separan ingresos, gastos y reservas, mientras las carteras de autoridad firman aprobaciones de tesorería.

Flujos etiquetados

Los pagos llevan etiquetas que explican por qué se movió el dinero y qué ruta de aprobación se usó.

Posición del modelo

CORP-PRIVATE-STD se sitúa entre el modelo en solitario y los modelos de gobernanza avanzada. Agrega aprobaciones compartidas y separación de funciones manteniendo la estructura simple. Baja al modelo en solitario cuando el control se consolida en un propietario, o sube a venture o privado complejo cuando la gobernanza se expande.

Modelo en solitario

Baja a CORP-SOLO cuando un propietario controla las aprobaciones y ya no se requiere cofirma compartida.

Modelo venture

Sube a CORP-VENTURE para gobernanza de directorio, rondas de inversionistas y equity multiclase.

Privado complejo

Sube a CORP-COMPLEX-PRIVATE para comités, asuntos protegidos o holdings multi-entidad.

Ideal para

CORP-PRIVATE-STD encaja para empresas privadas con dos o más propietarios y gasto operativo recurrente. Es ideal para equipos fundadores, estudios y negocios familiares que quieren roles claros, aprobaciones rutinarias y pagos nativos en stablecoins. El trabajo diario puede avanzar rápido mientras las acciones de alto impacto requieren cofirma.

Aprobaciones compartidas

Las acciones protegidas requieren al menos dos firmantes para que las decisiones sean compartidas y responsables.

Nativo de stablecoins

Las entradas y salidas de dinero funcionan en stablecoins en lugar de rieles bancarios, así el flujo se mantiene en la blockchain.

Separación de funciones

Los roles administrativos y de tesorería se separan para que un cartera no pueda crear y aprobar la misma acción.

Equipos operativos

Diseñado para equipos con gasto recurrente y aprobaciones que quieren roles claros sin mucha sobrecarga.

No es adecuado para

Este modelo no es para configuraciones de un solo propietario sin aprobaciones, y no está diseñado para directorios estilo venture ni equity multiclase. Asume control compartido con aprobaciones rutinarias, por lo que una gobernanza muy compleja debería usar modelos avanzados. Las organizaciones impulsadas por donaciones se alinean con modelos sin fines de lucro diseñados para recaudar fondos y desembolsos.

Simplicidad en solitario

CORP-SOLO encaja cuando un cartera controla todo y las aprobaciones no forman parte de la configuración.

Estructura venture

Las rondas de financiación con directorio o el equity multiclase se alinean con CORP-VENTURE.

Modelo sin fines de lucro

Las organizaciones sin fines de lucro siguen flujos de donación y asignación y se alinean con modelos sin fines de lucro construidas para recaudar fondos.

Propiedad y unidades

Mantén porcentajes claros entre varios titulares expresando participaciones en unidades base. Las transferencias y emisiones de unidades pasan por acciones de aprobación, de modo que los cambios de propiedad se mantienen controlados y visibles. Se pueden agregar más unidades después para mayor precisión sin cambiar los porcentajes existentes.

Unidades base predeterminadas

Empieza con 10.000 unidades base para que las divisiones de propiedad sigan siendo legibles entre varios titulares.

Un voto por unidad

La votación sigue la propiedad por unidades de forma predeterminada, de modo que los votos de cada titular coinciden con su participación, a menos que la gobernanza lo cambie.

Expansión de precisión

Agrega más unidades base después para aumentar la precisión manteniendo el mismo porcentaje de cada titular.

Autoridad y gobernanza

Separa roles administrativos, de tesorería y de aprobación para que ningún cartera pueda crear y aprobar la misma acción. Las acciones protegidas requieren cofirmas y dejan un rastro visible para cada decisión. Los cambios de rol y la rotación de claves se registran en la blockchain para que la autoridad vigente quede clara.

Separación de roles

Los roles administrativos, de tesorería y de aprobación se distribuyen entre carteras para que control y ejecución permanezcan separados.

Capa de aprobación

Los roles de aprobación cofirman acciones protegidas de tesorería y políticas para una responsabilidad compartida.

Rotación de claves

Las claves pueden rotarse mediante acciones de gobernanza para que los cambios de acceso permanezcan públicos y trazables.

Acciones protegidas

Las acciones sensibles requieren múltiples aprobaciones antes de mover fondos o cambiar políticas.

Carteras de roles de empleados

Puedes delegar trabajo mientras las aprobaciones quedan en manos de aprobadores designados usando carteras de roles. Los operadores pueden preparar facturas, etiquetar pagos o preparar desembolsos, y los aprobadores firman antes de mover fondos. Esto mantiene el trabajo en movimiento mientras la responsabilidad permanece compartida.

Tipos de rol

Las carteras de rol pueden configurarse para operadores, contadores, aprobadores o ejecutores de pagos en todo el equipo.

Permisos por alcance

Los permisos pueden permitir facturación, etiquetado o preparación de pagos, mientras bloquean la ejecución hasta que firmen las aprobaciones requeridas.

Separación de receptores

Los carteras de pago reciben fondos, mientras las carteras de rol manejan la autoridad, a menos que la empresa vincule ambas.

Límites de delegación y aprobación

Establece límites de aprobación para definir qué puede ejecutarse automáticamente y qué debe ser cofirmado. Los umbrales de control dual mantienen las transferencias grandes esperando firmas de aprobadores, mientras los pagos rutinarios se aprueban rápido. Los límites pueden variar por cartera o categoría para que distintos equipos sigan sus propios controles.

Alcance del rol

Cada rol incluye un alcance claro que enumera qué acciones puede preparar, aprobar o ejecutar.

Umbrales de aprobación

Los umbrales fijan el monto o nivel de riesgo que activa una aprobación por cofirma.

Límites por cartera y categoría

Los límites pueden ajustarse por tipo de cartera o categoría de gasto para que distintas actividades sigan sus propios controles.

Estructura de carteras

Separa el dinero por propósito para que la actividad sea fácil de seguir. Un cartera recibe pagos de clientes, otro maneja el gasto operativo y un cartera de reserva puede guardar ahorros. Los carteras de autoridad firman aprobaciones, mientras los carteras de pago reciben y envían fondos. Esto mantiene el control separado del efectivo para que la actividad sea fácil de verificar.

Cartera de comerciante

El tipo de cartera MERCHANT es el cartera público de cobro donde llegan los ingresos de clientes.

Tesorería operativa

El tipo de cartera OPERATING_TREASURY maneja los gastos rutinarios del negocio y los pagos salientes a proveedores y contratistas.

Cartera de reservas

El tipo de cartera RESERVES guarda colchones o fondos a largo plazo cuando decides apartar una parte.

Separación de autoridad

Los carteras de autoridad pueden incluir varios firmantes propietarios para aprobaciones, mientras los carteras de pago reciben y envían fondos para que el control quede separado del efectivo.

Activos operativos

Los totales de reporte se muestran en USDC para que los valores se mantengan estables y comparables. Los carteras de tesorería también pueden tener DCHUB para gas o exposición a largo plazo si decides mantenerlo. Esas tenencias se etiquetan para que los resúmenes sean claros y no se mezclen con el efectivo operativo.

Unidad de reporte

Todos los reportes en v0.1 usan totales en USDC para que las vistas se mantengan estables en el tiempo y entre herramientas.

Tenencias de tesorería

Los carteras de tesorería y reserva pueden tener DCHUB junto a stablecoins cuando quieras exposición a la red.

Activos etiquetados

Los saldos en DCHUB deben llevar asset_tag y BAL_DCHUB para que los exploradores los separen del efectivo operativo.

Pagos de gas

Las comisiones de transacción se pagan en DCHUB por el cartera firmante cada vez que envía una transacción.

Comercio y modos de pago

CORP-PRIVATE-STD admite pagos directos y facturas, para que los clientes paguen como les convenga. Los planes recurrentes cubren la facturación de suscripciones con pagos programados que se ejecutan en la blockchain. Cada factura tiene un estado para que el equipo vea al instante qué está abierta, pagada o cancelada.

Pagos directos

Los clientes pueden pagar directamente al cartera de comerciante cuando el monto es conocido de antemano.

Solicitudes de factura

Las facturas son solicitudes de pago en la blockchain vinculadas a la entidad, con monto, fecha de vencimiento y referencia del pagador.

Planes recurrentes

Los planes recurrentes programan la facturación repetida para que suscripciones u honorarios fijos funcionen sin reingreso manual.

Actualizaciones de estado

El estado de cada factura se actualiza al pasar de abierta a pagada o cancelada, para que el seguimiento sea claro.

Ítems de catálogo

Define lo que vendes una sola vez para que facturas y pagos se mantengan organizados a medida que crece el negocio. Cada ítem tiene un nombre, precio e ID que se puede reutilizar en facturas y etiquetas. Esto crea una vista consistente de ventas sin volver a escribir detalles cada vez.

Referencia del ítem

Crea un item_id con una etiqueta clara y precio para que cada producto o servicio sea fácil de reutilizar.

Base de costos

Agrega una base de costos opcional para poder estimar márgenes después sin suposiciones retroactivas.

Vinculación de facturas

Usa item_id en facturas y etiquetas para conectar la actividad de ventas con totales y vistas.

Flujos de nómina y contratistas

Etiqueta pagos de nómina y contratistas para que la compensación sea visible sin mezclarla con roles de autoridad. Los carteras de pago reciben fondos, mientras los roles de aprobación controlan cuándo salen los pagos. Las apps pueden programar o agrupar pagos para coincidir con ciclos de nómina.

Carteras de pago

Los carteras de pago reciben salarios o pagos a contratistas directamente, separados de cualquier rol de autoridad.

Pagos etiquetados

Los pagos llevan etiquetas de nómina o contratistas para que la compensación sea fácil de identificar en los resúmenes.

Programaciones opcionales

Las apps o SDKs pueden programar o agrupar pagos cuando quieras pagos recurrentes o por lotes.

Etiquetado y evidencia

Las etiquetas son rótulos simples añadidos a cada pago para que la actividad sea comprensible con el tiempo. Para transacciones importantes, puedes adjuntar prueba anclando una referencia segura a una factura, recibo o acuerdo. Esto crea un rastro claro sin publicar archivos privados.

Requeridos básicos

Estas etiquetas son obligatorias en cada flujo para que las vistas se mantengan consistentes. Empareja reference_type con reference_id.

category_code counterparty_type reference_id reference_type

Contexto operativo

Las etiquetas opcionales separan la actividad por equipo, producto, proyecto o canal para un seguimiento más claro.

business_unit_tag department_tag cost_center_tag project_tag product_tag item_id channel_tag region_tag counterparty_tag

Contexto de equity

Estas etiquetas aplican solo si se agregan flujos de equity más adelante, como clases, pools o vesting.

equity_class_tag vesting_schedule_tag option_pool_tag

Anclajes de evidencia

Los anclajes enlazan a facturas, recibos o acuerdos sin publicar el documento en sí.

Umbral de materialidad

Configura un umbral de materialidad para que los elementos grandes requieran evidencia, con 1.000 USDC como valor predeterminado.

Directorio de contrapartes y privacidad

Los clientes o proveedores recurrentes pueden etiquetarse con apodos privados en lugar de nombres reales. El mapeo al mundo real permanece fuera de cadena bajo tu control, lo que protege datos sensibles. Las vistas públicas muestran solo la etiqueta y el cartera, no la identidad subyacente. Aun así obtienes un historial consistente de quién paga y quién recibe pagos sin exponer identidades.

IDs seudónimos

Usa counterparty_tag para etiquetar clientes o proveedores recurrentes sin exponer sus nombres legales en la blockchain.

Mapeo fuera de cadena

Mantén el mapeo de nombres reales fuera de cadena para que solo tu equipo pueda verlo.

Contrapartes recurrentes

Haz seguimiento de contrapartes recurrentes en facturas y pagos sin publicar detalles personales o comerciales.

Flujo operativo

Pasa de la configuración a la actividad en vivo con una secuencia simple. La configuración comienza con múltiples carteras de propietarios, un nombre de entidad y umbrales de aprobación para acciones protegidas. Registras la entidad, conectas carteras, recibes pagos y etiquetas lo que ocurre para que las vistas se mantengan consistentes. Cada paso escribe en el historial en la blockchain, lo que mantiene las operaciones claras para el equipo y para cualquiera que verifique.

1

Registrar y vincular propietarios

Registra la entidad y vincula los carteras de propietarios junto con roles administrativos, de tesorería y de aprobación.

2

Configurar carteras y umbrales

Conecta los carteras estándar y establece umbrales de aprobación para que las acciones de tesorería requieran cofirmas por encima de los límites.

3

Delegar roles

Agrega carteras de roles de empleados y carteras de pago para que los equipos puedan preparar trabajo sin firmar.

4

Cobrar ingresos

Emite facturas o acepta pagos directos para que los ingresos lleguen al cartera de comerciante.

5

Etiquetar y anclar

Etiqueta el dinero que entra y sale, y ancla evidencia para elementos materiales que requieran prueba.

6

Revisar y cerrar

Revisa las vistas en vivo y luego cierra un período si quieres una foto fija para comparar después.

Vistas en vivo en la blockchain

Los exploradores muestran resúmenes en vivo de transacciones etiquetadas sin esperar exportaciones manuales. Puedes ver saldos, actividad reciente y cobertura de etiquetas en tiempo real. Otros pueden revisar los mismos números que ves, lo que mantiene la visibilidad pública sincronizada.

Saldos de carteras

Los saldos de carteras se actualizan a medida que las transacciones se confirman en la blockchain, por lo que los números se mantienen al día.

Vistas por ventana de tiempo

Las vistas por ventana de tiempo resumen la actividad en un período sin esperar un cierre manual.

Índices de cobertura

Los índices de cobertura muestran qué flujos están completamente etiquetados y cuáles aún requieren contexto.

Exportaciones de datos

Las exportaciones son opcionales para análisis offline o respaldos cuando quieras archivos fuera de la cadena.

Registro, bitácoras y pruebas

Usa el registro y la bitácora de gobernanza para verificar identidad, estado, carteras oficiales, aprobaciones, cofirmas y cambios de rol. Cada entrada de aprobación muestra quién firmó y cuándo, creando un rastro claro de decisiones. Los anclajes registran sellos de tiempo en documentos cuando se requiere prueba, para que el historial se mantenga duradero y verificable.

Entrada de registro

El registro lista la identidad, el estado y las vinculaciones oficiales de carteras para que cualquiera pueda verificar la configuración actual.

Bitácora de gobernanza

La bitácora de gobernanza muestra aprobaciones, cofirmas y cambios de rol en orden temporal para una responsabilidad clara.

Pruebas ancladas

Los anclajes registran sellos de tiempo en recibos y contratos para que su existencia pueda verificarse después sin publicar los archivos.

Ciclo de vida y estado

Las señales muestran si una empresa está activa, pausada o cerrada, para que las personas sepan si los pagos deben proceder. Las apps pueden mostrar el estado automáticamente como una señal simple de seguridad. Esto reduce confusiones y evita que el dinero vaya a entidades inactivas.

Estados

Las etiquetas de estado muestran si la entidad está activa y es segura para pagar, usando un conjunto de colores consistente.

borrador activa suspendida disuelta

Puntos de pago

Los puntos de pago se resuelven a partir del entity_id y el tipo de cartera, para que los usuarios no copien direcciones en bruto.

Advertencias de interfaz

Las interfaces pueden advertir cuando una entidad está suspendida o disuelta para que los pagadores eviten enviar fondos.

Rutas de actualización

A medida que la empresa crece o se simplifica, puede moverse a un modelo diferente sin perder continuidad. Las actualizaciones agregan flujos de directorio, términos de inversionistas o gobernanza compleja, mientras la simplificación puede volver a una configuración de un solo propietario. El mismo historial de entidad permanece intacto en las transiciones.

Modelo venture

El código de modelo CORP-VENTURE agrega aprobaciones de directorio, términos de inversionistas y etiquetado de equity para estructuras con venture capital.

Privado complejo

El código de modelo CORP-COMPLEX-PRIVATE soporta comités, asuntos protegidos y holdings multi-entidad para gobernanza avanzada.

Modelo en solitario

El código de modelo CORP-SOLO encaja cuando la propiedad se consolida en un solo controlador y las aprobaciones se minimizan.

Dónde operar y verificar

La app oficial maneja acciones del día a día como registro, facturación y aprobaciones. Las herramientas públicas (registro, explorador e indexador oficial) permiten verificar identidad, estado y vinculaciones de carteras. Esto mantiene en sincronía lo que haces y lo que otros ven en la red.

App oficial

La app oficial es donde registras, emites facturas, etiquetas pagos y apruebas acciones.

El registro

El registro confirma identidad, estado y carteras oficiales para que las contrapartes verifiquen a quién están pagando.

El explorador

El explorador, impulsado por el indexador oficial, muestra transacciones, saldos e historial público en una sola vista.

Indexador oficial

Servicio de datos de referencia que impulsa los resúmenes del explorador y las vistas de reportes para una visibilidad pública consistente.

dApps & SDKs

Las dApps y SDKs de terceros te permiten crear flujos personalizados o integrar pagos en tus propios productos.

Manifiesto

"Mi objetivo es simple: permitir que cualquiera, en cualquier lugar, pueda crear una entidad capaz de operar con credibilidad, continuidad y con infraestructura financiera real, diseñada para operaciones en stablecoins."

Leer el Manifiesto

Nicolas Turcotte

Fundador e ingeniero principal

Contribuye ahora

La testnet es para constructores, operadores y responsables que quieren validar el Hub en público.

Ingenieros de protocolo

Trabajando en definiciones del kernel, alcance de mensajes e invariantes.

Ingenieros de indexación y datos

Definiendo esquemas de eventos y entradas reproducibles para las vistas.

Operadores tempranos

Probando el secuenciador, la publicación de lotes y el alcance operativo bajo reglas de testnet.

Inversionistas alineados con la infraestructura

Siguiendo alcance, riesgos y progreso (sin promesas de retorno).

Asesoría legal

Revisando la postura de límites, el alcance no custodial y el orden de la pila documental.

Responsables de gobernanza

Definiendo la separación kernel/adaptadores y la postura de actualización.

Solo en inglés
Testnet

Acceso a la testnet

Solicita acceso para explorar el Hub, probar las interfaces de referencia y validar el comportamiento del protocolo de punta a punta en la testnet de desarrollo. Cualquiera puede solicitar acceso; el acceso de operador local/dev se revisa con mayor rigor.

Solicitar acceso a la testnet

Acceso controlado. Aprobación requerida.

Testnet Solo en inglés

Acceso a la testnet

Solicita acceso para explorar el Hub, probar las interfaces de referencia y validar el protocolo en la testnet de desarrollo. El acceso local/dev de operador se revisa con mayor rigor.

Solicitar acceso a la testnet

Boletín Solo en inglés

Mantente informado

Actualizaciones concisas sobre la preparación de la testnet, lanzamientos y hitos de gobernanza.