Staging

docs/fundamentals/certification.md

@@ -5,47 +5,36 @@ slug: "/certification"
 sidebar_position: 6
 ---
 
-Super Protocol uses the certification system for signing data, verifying signatures, and ensuring applications operate in a correct confidential computing environment. The system publishes verified data in the blockchain on behalf of confidential containers, allowing anyone to validate application integrity and ensure confidentiality.
+Super Protocol uses a certification system for signing data, verifying signatures, and ensuring applications operate within a trusted confidential computing environment. Verified data is published on the blockchain on behalf of confidential containers, allowing anyone to validate application integrity and ensure confidentiality. End users only interact with issued certificates and verify signatures, while the complexities of Remote Attestation are seamlessly managed in the background.
 
-All the system components are open-source, which guarantees transparency and verifiability.
+All the system components are open-source, ensuring transparency and verifiability.
 
 ## Architecture
 
-The backbone of the system is a hierarchical structure of Certification Authorities. Each Certification Authority works in a Confidential Virtual Machine (VM) executed inside a Trusted Execution Environment (TEE)—Intel SGX enclave.
+The backbone of the system is a hierarchical structure of Certification Authorities. Each Certification Authority operates inside a Trusted Execution Environment (TEE)—Intel SGX enclave.
 
 <img src={require('./images/certification-system-architecture.png').default} width="auto" height="auto"/>
 <br/>
 <br/>
 
 The Root Certification Authority (*Root CA*) is located at the highest hierarchical level. At the start, Root CA generates a self-signed certificate, embedding an SGX attestation quote.
 
-Distributed SubRoot Certification Authorities (*SubRoot CAs*) operate under the Root CA at the next hierarchical level. They provide their quotes and public keys for future certificates to the Root CA and request certificates.
+Distributed SubRoot Certification Authorities (*SubRoot CAs*) are located at the next hierarchical level. They provide their quotes and public keys to the Root CA and request certificates.
 
-Root CA receives these incoming requests, verifies them, and issues and signs certificates for SubRoot CAs. The SubRoot CAs, in turn, issue and sign certificates for [orders](/fundamentals/orders). Confidential VMs that execute orders may be deployed inside TDX, SEV, or other CPU- or GPU-based TEE.
+Root CA verifies the incoming requests and then issues and signs certificates for SubRoot CAs. The SubRoot CAs, in turn, issue and sign certificates for [orders](/fundamentals/orders).
 
 ## Order certificates
 
-The certification system facilitates attestation verification for orders, as only the order certificate is required. The certificate chain up to the Root CA is verified automatically.
+The issuing of order certificates involves [Trusted Loader](/whitepaper/tee-provider/#trusted-loader-mechanism)—a mechanism developed to load and run applications within a TEE. Trusted Loader operates inside a Confidential VM that executes the order. This VM is deployed within Intel TDX, AMD SEV-SNP, NVIDIA GPU TEE, or other TEEs.
 
-The issuing of order certificates involves [Trusted Loader](/whitepaper/tee-provider/#trusted-loader-mechanism)—a mechanism developed to load and run applications within a TEE. Trusted Loader operates inside a Confidential VM that executes the order.
+To receive an order certificate, the Trusted Loader sends a request to a SubRoot CA providing the quote and a public key. The SubRoot CA verifies the quote and issues the order certificate using the provided public key.
 
-The process of getting an order certificate is the following:
+### Workload Info
 
-1. Trusted Loader provides its quote and a public key to a SubRoot CA and sends a request for an order certificate.
-2. The SubRoot CA verifies the Trusted Loader’s quote and issues the order certificate with the provided public key.
+All orders in Super Protocol contain necessary input data, including the hash of the executed application—the *solution hash*. This execution environment is referred to as *Workload Info*.
 
-Any new order in Super Protocol contains necessary input data, including the solution hash or, in other words, the hash of the executed application. This execution environment is referred to as *Workload Info*.
+The Workload Info includes an array called `runtimeInfo[]`, which contains each order component’s `Type`, `Hash`, and `Size`. It may also contain a signature key (`SignatureKey`), stored as a hash, and hashes of input arguments (`Args`). Each application, dataset, or other order component has a corresponding entry in this array.
 
-The Workload Info includes an array called `runtimeInfo[]`, which contains each order component’s Type, Hash, and Size. It may also contain a signature key (SignatureKey), stored as a hash, and hashes of input arguments (Args hash). Each application, dataset, or other order component has a corresponding entry in this array.
+The hash of the Workload Info is stored in the certificate generated for each order. The certificate’s public component, private key, Workload Info, and complete certificate chain are stored in the `sp/certs` directory, available to the order during execution.
 
-The hash of the Workload Info is stored in the certificate generated for each order. The certificate’s public part, private key, Workload Info, and complete certificate chain are stored in the `sp/certs` directory available to the order during execution.
-
-Besides, the public part of the certificate and the `runtimeInfo[]` array are recorded on the blockchain, allowing anyone to validate the order and verify the certificate chain using the following [SPCTL](/cli) command:
-
-```
-./spctl orders get-report <ORDER_ID>
-```
-
-Where:
-
-- `<ORDER_ID>` is the ID of the order.
+Additionally, the public component of the certificate and the `runtimeInfo[]` array are recorded on the blockchain, allowing anyone to validate the order and verify the certificate chain.

docs/marketplace/guides/log-in.md

@@ -91,7 +91,7 @@ To log in as a Web3 user, you need the MetaMask browser extension. MetaMask is o
 <br/>
 <br/>
 
-3. In the MetaMask window that appears, **Approve** adding a new network (opBNB) and then **Confirm** the signature request.
+3. In the MetaMask window that appears, press **Connect**, then **Approve** adding a new network (opBNB Mainnet), and finally, **Confirm** the signature request.
 
 <img src={require('../images/metamask-add-opbnb.png').default} width="auto" height="auto" border="1"/>
 <br/>

docs/marketplace/limitations.md

@@ -21,20 +21,20 @@ Super Protocol constantly adds more TDX+H100 machines and will soon begin onboar
 Pricing and restrictions:
 
 - Order lease time: minimum 2 hours.
-- Compute costs 0.326 SPPI tokens per hour in most cases.
+- Compute costs 0.2126 SPPI tokens per hour in most cases.
 - Models from the Marketplace cost 0 SPPI per order.
 - Engines cost 0 SPPI per order.
 - Setting up a confidential tunnel costs 0.1 SPPI per order or less.
 
 For example, a two-hour GPU-order would cost:
 
-0.326 x 2 + ~0.1 = **0.752 SPPI** tokens.
+0.2126 x 2 + ~0.1 = **0.5252 SPPI** tokens.
 
 The total gas fee varies, but it is approximately **0.00001 BNB** per order.
 
 ## Token limits
 
-All users can receive up to **5 SPPI** tokens daily. Web3 users can also get up to **0.0001 BNB** tokens daily.
+Web3 users can receive up to **5 SPPI** tokens and **0.0001 BNB** tokens daily.
 
 ## Model limits