rebranding .md files (#1648)

* rebranding .md files

* rebranding .md files

* rebranding .md files

* revert changelog

contracts/README.md

@@ -1,6 +1,6 @@
-# Obscuro smart contracts
+# Ten smart contracts
 
-This hardhat project contains the relevant smart contracts for the Obscuro L2 platform.
+This hardhat project contains the relevant smart contracts for the Ten L2 platform.
 
 ## Dependencies
 
@@ -32,13 +32,13 @@ Additionally you can pass the `noCompile` flag which will disable running the co
 
 ### Deployment Scripts folder structure
 
- * core - Scripts required to be predeployed for Obscuro to start.
+ * core - Scripts required to be predeployed for Ten to start.
  * bridge - Scripts that deploy/upgrade ONLY the bridge.
  * messenger - Scripts that enable the relayer functionality. Can contain predeployed libraries too in the future.
  * testnet - Scripts that should only be deployed on the testnet. Tokens, "dev tooling" scripts, etc.
 
-For deployments, we use the hardhat-deploy plugin. It provides the `deploy` task, which determines what folders with deployment scripts need to be executed for the current selected network. Additionally there is the `obscuro:deploy` task that will launch a wallet extension.
-For the wallet extension to work, the network needs to have configured the `url` to 127.0.0.1:3000 and the additional `obscuroEncRpcUrl` property to the rpc endpoint of the obscuro node the wallet will connect to.
+For deployments, we use the hardhat-deploy plugin. It provides the `deploy` task, which determines what folders with deployment scripts need to be executed for the current selected network. Additionally there is the `ten:deploy` task that will launch a wallet extension.
+For the wallet extension to work, the network needs to have configured the `url` to 127.0.0.1:3000 and the additional `tenEncRpcUrl` property to the rpc endpoint of the ten node the wallet will connect to.
 
 Scripts are taken from `deployment_scripts` and executed in alphabetic order. Each folder, as ordered in the network config and then inside of it alphabetically. Notice that `func.dependencies = []` defined in deployment functions has the ability to escape the default ordering. If such a deployment function/script is reached, the deploy plugin will first deploy its dependency if it hasn't already.
 

contracts/src/README.md

@@ -1,7 +1,7 @@
 ## Solidity smart contracts
 
 In this subdirectory you can find the solidity smart contracts for the platform.
-Under the `/management` subdirectory you can find the root contract of Obscuro - ManagementContract.sol
+Under the `/management` subdirectory you can find the root contract of Ten - ManagementContract.sol
 It dictates the possible state of the Layer 2 and drives the process. 
 
 Under `/messaging` you can find the cross chain messaging contracts. Inside of it under the `/messenger` subdirectory sits an example implementation of cross chain message relayer that utilizes the message bus.

design/README.md

@@ -1,6 +1,6 @@
-# Obscuro design documents
+# Ten design documents
 
-Obscuro started based on a (whitepaper)[https://whitepaper.obscu.ro/] published in Nov. 2021.
+Ten started based on a (whitepaper)[https://whitepaper.obscu.ro/] published in Nov. 2021.
 
 As we started development, we started thinking more deeply about some aspects and also getting feedback from the community
 and the users.
@@ -25,7 +25,7 @@ Note: the wallet extension and the data relevancy rules are already implemented.
 
 ## Bridge
 
-Obscuro needs a decentralised bridge infrastructure to Ethereum.
+Ten needs a decentralised bridge infrastructure to Ethereum.
 
 Note: this design is approved and mostly implemented (there are some dependencies on the fast-finality work). 
 
@@ -40,7 +40,7 @@ Note: the design is approved, and currently it is being implemented.
 
 ## Security, Privacy and Cryptography
 
-Obscuro is a decentralised Ethereum Layer 2 that aims to maintain privacy.
+Ten is a decentralised Ethereum Layer 2 that aims to maintain privacy.
 We need to design the cryptography that keeps data private.
 Like any software system, it needs to be upgradeable, which is more difficult with our constraints.
 

design/architecture/overall_design.md

@@ -1,24 +1,24 @@
-# Obscuro design
+# Ten design
 
 ## Scope
 
-The purpose of this document is to describe aspects of Obscuro's technical design that are not addressed in the 
-[Obscuro whitepaper](https://whitepaper.obscu.ro/).
+The purpose of this document is to describe aspects of Ten's technical design that are not addressed in the 
+[Ten whitepaper](https://whitepaper.obscu.ro/).
 
 ## Overview
 
-The following diagram shows the key components of an Obscuro deployment:
+The following diagram shows the key components of an Ten deployment:
 
 ![architecture diagram](./resources/obscuro_arch.jpeg)
 
 The Ethereum node and Ethereum chain components shown in this diagram are developed and maintained by third-parties. 
 The following additional components must be developed:
 
-* **The enclave:** The trusted part of the Obscuro node that runs inside a trusted execution environment (TEE)
-* **The host:** The remainder of the Obscuro node that runs outside the TEE
-* **The Obscuro management contract:** The Ethereum mainnet contracts required by the Obscuro protocol, described 
-  [here](https://whitepaper.obscu.ro/obscuro-whitepaper/l1-contracts)
-* **Client apps:** Applications that interact with the Obscuro node (e.g. Obscuro wallets)
+* **The enclave:** The trusted part of the Ten node that runs inside a trusted execution environment (TEE)
+* **The host:** The remainder of the Ten node that runs outside the TEE
+* **The Ten management contract:** The Ethereum mainnet contracts required by the Ten protocol, described 
+  [here](https://whitepaper.obscu.ro/ten-whitepaper/l1-contracts)
+* **Client apps:** Applications that interact with the Ten node (e.g. Ten wallets)
 
 ## Host/enclave split
 
@@ -50,7 +50,7 @@ The host has a lot of responsibilities, including:
 - serving requests for data and transaction submissions
 - feeding data to the enclave to keep it up-to-date with the L1 and L2 networks
 - publishing secret request/responses and (for the sequencer) rollups to the L1 network
-- receiving and publishing Obscuro data (e.g. batches and mempool transactions) with peer nodes
+- receiving and publishing Ten data (e.g. batches and mempool transactions) with peer nodes
 - managing failover and recovery for the enclave for high-availability (HA) nodes
 
 The host will be organised with a variety of services to manage these responsibilities.

design/architecture/tech_decisions.md

@@ -1,12 +1,12 @@
 # Tech decisions
 
-This document lists the frameworks and tooling used by Obscuro.
+This document lists the frameworks and tooling used by Ten.
 
 The purpose of this list is to avoid the proliferation of different frameworks and tooling with the same general 
-purpose, as this increases the developer overhead when extending Obscuro.
+purpose, as this increases the developer overhead when extending Ten.
 
 The introduction of a new framework or tool should be discussed with the team, even if the usage sits outside the 
-`go-obscuro` repo.
+`go-ten` repo.
 
 ## Deployment