Whitepaper

Request Network

El Futuro del Comercio

Una red descentralizada para solicitudes de pago

13 de marzo de 2018

Indice

1. Resumen Ejecutivo 3

2. La plataforma 3

3. El ecosistema 83.1. El protocolo Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2. Las Extensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. Las Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Casos de uso 114.1. Facturacion de negocio a negocio (B2B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2. Pagos online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3. Automatizacion de tareas: Contabilidad, Auditorıa, Gastos . . . . . . . . . . . . . . . . . . . 13

4.3.1. Contabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3.2. Auditorıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.3. Gastos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4. Logica de negocio y leyes comerciales - Gobierno e Impuestos . . . . . . . . . . . . . . . . . . 164.5. Simplificacion de herramientas comerciales: Factoraje, Depositos . . . . . . . . . . . . . . . . 164.6. Transparencia de las instituciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.7. IoT y contratos inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5. Token 175.1. Incentivo para asegurar el ecosistema de las aplicaciones . . . . . . . . . . . . . . . . . . . . . 175.2. Gobernanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3. Independencia de otras monedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4. Independencia tecnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5. Facilitar el intercambio de diferentes monedas . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6. Borrador del Roadmap (Programa) 19

7. Equipo 207.1. Equipo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8. Arquitectura 218.1. Consideraciones Tecnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2. Arquitectura de los contratos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

9. Agradecimientos 24

10.Bibliografıa 25

1. Resumen Ejecutivo

Request es una red descentralizada1 que permite a cualquier persona solicitar un pago (en ingles, RequestInvoice) por el que el receptor podra pagar de manera segura. A su vez, la informacion relativa a la tran-saccion es almacenada en un libro de cuentas descentralizado. Esto resulta en pagos mas baratos, faciles yseguros, y permite una amplia gama de posibilidades de automatizacion.

Para llegar a ser la columna vertebral del comercio mundial, Request integra un libro de cuentas general,el cual es:- Universal porque esta disenado para sostener el 100 % de las transacciones globales, independientementede la moneda usada, legislacion o idioma. Request esta hecho para perdurar.- Inteligente porque al contrario de otros libros de cuentas existentes, Request se situa en el origen de losintercambios e integra un codigo de comercio computerizado, ası como el manejo de una multitud de condi-ciones de pago.

Al dıa de hoy, su ausencia hace que todo el sistema sea ineficiente y absolutamente no preparado para larevolucion digital y de IoT (Internet de las Cosas) que esta ocurriendo.

Request se puede ver como una capa sobre Ethereum2, que permite la solicitud de pagos cumpliendo conun marco de referencia legal. Tambien es posible ver monedas como herramientas para completar transaccio-nes de Request. En este sentido, Request resulta mas global que cualquier otra moneda.

2. La plataforma

Cualquiera puede escribir en el libro de cuentas de Request (en ingles, Request Ledger) y crear un Requestcomo Pago. Este Request puede ser detectado por el receptor que supervisa la red (mediante una billeterao una aplicacion financiera). Si la solicitud es aceptada por el usuario, el pago se podra realizar con un soloclic. Despues, la solicitud sera completada y la red actualizada.

Cuando una Request es creada, se aplicaran las leyes comerciales pertinentes, ası como los correspondien-tes impuestos a pagar. Si fuese necesario, otros terminos avanzados de contrato podran ser incluidos.

1http://gavwood.com/paper.pdf, 2014, Gavin Wood. Ethereum: a secure decentralised generalised transaction ledger2https://github.com/ethereum/wiki/wiki/White-Paper

2

Bob le esta solicitando un pago a Alice

Veamos dos ejemplos:Bob le pide a Alice un pago. Para ello crea una (factura) Request y envıa esta peticion a la cadena de bloques.La billetera de Alice detecta la Request y procesa el pago.En caso de que Bob estuviese en Amazon y Alice estuviese realizando una compra, Amazon crearıa unaRequest en la cadena de bloques. Como resultado, el telefono de Alice analiza la cadena de bloques, detectala solicitud, envıa una notificacion y aprueba el pago.

Request ofrece:

Seguridad, dado que no es necesario compartir informacion bancaria.

Simplicidad, dado que tan solo requiere un clic.

Ahorro, dado que las compras no precisan de una tercera parte (Ej.: Paypal).

3

Una representacion de un Libro de Cuentas General

Ahora considera un segundo escenario. En este, un coche autonomo se conecta a un garaje inteligentepara comprar una rueda. Ambos negocian mediante un algoritmo y acuerdan un pago con deposito y unagarantıa (el dinero esta bloqueado hasta recibir el producto). Para interactuar financieramente, las maquinasy el IoT requieren un sistema de referencia de pago.

Estos ejemplos no son factibles a dıa de hoy, puesto que no existe un formato estandar ni una interconexionentre servicios. Actualmente, para que esto sea posible habrıa que, o bien compartir informacion bancaria ousar una tercera parte que sea comun a ambas entidades (Ej.: Paypal, Venmo, Lydia, Stripe, . . . ). Todo esto,ademas de ser limitado e inseguro, da lugar a facturas dispersas que pueden contener errores.

La cadena de bloques ofrece el perfecto soporte para crear un sistema de codigo abierto, sostenible, inte-ligente e inmutable.

4

Estas nuevas bases simplifican los flujos electronicos.Hoy, esto es increıblemente importante debido a que todo se reduce a pagos. Mas de 5 trillones de dolares sonintercambiados cada dıa3 tan solo en la red SWIFT, sin embargo, el flujo se encuentra pobremente optimizado.

Esta solucion tiene mayores ventajas. Un libro de cuentas que contenga todas las entradas contables es-tandarizadas puede automatizar la contabilidad en tiempo real, mejorar la auditorıa, automatizar el factorajefinanciero, simplificar reportes de gastos, hacer los depositos en garantıa simples y fiables, y detectar y pagarimpuestos automaticamente.

3https://www.fincen.gov/sites/default/files/shared/Appendix_D.pdf

5

Ademas, abre la oportunidad para una mejora mas amplia del comercio.

Ser capaz de controlar la privacidad de datos permite impulsar la transparencia de las transacciones (atener en cuenta el gasto publico, de asociaciones, etc), mayor equidad (la transparencia hace posible seguirla distribucion de las ganancias y el origen de los productos, ademas de potenciar el comercio justo) y lajusticia (las normas de comercio podran ser alineadas y aplicadas mas facilmente).

Es difıcil imaginar que el mundo financiero pueda avanzar sin esta capa.

6

3. El ecosistema

Multiples desarrollos seran posibles por encima de Request una vez que el equipo haya finalizado el pro-tocolo Central. Nuestro Mapa tecnico mental4 proporciona una imagen completa de Request Network ysu hoja de ruta.

Nosotros creemos que el ecosistema de Request es la clave del exito, por ello queremos potenciarlo. Conel fin de llevar esta descentralizacion adelante y ayudar a Request a escalar, aquı podras encontrar una in-troduccion al Request Hub5. Lo que nosotros llamamos Request Hub es la comunidad fuera de la Requestfoundation, que esta dispuesta a trabajar sobre el protocolo, crear equipos y proyectos sobre Request y ayudarcon su descentralizacion.

3.1. El protocolo Central

La capa inferior es el protocolo central, el cual maneja el consenso sobre el libro de cuentas y la transicionde los estados. Consiste en los contratos inteligentes mas fundamentales, permitiendo la creacion de diferentesentidades y solicitudes de pago. A su vez, detecta cuando los pagos han sido realizados. Esta basado en lainmutabilidad (ej.: nadie puede cambiar la informacion), la apertura de su sistema (todos pueden accedera la informacion que les concierne) y en una inteligencia que le permite saber cuando una factura es pagadade acuerdo con las normas del mismo.

Esta capa tiene lugar en la cadena de bloques de Ethereum, la cual ofrece beneficios endogenos paraEthereum y tokens ERC20, ası como el beneficio de deteccion automatica. Existen otras monedas que, atraves del uso de Oraculos (en ingles, Oracles), tambien detectan pagos de manera automatica.

4https://www.mindmeister.com/991002501?t=R1iofDilV05https://www.mindmeister.com/995302918?t=Y78CuCvpRn

7

Esta capa es gratuita con el fin de fomentar su uso a gran escala y disuadir el desarrollo de otros sistemas.El unico coste necesario es el del uso del gas de Ethereum y el del almacenamiento de informacion.

3.2. Las Extensiones

La segunda capa es la capa de Extensiones. Al dıa de hoy, la mayorıa de solicitudes de pago no son tanbasicas como la propuesta por el protocolo Central. Si la solicitud viene de una empresa entonces se incluyenreglas para el calculo de impuestos, terminos de pago, depositos en garantıa o adelantos. Todas estas condi-ciones se dan en forma de extensiones disponibles que pueden ser anadidas a las solicitudes. Esta capa es lapuerta a increıbles funcionalidades que todavıa no existen, como la de ”facturas contınuas”.Por ejemplo,alguien podrıa elegir este modulo para descomponer el pago de su alquiler en 30x24, permitiendo ası que estapersona tenga una cuenta bancaria con liquidez sin sufrir altos cargos a final de mes. Los impuestos serıanredirigidos en tiempo real a agencias gubernamentales. Con cada pago, el 20 % del IVA se destinarıa a pagarimpuestos y el 80 % restante a pagar a la empresa receptora. El mismo ejemplo permitirıa a cualquier personadar el 1 % de sus pagos a ONGs (Organizaciones no Gubernamentales) o a depositarlas en cuentas de ahorroo jubilacion personales.

Esta capa es facturable, en el sentido de que cada extension tendra una cuota que sera parcialmentequemada y parcialmente transferida a los desarrolladores de la extension, con las extensiones acumuladas enla misma factura. Los costos disminuyen con el tiempo para mantener la competitividad y desalentar otrossistemas alternativos. Se estima que los costes de estas extensiones seran entre el 0.1 % y el 0.5 % inicialmentey, a medida que el sistema crezca, estos seran reducidos. Mas de 5.000 billones de dolares en pagos se realizandiariamente, y al final sera suficiente para financiar la red en menos de un 0,1 %. Sin embargo, los costescontinuaran sosteniendo la seguridad de las aplicaciones y su desarrollo.

Esta capa es completamente abierta, cualquiera puede crear sus propias extensiones en las que los pagospueden ser distribuidos de la manera que mas interese y anime al desarrollador y la comunidad.

8

3.3. Las Aplicaciones

La capa superior es la de Aplicaciones, que tiene lugar fuera de la cadena de bloques. Los sistemas dediversas empresas pueden conectarse a Request para crear solicitudes o acceder a informacion. Contabilidad,auditorıa, impuestos, recuperacion de deudas y sistemas de cobro, factoraje o pago pueden estar conectados.Cuando un pago se conecta a Request (Mycellium, Coincase, Bank of America, Bankin, . . . ), sera posibleacceder a las facturas del usuario y proponer pagarlos de manera instantanea.

Para crear y acceder a solicitudes, el equipo de Request desarrollara aplicaciones que incluiran una interfazy una API.

Aplicacion de ReputacionEn esta capa se incluye un sistema de reputacion con la finalidad de proteger contra la suplantacion de identi-dad (phishing) o los malos pagadores. Por ejemplo, el usuario podra detectar si una empresa esta intentandosuplantar la identidad en caso de que otros usuarios hayan rechazado pagos previamente. Por el contrario,una empresa que no paga sus facturas a tiempo, despues de haberlas aceptado, tambien sera penalizada porsu reputacion. El sistema de reputacion tambien tendra otros usos, por ejemplo, los miembros de la red quetengan mejor reputacion seran capaces de recibir reducciones de costes o acceder a extensiones personalizadas.

La reputacion puede ser directamente anadida a la cadena de bloques, pero para mantener liviano al sis-tema hemos elegido mantener la reputacion en la capa de aplicaciones por ahora, dado que esta informacionse puede obtener examinando la cadena de bloques.

9

4. Casos de uso

Los casos de uso de esta tecnologıa son extremadamente amplios. Este sistema automatiza la contabi-lidad global en tiempo real, reemplaza una rama entera de la auditorıa, elimina la recaudacion manual deimpuestos, simplifica pagos internacionales, permite que maquinas puedan comunicarse en el mismo campofinanciero, reemplaza sistemas de pago como Paypal, y hace que los terminos mas avanzados de pagosean accesibles por todos.

4.1. Facturacion de negocio a negocio (B2B)

Cada ano se comparten billones de facturas entre empresas, la mayorıa en papel o email, teniendo que sercopiados despues. Esto genera un gran numero de errores, particularmente cuando se aplican pagos avanzadoso normas generales sobre impuestos.

Con Request, las empresas pueden compartir estas facturas directamente a traves del libro de cuentas.No habra que realizar mas duplicaciones, dado que los sistemas contables estaran directamente conectados yactualizados.

La empresa que espera el pago sera capaz de detectar un retraso inmediatamente, lo cual sucedera conmenos frecuencia a medida que se desarrolle el sistema de pagos de facturas. La empresa puede pagar en lafecha optima en el momento de recibir la solicitud.

Cada ano, miles de pequenas y medianas empresas quiebran mientras esperan que sus facturas sean pa-gados. El Banco Central Europeo esta planteando soluciones que Request puede completar anadiendo unsistema de reputacion de pago e indicadores clave. Hoy, un proveedor tiene que confiar en su cliente, expo-niendose a no ser pagado. Manana, el proveedor podra verificar la reputacion de su cliente y otros indicadores,como el plazo promedio de pago (en ingles DPO, Days Payable Outstanding) antes de aceptar un contrato.

10

4.2. Pagos online

Por ejemplo, comprar en Amazon requiere de un pago a traves de una tarjeta de credito o debito, por loque se expone informacion personal sensible. Por otro lado, seleccionar el pago a traves de Request protegela informacion del cliente. Amazon le mandara una solicitud a la red que sera detectada y confirmada por lacuenta del usuario. Esto desencadenara una transferencia de bajo coste, sin exponer informacion sobre el pago.

Es posible evitar cargos imprevistos a la tarjeta de credito/debito que son encubiertos por algunos servi-cios. Request le da el control a sus usuarios.

Las ventajas de Request, comparado con los sistemas actuales, son:

Seguridad: la informacion de los pagos nunca es compartida, no existe riesgo de que alguien puedainterceptar y usar informacion bancaria.

Simplicidad: un clic para pagar, sin posibilidad de cometer un error de entrada.

11

Coste: No existe una tercera parte que cobre entre el 1 % y el 7 %, como Paypal6, Bitpay7 o Stripe8.

4.3. Automatizacion de tareas: Contabilidad, Auditorıa, Gastos

4.3.1. Contabilidad

Con Request, la contabilidad se realiza de forma automatica y en tiempo real. Mas alla de la reduccionen costes, esta funcion permite un mejor control financiero, mas eficiente y con mas informacion.

Casos de uso para esta funcion:Request brinda simultaneidad al proceso de contabilidad. Pagos, contabilidad y reembolso de IVA/pagosson realizados automaticamente.

Ademas, representa un cambio de contabilidad de partida doble9 a contabilidad de partida triple10.

6https://www.paypal.com/en/webapps/mpp/paypal-fees7https://bitpay.com/pricing8https://stripe.com/nl/pricing9https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system

10http://iang.org/papers/triple_entry.htmlhttps://en.wikipedia.org/wiki/Momentum_accounting_and_triple-entry_

bookkeeping

12

Esto supone una revolucion esperada por los expertos, que abre algunas preguntas sobre el futuro del valorde auditorıas externas. Una tercera validacion se anade al sistema de contabilidad de partida doble11, y esaquı donde los interventores estan trabajando actualmente para validar la autenticidad de cuentas.

Request permite la digitalizacion de sistemas de contabilidad, donde actualmente se emplea el doblede esfuerzo a traves de documentacion repetitiva y frecuentes comprobaciones. Estas tareas manuales ahorapodran ser automatizadas. Request transformara el trabajo de un CPA en actividades de consulta y apoyo.Este sistema permite mas tiempo para otras tareas de valor anadido, como analisis, estimacion y estrategia.

Tecnicamente, notas de credito, ordenes de compra, reembolsos y cada uno de los conceptos contablesseran posibles con Request. El sistema sera compatible con el estandar UN/EDIFACT y tendra la capacidadde actualizar los ultimos estandares.

4.3.2. Auditorıa

Gracias a la inmutabilidad que brinda Request, realizar auditorıas se convierte en un simple chequeoalgorıtmico. En comparacion, en 2014, Microsoft pago $46.2 millones de dolares en honorarios de auditorıaa Deloitte12. De la misma manera, Bank of America pago cerca de 100 millones de dolares. En total, las 100mayores empresas de Estados Unidos pagaron 2.5 billones de dolares en honorarios de auditorıa.

De ahora en adelante, se podran llevar a cabo auditorıas en tiempo real. A esto lo llamaremos RevisionInteligente13 (en ingles, Smart Audits). Las soluciones de auditorıa en la cadena de bloques (”smart audits”)se convertiran probablemente en una alternativa fiable y economica a las auditorıas manuales actuales.

Request trae significantes beneficios para mejorar la eficiencia de las auditorıas. En terminos de digita-lizacion y software contable, estados y companıas aun estan lejos de ser optimas. Muchas empresas envıanfacturas por email cada dıa y la mayorıa pierde algunos de ellos cada ano.

Sin embargo, las reglas son claras. Los metodos y el soporte tecnologico podrıan cambiarlo todo y sustituirlos costosos controles interempresariales e inter-filiales, que se llevan a cabo para garantizar la fiabilidad delos estados contables.

11https://bitcoinmagazine.com/articles/triple-entry-bookkeeping-bitcoin-1392069656/12http://fortune.com/2015/08/27/microsoft-pays-more-than-apple-for-its-audit-and-why-investors-should-care/13https://request.network/assets/pdf/request_yellowpaper_smart_audits.pdf

13

En la industria de la consultorıa informatica, el coste del tiempo requerido por un contable para procesaruna factura es de entre 5 y 15 dolares. A esta cantidad habrıa que anadirle el tiempo necesario para revisionesy correcciones mensuales. La automatizacion del sistema completo es lenta.

Usar la cadena de bloques con fines contables es una oportunidad de simplificar la cumplimiento y me-jorar el sistema de partida doble. Este sistema data de la epoca del Renacimiento, en la que los gestoresobtenıan ası mayor confianza en sus propios reportes. Hoy en dıa, para justificar esta confianza, interventoresindependientes verifican la informacion de grandes grupos en un proceso que resulta costoso tanto en tiem-po como en dinero. La empresa auditora se convierte entonces en un tercero de confianza que garantiza laveracidad de la informacion establecida en los estados financieros. Sin embargo, los auditores mantienen laresponsabilidad sobre las empresas, lo que genera desconfianza. ¿Los interventores trabajan para los encar-gados de las empresas que las contratan o para las terceras partes que consultan la informacion gratuitamente?

Por lo tanto, en vez de mantener cuentas internas y publicarlas despues de la auditorıa anual, las em-presas pueden mantener cuentas en una base de datos confidencial, compartida y descentralizada usando latecnologıa de cadena de bloques. Todos los asientos contables se inscriben en el registro, sin posibilidad deretroceso, lo que significa que no hay posibilidad de falsificacion. Ademas, serıa mas complicado hacer ajustescontrovertidos al final del ano, y lo que es mas importante, la companıa se beneficia de este sistema en tiemporeal. A su vez, accionistas y terceras partes tambien podrıan tener esta informacion en tiempo real. El costede la auditorıa es insignificante y los asientos contables ya no requieren controles manuales duplicados. Porultimo, la integridad de las declaraciones financieras no volvera a cuestionarse cuando los consumidores y losproveedores esten interconectados con este sistema, al menos a traves de sus direcciones criptograficas.

Request es un registro distribuido que actua como fuente de confianza, permitiendo realizar ‘auditorıasinteligentes’ en tiempo real. Esto incluye todas las compras y ventas de la empresa. En vez de tener cuentasde doble entrada, donde la informacion relativa a una compra aparece en la cuenta de compras y en la cuentadel banco de forma separada; uno puede ver dentro de la cadena de bloques una cuenta de compras, unidaal proveedor, unida al pago, y unida a la cuenta bancaria. Localizable, inmutable y autentica.

Request comprueba la integridad de los registros electronicos guardados. Es la puerta al comercio delfuturo.

14

4.3.3. Gastos

Con Request, los informes de gastos son facilmente compartidos entre trabajadores y empresas, sin termi-nar perdidos o alterados. Un sistema de control de gastos permitira a los trabajadores seleccionar y enviar, entiempo real, sus gastos profesionales a su manager, quien puede aceptarlo y devolverlos cuando sea apropiado.

4.4. Logica de negocio y leyes comerciales - Gobierno e Impuestos

Que los gobiernos soliciten a las companıas informes de todas sus transacciones podrıa dar lugar a erroresy duplicaciones. Request permite a los gobiernos ver de manera especıfica aquellas transacciones a las quetengan acceso en tiempo real.Ademas, el desarrollo de un modulo que grave el IVA, o por ejemplo, un impuesto transatlantico, redirigirael dinero automaticamente.Tanto si uno esta de acuerdo con las polıticas gubernamentales o no, la posibilidad, por primera vez, desimplificar y hacer transparentes los gravamenes de los impuestos es una mejora real.

La tecnologıa de la cadena de bloques permite a las agencias gubernamentales tener la capacidad dedetectar los desequilibrios financieros, el fraude, el lavado de dinero y el crimen financiero por adelantado, yactuar basandose en estas observaciones.

El ala cientıfica del gobierno de Reino Unido ha identificado recientemente diferentes formas en las quela cadena de bloques puede “revolucionar la relacion ciudadano-estado.” Por ejemplo: ayudando al gobiernoa cobrar impuestos y distribuir ayuda.

4.5. Simplificacion de herramientas comerciales: Factoraje, Depositos

Request permitira a empresas y usuarios un acceso facil a diversas herramientas como las de depositoso factoraje. Por ejemplo, permitiendo con un clic elegir pagar solo despues de la entrega de un producto oservicio o asegurar la fianza de un apartamente en deposito, en vez de acreditarlo a la cuenta del dueno.

Simple y sobre todo mas barato. De hecho, el deposito en garantıa puede ser automatizado y basadoen oraculos. En lo referido al factoraje, las companıas seran capaces de usar el mejor sistema descoring de creditos que existe: la reputacion .On Chain”. Asignando una huella unica a cada facturay publicandola en la cadena de bloques, se evitan las dobles facturaciones porque una factura solo puede serescrita una vez en la cadena de bloques. Un contrato inteligente permitira a determinadas companıas cancelarun request para reemplazarlo con un request de doble factoraje.

4.6. Transparencia de las instituciones

La transparencia de los fondos presupuestarios para instituciones (Gobiernos, Municipios, Asociaciones)forma parte de la agenda de la OCDE y del Banco Mundial. Esto incluye:

Rendicion de cuentas: mostrar claridad en cuanto a donde se gastan los fondos es necesario paraque representantes publicos y oficiales sean responsables por su efectividad y eficiencia.

Integridad: la transparencia es la mejor de las polıticas para prevenir la corrupcion y mantener altosestandares de integridad en el uso de fondos publicos.

Inclusividad: la transparencia invita a un debate informado e inclusivo sobre los impactos de la polıticapresupuestaria.

15

Confianza: estamos en la era de los proyectos de fuente abierta y colaboracion. La transparenciafomenta la confianza en una sociedad donde las opiniones e intereses de las personas son respetadas ydonde el dinero publico se usa de manera apropiada.

Calidad: la revision del presupuesto, como revision del codigo, permite detectar el desperdicio y eluso indebido y brinda informacion sobre como mejorar el resultado para obtener mas capacidad derespuesta e impacto.

Request propone un marco que permite a estas instituciones adoptar la transparencia de la forma masconveniente, con el objetivo de publicar sus cuentas en tiempo real y permitir que cualquiera pueda auditar yutilizar estos datos. A medida que la infraestructura gane en popularidad, se desarrollaran mas herramientaspara que, por ejemplo, nos den un registro sobre los gastos de nuestra ciudad.

Esta transparencia puede aplicarse a otras industrias y puede ayudarnos a identificar el origen de algunosproductos y la cantidad de intermediarios implicados.

4.7. IoT y contratos inteligente

Un reto apasionante de los proximos anos seguramente sera imaginar como objetos, maquinas e inteli-gencias artificiales se relacionaran entre sı, y como negociaran y definiran automaticamente los terminos depago. Necesitaran una infraestructura de pagos que especifique los mismos y ayude a definir las razones ycondiciones de la transaccion.

De esta manera, uno puede empezar a imaginar a un coche autonomo pidiendo una ruedanueva a un garaje virtual, dar un anticipo y pagar el 90 % restante tras la entrega.

5. Token

Pese a estar construido sobre la cadena de bloques de Ethereum, Request pretende ser independiente deotras monedas, de polıticas monetarias o de decisiones tecnologicas para construir un sistema lo mas robustoposible. Creemos que la clave para el desarrollo a largo plazo es con una comunidad creciente y con el desa-rrollo de una infraestructura donde muchas DAPP (aplicaciones descentralizadas) puedan ser creadas.

5.1. Incentivo para asegurar el ecosistema de las aplicaciones

Los tokens ERC20 de Request son necesarios para participar en la red, crear peticiones avanzadas e incen-tivar a sujetos que ayudaran a construir el ecosistema de Request. Al usar la red, los participantes deberanpagar una tarifa de red en REQ que se quemara. Las tarifas seran ajustadas por los operadores de la Re-quest Network en funcion del suministro decreciente de REQ y el tipo de cambio con las diferentes monedasautorizadas por la red.

Como ejemplo, una solicitud al comienzo del sistema podrıa quemar 10 REQ del suministro total de1.000.000.000 de REQ. Mas tarde, despues de que el sistema se haya utilizado por un tiempo, una solicitudpodrıa quemar 0,0001 REQ de un suministro total de 100.000 REQ.

La red tendra un sistema integrado para recompensar a las plataformas que usen el protocolo y decidancobrar una tarifa en REQ. De esta manera favorecemos la creacion de toda una plataforma financiera abierta.

Los costos que esperamos en la plataforma son del 0.05 % al 0.5 % de la transaccion. Estos costos dismi-nuiran con el tiempo cuando el volumen de la red aumente para seguir siendo competitivos y evitar incentivarel desarrollo de alternativas. Con un mercado mundial en el que transitan mas de 5.000 billones de dolares

16

al dıa, las tarifas mınimas seran mas que suficiente una vez la plataforma crezca a mayor escala.

5.2. Gobernanza

Creemos firmemente en la construccion de un sistema (Request) que dure decadas o incluso siglos. Unsistema que no solo pueda ser usado por historiadores para ver como era el comercio en el sigloXXI, sino tambien un sistema que nos lleve al futuro, con el poder y la estructura necesaria para ser usadacuando las maquinas artificiales e inteligentes lleven a cabo la mayorıa de las transaccionesPor esta razon, Request tendra que mantenerse flexible y escalable, siendo este uno de los mayores retos de lossistemas descentralizados (como podemos ver con Bitcoin14 Segwit, o la gestion de Ethereum con Casper. . . ).Nos gustarıa separar la gobernanza de nuestra comunidad de la de Ethereum para evitar una sub-gobernanzaque permitirıa a todos los propietarios de Ethereum decidir sobre el futuro de esta comunidad15.

El token de Request unira a la comunidad y permitira el debate y las votaciones de futuras decisiones.La comunidad sera una sociedad y crearemos las herramientas necesarias para su administracion. Sera unsistema de votacion, pero tambien un sistema de comunicacion restringido solo a miembros de la sociedad.

5.3. Independencia de otras monedas

En terminos de divisas, Request es agnostica. Estamos creando un sistema que no deberıa ser dependientede ninguna polıtica monetaria. Request deberıa ser lo mas independiente posible de la inflacion o deflacion deETH. La hoja de ruta de Ethereum apoya nuestra direccion, es muy probable que los mineros/stakers puedanactualizarse a Casper para aceptar otros tokens ERC20 como gas, lo que supondra una gran simplificacion.

Eventualmente, esta independencia le permitira a Request realizar un hard fork (bifurcacion) a un nuevosistema con una nueva tecnologıa manteniendo el mismo ecosistema.

5.4. Independencia tecnica

En el proceso de escalabilidad de Request Network, existe una gran probabilidad de que utilicemos unasolucion como Plasma (en ingles, Plasma Chains). En estas condiciones, un token especıfico ayuda a incenti-var la evasion de estados Bizantinos (en ingles Byzantine16 states), y maximizar la seguridad. El token se usacomo un POS (Prueba de Participacion o Proof of Stake) y los stakers son desincentivados contra conductaso fallas Bizantinas, ya que eso causarıa una perdida en el valor del token.Usar un token es la forma mas flexible e independiente de conceptualizar un sistema que necesitara consensoy seguridad para evolucionar a largo plazo17.

5.5. Facilitar el intercambio de diferentes monedas

Propondremos un modelo donde el sistema pueda identificar automaticamente los bucles de facturas yliquidarlos sin necesidad de un cambio de fondos. Por ejemplo, si Alice le debe dinero a Bob, que a su vez ledebe dinero a Charlie quien a su vez recibe un request de pago de Alice, el sistema puede ofrecer compensa-cion por estas facturas y REQ liquidara las diferencias compensatorias.

14https://bitcoin.org/bitcoin.pdf, 2008, Satoshi Nakamoto15https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1, 06/27/2017, Fred Ehrsam16http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf, 2016, Christopher Copeland and Hong-

xia Zhong17http://plasma.io/plasma.pdf

17

6. Borrador del Roadmap (Programa)

Siendo terminado. La hoja de ruta detallada sera publicada aquı una vez lista.

Request Pyramid: Q3 2017-Publicacion del borrador final del whitepaper.-Lanzamiento de la web de Request Network.

Request Colossus: Q4 2017-Lanzamiento del token.-Primera version de Request funcionando con Ethereum en la Test Net (red de pruebas).-Implementacion de la web para Crear/Visualizar e interactuar con Requests.-Anadir a Request la gestion de conceptos contables como devolucion, nota de credito y ordenes de compra.-Lanzar la API para crear/leer/actualizar Requests.-Publicar los papeles tecnicos sobre arquitectura, actualizaciones e implementacion de contabilidad.

Request Great Wall: Q1 2018-Primera version de Request funcionando con Ethereum en la Red Principal (en ingles, Main Net).-Prueba de concepto (POC): Request Core trabajando con un Oraculo (Oracle) de Bitcoin.-Lanzamiento del manejo de criptomonedas en Request (ERC20 tokens. . . ).-Lograr alianzas con firmas de contabilidad, pagos y auditorıas.-Lanzar el proyecto “Pagar con Request”: un boton online que ofrece la alternativa al tradicional “Pagar conPaypal” y “Pagar con tarjeta de credito”.-Auditorıas externas de los Request Contracts.

Request Stonehenge: Q2 2018-POC para escalar Request a traves de la cadena de Plasma con PoS (Proof of Stake). Request tendra quemanejar un monton de transacciones.-POC para incrementar la seguridad de Request usando ZkSnarks18.-Anadir el manejo de monedas nacionales a Request (USD, EUR, CNY. . . ).-Lanzamiento del proyecto “Request and Transparencia”. Trabajaremos con ayuntamientos, asociaciones ygobiernos para publicar en tiempo real informacion sobre sus presupuestos.-Organizar grupos de discusion sobre pagos con Request con diversas instituciones como el Banco Mun-dial/FMI/BCE y la ONU.

Request Colosseum: Q3 2018-Lanzamiento de la extension de “Deposito” que permite la liberacion de fondos en el momento de la entregao una vez satisfechas otras condiciones.-Lanzamiento de la extension “Impuestos” para pagar impuestos en tiempo real.-Lanzamiento de la extension “Pago Inicial” para especificar una cantidad a pagar y una fecha especıfica paraprocesar el pago.-Lanzamiento de la extension “Cargo de Demora” para precisar multas si un trabajo no se paga a tiempo.-Anadir una capa Offchain (fuera de la cadena) de Reputacion.

Request Petra: Q4 2018 y mas alla-Lanzamiento del sistema de gobernanza (Votar/Token chat).-Lanzamiento del proyecto “infraestructura del Internet de las Cosas”.-Lanzamiento de acuerdos entre monedas a traves de REQ para facilitar los pagos internacionales.-Lanzamiento de la extension “Pago Continuado” que actuara como un “Pago por adelantado” con multitudde micropagos.

18https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6, 2017, Vitalik Buterin

18

7. Equipo

7.1. Equipo principal

Nuestro equipo es nuestro activo mas importante en el proyecto de Request. Todos sus miembros hantrabajado juntos en el pasado, entre 6 meses y 6 anos. Somos “hacedores” (doers, en ingles). Nuestra expe-riencia en finanzas, cadena de bloques (blockchain) y espıritu emprendedor se combinan para replantear laorganizacion del comercio internacional del manana.

¿Quienes somos?

Entre las funciones de nuestro equipo se encuentran las de: director financiero, gerente de IT, auditor fi-nanciero, contador, controlador de gestion, tesorero, analista de datos, desarrollador front-end, desarrolladorback-end, desarrollador principal y desarrollador blockchain. Estos roles han abarcado industrias que incluyenconsultorıa, finanzas, farmaceutica, musica, investigacion y fintech.Pensamos en terminos de la cadena de bloques, fintech y finanzas, y creemos que existen alternativas muchomas transparentes y saludables a la forma en que los bancos operan actualmente. Nuestra experiencia enel accelerator del banco ING en Amsterdam, el Lisbon Challenge en Portugal y el YCombinator en SiliconValley, ası como nuestras experiencias personales en China, Estados Unidos, Suiza y Mexico, reflejan nues-tro espıritu y modo de pensar internacional. Creemos en la libertad de moverse, trabajar de forma remotay trabajar libremente, no solo para individuos y empresas, sino tambien para maquinas, dinero e informacion.

¿Por que Request?En el primer trimestre de 2017, el equipo participo en el YCombinator de San Francisco. Los muchos in-tercambios que tuvimos con las mayores startups del manana y los mejores inversores en Silicon Valleyconfirmaron la idea de que la cadena de bloques (blockchain) es el mejor medio para construir las bases parael comercio internacional. Mientras que los servicios de hoy luchan por resolver los problemas de los bancos ylas administraciones, el blockchain trae una solucion al origen. Con Request, el problema de los pagos localese internacionales casi no existe, se simplifica y se automatiza.

¿Cuando comenzo?En 2014, el equipo estaba trabajando en la construccion de una red de transferencias internacionales basadaen bitcoin, Moneytis, la cual fue gradualmente convirtiendose en una red de pagos global que agrupaba solu-ciones para transferencias de dinero y permitıa transferencias internacionales de millones de dolares. Desde2014 a 2017, el equipo desarrollo destinesia.io, theblockchainnetwork.com, neomy.io y moneytis.com. Nuestrainvestigacion sobre la escalabilidad y liquidez de una solucion blockchain para transferencias de dinero fuefructıfera cuando aprendimos mas de usuarios, empresas, autonomos e individuos.

Presentacion de los miembros del equipo:

Etienne Tatur, CTOEtienne es un entusiasta de la cadena de bloques que se graduo en la escuela de ingenierıa francesa INSA enLyon. Contrato a Christophe en Amaris en abril de 2011 en Geneva (Suiza), donde el era el desarrolladorprincipal y manager de proyectos IT. Fue allı donde compartio su pasion por la cadena de bloques, antes deconvertirse en el CTO. Despues de su experiencia con Qobuz (startup de musica), en 2014, creo su primerproyecto de blockchain “Snapsoko”, que mas tarde cambio el nombre a The Blockchain Network, el cualestaba integrado dentro del proyecto Moneytis. Es tambien el creador del Messenger Bot Neomy.io.Ha dado conferencias sobre las conexiones entre la cadena de bloque y las transferencias de dinero en Miamipara al Money Transfer Conference, y en Parıs para la Blockchain France and Visa Europe.Nuestro experto en tecnologıa se interesa por las nuevas tecnologıas, la fotografıa y la escalada. Es miembrode La Chaintech. Cree que la cadena de bloques cambiara el mundo.

Christophe Lassuyt, CFOChristophe Lassuyt tiene experiencia como manager financiero internacional por todo Norte America, Euro-pa y Asia. Despues de graduarse en la Escuela de Negocios (NEOMA Business School), comenzo a trabajar

19

como supervisor de la administracion de equipos, antes de convertirse en director financiero internacional deAmaris y Virtua. Es miembro del movimiento Mangrove. Cree que trabajar y viajar al mismo tiempo es muyefectivo.Cuando comenzo como CFO, Christophe llevaba personalmente todas las lıneas de negocios para una filial deAmaris en Munich, Alemania, la cual incluıa la contabilidad de clientes; proveedores; recaudacion; auditorıasinternas; contactos con auditorıas externas; control de auditorıas de impuestos; control de direccion y otros.Sus conocimientos incluyen el tiempo de procesamiento de una factura, los problemas de factoraje, y su mayorlogro es haber logrado automatizar estas transacciones en las companıas donde ha trabajado, con un ratiode una persona en finanzas por cada 300 empleados.Esta interesado en los problemas asociados con el pago de facturas. Por ejemplo, imaginemos que un admi-nistrativo recibe una factura por email, la cual es aprobada por el manager, y luego es enviada al contable.El contable debe incluirla en un programa de software, antes de gestionar el pago, lo cual tambien debe servalidado por el manager. Este proceso es innecesariamente largo, mientras que el dıa de manana, con Request,podrıamos recibir la misma factura a traves del telefono, y con un unico clic de sı/no el pago se llevarıa acabo de forma automatica en la fecha de vencimiento.

Vincent Rolland, Ingeniero Back-end, desarrollador de SolidityVincent se graduo en la prestigiosa escuela francesa de Lyon INSA con experiencia en investigacion y trabajopara el CNRS en asociacion con la Universidad de Stanford. Tambien ha colaborado en proyectos cientıficosen el Museo de Historia Natural de Parıs. Despues de esto, se unio a Moneytis, un proyecto de pagos inter-nacionales en la cadena de bloques, y tambien ha mejorado el proyecto neomy.io desde el punto de vista dela investigacion y el desarrollo, haciendolo autonomo. Vincent se esfuerza por traer transparencia y valores alos proyectos en los que trabaja. Request es la solucion definitiva para traer transparencia a un nivel global.

Elliott Denis, Ingeniero Full StackElliott es un desarrollador full-stack con experiencia en asesorıa y empresas tecnologicas. Trabaja escribiendocodigo de forma limpia, elegante y efectiva utilizando las mas modernas tecnologıas. Descubrio Ethereum porprimera vez en 2016 y desde entonces no ha dejado de pensar en la amplitud de sus aplicaciones. Primerocon Moneytis y luego con Request, cree que puede traer simplicidad y transparencia al comercio mundial delmanana.

Laura Girod, Interventora Financiera y Analista de DatosGraduado en la Escuela de Negocios ICN, Laura desempenaba una labor como auditora interna, interven-tora financiera, analista de datos, e incluso atencion al cliente. Domina los ecosistemas de la consultorıa yauditorıa, y paso varios anos en una empresa internacional en Suiza y Asia, antes de unirse Moneytis enDiciembre de 2015Gracias a sus habilidades en estadıstica y modelaje, Laura creo el algoritmo neomy.io.

Julien Devoir, CMO HipsterJulien tiene una extensa experiencia en el marketing de crecimiento y diseno grafico. Participo en YCombi-nator con Moneytis. Es uno de los primeros miembros del movimiento Mangrove. Julien se educo a sı mismoen marketing digital y nuevas tecnologıas. Su pasion por internet le llevo a convertirse en Growth Hacker enVirtua (Suiza) y en Molotov.tv (Francia).Segun el, trabajar y viajar a la vez aumenta la productividad. Tambien cree que viajando se aprende a sermas profesional y ha fomentado esto co-fundando el proyecto de vida destinesia.io.

8. Arquitectura

Pronto publicaremos el Yellow Paper detallando las especificaciones tecnicas. Este texto dara algunaspistas sobre los retos que afrontamos y la arquitectura que elegimos.

Request es un protocolo de servicio en el cual se van a basar diferentes aplicaciones, que aspira a nodepender de servidores, a ser de codigo abierto y a ser descentralizado. Para lograr este objetivo, tomamos

20

la decision de construir Request con la tecnologıa Ethereum.

Ethereum: Ethereum permite la ejecucion de Contratos Inteligentes de forma descentralizada a travesde EVM, lo que permite a Request ser descentralizado y sin servidores. Los contratos inteligentes de Requestestan creados con Solidity. Request utiliza Ethereum para crear facturas y automaticamente detectar su pago.

Swarm & Filecoin: Swarm19 y Filecoin20 permiten que el almacenamiento de documentos sea descen-tralizado y en una red distribuida. Filecoin almacenara la informacion mas grande en facturas y Swarm seencargara de aquella informacion a la que deba accederse de una forma mas rapida, como algunos metadatos.

8.1. Consideraciones Tecnicas

Polıticas de privacidadGestionar la confidencialidad y privacidad en Ethereum es uno de los retos y prioridades del protocolo deEthereum. El uso de ZkSnark21 (Zero Knowledge succinct non-interactive arguments of knowledge) abordaesta cuestion. ZkSnarks es parte de la hoja de ruta de Ethereum pero no sera inmediato.Hasta que se lance ZkSnarks u otra solucion, trabajaremos en tres rutas:-Permitir requests publicos.-Introducir el concepto de Request Basico. Un tipo de Request que no sera un contrato inteligente sino unresumen criptografico en Filecoin.-Cadena de Plasma. La cadena de Plasma permitira el uso de ZkSnark y estamos siguiendo de cerca el trabajode Omise para trabajar en ellos.-Eventualmente se utilizara una cadena lateral temporal con Quorum22 y transacciones privadas conectadasa la publica a traves de un sistema como Polkadot23.

Escalabilidad La escalabilidad es otro reto que afronta la cadena de bloques, y no hay duda de quequeremos tener el mayor numero de transacciones posibles. El hecho de que podamos manejar varias mo-nedas hara que el numero de transacciones en Request crezca mas rapido que el numero de transaccionesen Ethereum. Esto es porque algunas innovaciones en la hoja de ruta de Ethereum seran importantes paraRequest, como Sharding24.

Sharding todavıa esta lejos, ası que nos centraremos en-descargar la mayorıa del off chain en Plasma / State-channels25.-Request basicos para pequenas cantidades, que no seran contratos inteligente, agregados a Filecoin y Swarm.

19https://github.com/ethersphere/swarm, 03/22/201720https://filecoin.io/filecoin.pdf, 08/04/2017, Protocol Labs21https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/, 12/05/2016, Christian Reitwiessner22https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf, 11/22/201623https://github.com/w3f/polkadot-white-paper/, 11/10/2016, Dr. Gavin Wood24https://github.com/ethereum/wiki/wiki/Sharding-FAQ, Vitalik Buterin. Ethereum Sharding FAQ25https://raiden.network/, Raiden. Raiden Network

21

8.2. Arquitectura de los contratos inteligentes

Vista de alto nivel de los contratos inteligentes. El nucleo registra todos los Requests y es administrable, loque permite actualizarlo y detenerlo. Solo hay un nucleo, que puede permitir subcontratos para gestionar

diferentes monedas. Cada subcontrato gestiona la creacion e interaccion con el request de la monedaespecıfica. Algunos subcontratos estan sincronizados, mientras otros interactuan con un oraculo (por

ejemplo para monedas nacionales)

22

Aquı hay detalles del actual subcontrato. El subcontrato interactua con diferentes extensiones que pueden serelegidas por el creador de la solicitud.

9. Agradecimientos

Nos gustarıa agradecer a ciertos seguidores, cuyas contribuciones y feedback han hecho este documentoposible o nos han ayudado en diferentes partes del proyecto:Nadja Benes - GnosisAntoine Grebert - QuandooYoann Marion - AmarisAndria Antoniou - PhD at PiGPierre Laurent - Blockchain enthusiastaChristopher BarryMarta - traduccion al espanolMatıas Puletti - traduccion al espanol

23

10. Bibliografıa

1. http://gavwood.com/paper.pdf, 2014, Gavin Wood. Ethereum: a secure decentralised generalisedtransaction ledger

2. https://github.com/ethereum/wiki/wiki/White-Paper

3. https://www.fincen.gov/sites/default/files/shared/Appendix_D.pdf

4. https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Double-entry_bookkeeping_system.html, 11/25/2016

5. http://iang.org/papers/triple_entry.html, 2005, Ian Grigg

6. http://ww2.cfo.com/expense-management/2015/06/metric-month-accounts-payable-process-cost/,06/24/2015, Mary Driscoll

7. https://bitcoin.org/bitcoin.pdf, 2008, Satoshi Nakamoto

8. https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1, 06/27/2017,Fred Ehrsam

9. http://www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf, 2016, Christop-her Copeland and Hongxia Zhong

10. https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6,2017, VitalikButerin

11. https://github.com/ethersphere/swarm, 03/22/2017

12. https://filecoin.io/filecoin.pdf, 08/04/2017, Protocol Labs

13. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell, 12/05/2016, Christian Reit-wiessner

14. https://github.com/jpmorganchase/quorum-docs/blob/master/Quorum%20Whitepaper%20v0.1.pdf, 11/22/2016

15. https://github.com/w3f/polkadot-white-paper/, 11/10/2016, Dr. Gavin Wood

16. https://github.com/ethereum/wiki/wiki/Sharding-FAQ

17. https://raiden.network/

24