Adiciona documentação do Rayls.

README.md

@@ -10,3 +10,4 @@ Este repositório contém as informações necessárias para a participação no
 * [Exemplos de interação com os smart contracts](exemplos/README.md)
 * [Privacidade - Anonymous Zether](AnonymousZether.md)
 * [Privacidade - Starlight](Starlight.md)
+* [Privacidade - Rayls](Rayls.md)

docs/RaylsArquitetura.md

@@ -0,0 +1,31 @@
+# Infraestrutura topológica 
+
+O esquema ilustrativo, a seguir, demonstra como uma Privacy Ledger de propriedade de uma única instituição é composta, e como ela se relaciona com a Commit Chain: 
+
+<p align="center">
+    <a href="" rel="noopener">
+        <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/Raylz-e-Commit-Chain+(1).png" alt="Rayls">
+    </a>
+    <p align="center">
+        <span>Figura - Estrutura de uma Privacy Ledger e sua relação com a Commit Chain</span>
+    </p>
+</p>
+
+Como podemos observar, na ilustração acima, os contratos inteligentes podem existir tanto na Privacy Ledger quanto na Commit Chain, sendo elas blockchains distintas e funcionais. A comunicação entre PL e Commit Chain se dará através da figura do Relayer, que é um serviço que realiza escuta ativa de eventos que ocorrem na respectiva PL e propaga tais eventos à(s) blockchain(s) interessada(s), de forma criptografada e, privada. Ou seja, toda e qualquer mensagem que trafega pela Private Subnet através da Commit Chain será confidencial e poderá ser acessível apenas pelas partes autorizadas (terceiros participantes da rede não terão acesso às respectivas trocas de mensagem). 
+
+Em suma, pode-se dizer que a arquitetura da Private Subnet foi construída de forma a garantir que: 
+
+- Tudo o que ocorre dentro de uma PL é privado, e somente os administradores da respectiva PL poderão autorizar acesso a ela; 
+
+- Os contratos inteligentes e protocolos podem ser executados tanto nas PLs quanto na Commit Chain, a depender dos papéis de cada ator na Private Subnet; 
+
+- A comunicação entre PLs se dará por intermédio da Commit Chain, protegida por criptografia de ponta a ponta; 
+
+Para mais informações, acesse:
+
+- [Site oficial Parfin](https://parfin.io/rayls)
+- [Repositório de Setup da Rayls](https://github.com/raylsnetwork/piloto_rd_setup)
+
+<br>
+
+[<<< Voltar](../Rayls.md)

docs/RaylsAtacadoCBDC.md

@@ -0,0 +1,77 @@
+# CBDC (atacado):
+
+- [ex1-requisitar-emissao-cbdc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex1-requisitar-emissao-cbdc.ts): faz uma soliticação de emissão de novos CBDC para receber em uma conta.
+
+  <strong>Pré-requisitos:</strong> 
+
+  1. Antes de mais nada, os contratos da instituição precisam estar implantados no ambiente do participante com a execução do código [setup-participant-contracts.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/setup/setup-participant-contracts.ts).
+
+- [ex2-transferir-cbdc-atacado.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex2-transferir-cbdc-atacado.ts): a partir da instituição de origem, envia Real Digital para uma segunda instituição de destino (atacado).
+
+  <strong>Pré-requisitos:</strong> 
+
+  1. Na origem, o endereço que deseja iniciar a transferência necessita de saldo, portanto, é interessante que o respectivo endereço tenha recebido saldo, por exemplo, através da execução do script [ex1-requisitar-emissao-cbdc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex1-requisitar-emissao-cbdc.ts);
+
+  2. No destino, o endereço destinatário precisa estar autorizado, via allowlist, na PL da instituição de destino, a receber CDBC. Caso o endereço não tenha autorização, basta que os administradores da PL de destino tenham executado o código [opcional_add-conta-allowlist-cdbc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/opcional_add-conta-allowlist-cdbc.ts) para autorizar uma conta a receber CDBC na respectiva PL.
+
+- [ex3-reversao-transferencia-cbdc-atacado.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex3-reversao-transferencia-cbdc-atacado.ts): tenta realizar o envio de Real Digital para uma conta não autorizada, mas tem o envio revertido devido à não autorização - ocorre que apenas endereços de contas autorizadas podem receber CDBC.
+
+  <strong>Pré-requisitos:</strong> 
+
+  1. Na origem, o endereço que deseja iniciar a transferência necessita de saldo, portanto, é interessante que o respectivo endereço tenha recebido saldo, por exemplo, através da execução do script [ex1-requisitar-emissao-cbdc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex1-requisitar-emissao-cbdc.ts);
+
+  2. Caso o endereço de destino esteja autorizado a receber CDBCs, no caso deste exemplo, é necessário desautorizar o endereço de destino, através da execução do código [opcional_remove-conta-allowlist-cdbc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/opcional_remove-conta-allowlist-cdbc.ts): desautoriza uma conta a receber CDBC.
+
+<br/>
+<br/>
+<br/>
+
+## Diagramas de Sequência
+
+<p align="center">
+  <a href="" rel="noopener">
+    <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/1-requestToMint.drawio.png" alt="Project logo">
+  </a>
+  <p align="center">
+    <span>Exemplo 1 - Requisição para emissão de novos Reais Digitais (CDBC)</span>
+  </p>
+</p>
+</br>
+</br>
+
+<p align="center">
+  <a href="" rel="noopener">
+    <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/2-CBDC-Allowlist.drawio.png" alt="Project logo">
+  </a>
+  <p align="center">
+    <span>Opcional - Fluxos de adição, remoção e checagem para uma conta receber, ou não, Real Dgital (CDBC)</span>
+  </p>
+</p>
+</br>
+</br>
+
+<p align="center">
+  <a href="" rel="noopener">
+    <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/3-STR0004.drawio.png" alt="Project logo">
+  </a>
+  <p align="center">
+    <span>Exemplo 2 - Envio de Real Digital entre instituições financeiras (atacado)</span>
+  </p>
+</p>
+</br>
+</br>
+
+<p align="center">
+  <a href="" rel="noopener">
+    <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/4-STR0004-Revers%C3%A3o-At%C3%B4mica.drawio.png" alt="Project logo">
+  </a>
+  <p align="center">
+    <span>Exemplo 3 - Reversão de envio de Real Digital devido a permissionamento inválido</span>
+  </p>
+</p>
+</br>
+</br>
+
+<br>
+
+[<<< Voltar](../Rayls.md)

docs/RaylsCasosdeUsoDREX.md

@@ -0,0 +1,32 @@
+# Casos de Teste e Contratos Inteligentes 
+
+Os contratos inteligentes desenvolvidos implementam o Real Digital (DREX) como um token ERC20 e o Título Público Federal Tokenizado (TPFt) como um token ERC1155, ambos registrados via Commit Chain e com capacidades de envio e recebimento de mensagens cross-chain dentro da VEN. Ainda, o token Real Tokenizado também foi implementado seguindo o padrão ERC20, todavia, sem a necessidade de ser registrado via Commit Chain, existindo somente nas PLs de cada um dos participantes.  
+
+O caso de testes requestToMint foi implementado de forma que a PL do BACEN seja responsável por autorizar tais ações de emissão de novos DREX.  
+
+Já o caso de teste STR0004 (Transferência de Real Digital entre Participantes) focou em demonstrar como transações de DREX entre diferentes IFs podem ser feitos de forma atômica e garantindo confidencialidade entre as s IFs.  
+
+O caso de teste STR0008 (equivalente ao Swap One Step) focou em demonstrar como é possível que clientes de diferentes IFs participantes podem transacionar entre si.  
+
+Já os casos de testes com TPFt e DVP foram feitos de forma a permitir que a emissão de Títulos Públicos e posterior comercialização de tais títulos, tanto entre instituições apenas, quanto entre clientes de instituições.  
+
+Foram criados os seguintes contratos inteligentes:  
+
+- CDBC.sol: contrato que representa o Real Digital;  
+
+- TPFt.sol: contrato que representa o Título Público Federal Tokenizado;  
+
+- RealTokenizado: contrato que representa reais tokenizados existentes dentro de uma IF;  
+
+- STR.sol: contrato utilizado para que o BACEN receba e processe mensagens para emissão de novos DREX;  
+
+- TPFToperation.sol: contrato utilizado por participantes para registrarem, liquidarem e/ou reverterem operações de DVP;  
+
+- DVP.sol: contrato existente na PL da SELIC cujo objetivo é conciliar e servir como ponto de liquidação de operações de DVP.  
+
+Ainda, foram desenvolvidos os scripts de setup que cada PL deve executar quando do seu ingresso na VEN. Por fim, foram escritos e executados os casos de teste para os requisitos solicitados.  
+
+
+<br>
+
+[<<< Voltar](../Rayls.md)

docs/RaylsDVPEntreClientes.md

@@ -0,0 +1,76 @@
+# Delivery versus Payment entre Clientes de Instituições Financeiras:
+
+É importante observar os <strong>pré-requisitos</strong> pois, apesar de alguns scripts poderem se executados "fora de ordem", devemos notar que os scripts de registro de operações de DVP devem preceder a execução dos scripts de liquidação das respectivas operações, como já mencionado anteriormente nesta documencação.
+
+- [ex11-transferir-tpft-entre-wd-e-cliente.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex11-transferir-tpft-entre-wd-e-cliente.ts): realiza a transferência de Título Público Federal Tokenizado entre contas de uma mesma instituição financeira;
+
+  <strong>Pré-requisitos:</strong>
+
+  1. O endereço da conta que deseja realizar a venda necessita de saldo de TPFt. Para tanto é preciso que uma solicitação off-chain seja feita à SELIC para que, então, a SELIC envie os TPFt solicitados à respectiva conta do vendedor
+
+- [ex12-dvp-cliente-registro-vendedor.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex12-dvp-cliente-registro-vendedor.ts): realiza o lançamento (registro) de uma operação de DVP com Título Público Federal Tokenizado enquanto vendedor do ativo (entre clientes de instituições financeiras);
+
+    <strong>Pré-requisitos:</strong>
+
+    1. Antes de mais nada, os contratos da instituição precisam estar implantados no ambiente do participante com a execução do código [setup-participant-contracts.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/setup/setup-participant-contracts.ts);
+
+    2. O endereço do cliente que deseja registrar a operação de venda deve possuir saldo de TPFt. Para tanto, é preciso que o script [ex11-transferir-tpft-entre-wd-e-cliente.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex11-transferir-tpft-entre-wd-e-cliente.ts) tenha sido executado previamente;
+
+    3. É necessário conhecer os metadados do TPFt (`TPFtData`), a saber: `acronym`, do tipo `string`; `code`, do tipo `string` e; `maturityDate` do tipo `uint256`;
+
+    4. É necessário conhecer dados da operação, a saber: os Chain Ids das partes envolvidas; os endereços das contas envolvidas; os metadados (`TPFtData`) do título negociado; a quantidade (`tpftAmount`) de títulos negociados; o preço (`price`) a ser pago por unidade de TPFt; o estado inicial (`status` - 1 p/ vendedor) da operação e; a informação de confirmação de que a operação será realizada entre duas clientes de instituições (`isBetweenClients` = `true`).
+
+- [ex13-dvp-cliente-registro-comprador.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex13-dvp-cliente-registro-comprador.ts): realiza o lançamento (registro) de uma operação de DVP com Título Público Federal Tokenizado enquanto comprador do ativo (entre clientes de instituições financeiras); 
+
+    <strong>Pré-requisitos:</strong>
+
+    1. Antes de mais nada, os contratos da instituição precisam estar implantados no ambiente do participante com a execução do código [setup-participant-contracts.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/setup/setup-participant-contracts.ts);
+
+    2. O endereço da de reservas da instituição de onde está partindo o registro de compra necessita de saldo de CBDC. Para tanto é preciso ter executado o script [ex1-requisitar-emissao-cbdc.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex1-requisitar-emissao-cbdc.ts) previamente. Também é necessário que a conta do cliente comprador possua saldo de Real Tokenizado;
+
+    3. É necessário conhecer os metadados do TPFt (`TPFtData`), a saber: `acronym`, do tipo `string`; `code`, do tipo `string` e; `maturityDate` do tipo `uint256`;
+
+    4. É necessário conhecer dados da operação, a saber: os Chain Ids das partes envolvidas; os endereços das contas envolvidas; os metadados (`TPFtData`) do título negociado; a quantidade (`tpftAmount`) de títulos negociados; o preço (`price`) a ser pago por unidade de TPFt; o estado inicial (`status` - 2 p/ comprador) da operação e; a informação de confirmação de que a operação será realizada entre duas clientes de instituições (`isBetweenClients` = `true`).
+
+- [ex14-dvp-cliente-liquidacao-vendedor.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex14-dvp-cliente-liquidacao-vendedor.ts): realiza o resgate de uma operação de DVP com Título Público Federal Tokenizado enquanto vendedor do ativo (entre clientes de instituições financeiras); 
+
+  <strong>Pré-requisitos:</strong>
+
+  1. Para que o cliente receba seu pagamento via RealTokenizado, o endereço do contrato CBDC precisa estar autorizado a emitir e queimar tokens do contrato RealTokenizado. Dito isso, antes de executar este exemplo, é preciso ter executado o script [setup-participant-rt.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/setup/setup-participant-rt.ts);
+
+  2. É necessário ter executado o código [ex12-dvp-cliente-registro-vendedor.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex12-dvp-cliente-registro-vendedor.ts) previamente;
+
+  3. É necessário conhecer os metadados do TPFt (`TPFtData`), a saber: `acronym`, do tipo `string`; `code`, do tipo `string` e; `maturityDate` do tipo `uint256`;
+
+  4. É necessário conhecer dados da operação, a saber: os Chain Ids das partes envolvidas; os endereços das contas envolvidas; os metadados (`TPFtData`) do título negociado; a quantidade (`tpftAmount`) de títulos negociados; o preço (`price`) a ser pago por unidade de TPFt; o estado inicial (`status` - 1 p/ vendedor) da operação e; a informação de confirmação de que a operação será realizada entre duas clientes de instituições (`isBetweenClients` = `true`).
+
+
+- [ex15-dvp-cliente-liquidacao-comprador.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex15-dvp-cliente-liquidacao-comprador.ts): realiza o resgate de uma operação de DVP com Título Público Federal Tokenizado enquanto comprador do ativo (entre clientes de instituições financeiras); 
+
+    <strong>Pré-requisitos:</strong>
+
+    1. É necessário ter executado o código [ex13-dvp-cliente-registro-comprador.ts](https://github.com/raylsnetwork/piloto_rd/blob/main/exemplos/ex13-dvp-cliente-registro-comprador.ts): previamente;
+
+    2. É necessário conhecer os metadados do TPFt (`TPFtData`), a saber: `acronym`, do tipo `string`; `code`, do tipo `string` e; `maturityDate` do tipo `uint256`;
+
+    3. É necessário conhecer dados da operação, a saber: os Chain Ids das partes envolvidas; os endereços das contas envolvidas; os metadados (`TPFtData`) do título negociado; a quantidade (`tpftAmount`) de títulos negociados; o preço (`price`) a ser pago por unidade de TPFt; o estado inicial (`status` - 2 p/ comprador) da operação e; a informação de confirmação de que a operação será realizada entre duas clientes de instituições (`isBetweenClients` = `true`).
+
+<br/>
+<br/>
+<br/>
+
+## Diagrama de Sequência
+
+<p align="center">
+  <a href="" rel="noopener">
+    <img src="https://public-professional-services.s3.eu-west-2.amazonaws.com/9-DVP-entre-Clientes.drawio.png" alt="Project logo">
+  </a>
+    <p align="center">
+    <span>DVP entre clientes de instituições financeiras</span>
+  </p>
+</p>
+
+
+<br>
+
+[<<< Voltar](../Rayls.md)