# Introduction
Welcome to Graphite’s developer documentation hub. Dive into our resources to learn more about the blockchain leading the next generation of consumer crypto.
## Get started with Graphite
Connect to Graphite
Connect your wallet or development environment to Graphite.
# What is Graphite?
Graphite is a finance-oriented blockchain platform aiming to formalize crypto transactions through a unique reputation-based system, enhanced Know Your Customer (KYC) procedures, and a Proof-of-Authority (PoA) consensus model. Graphite seeks to blend the benefits of traditional financial systems with the transparency and security of blockchain, balancing privacy with a reputation-focused ecosystem.
## **Key Features and Principles**
### **Reputation-Based Ecosystem:**
Graphite’s primary differentiator is it's **`reputation-centric`** approach, which enables more formalized, trust-based interactions:
* **`Account Activation`**: To avoid clutter from inactive or fraudulent accounts, users activate their wallets with a small fee before sending transactions.
* **`Trust Score`**: Each user is assigned a Trust Score, influenced by factors like KYC, account longevity, transaction history, and volume. This score assists in evaluating a user’s credibility, enhancing trust within the ecosystem.
### **Advanced KYC and Privacy Controls**:
* **`KYC Verification`**: Graphite offers a KYC verification process that allows users to build their reputations without compromising personal privacy. Verified data remains off-chain and only a user’s KYC level is recorded on the blockchain.
* **`Zero Knowledge Proof (ZKP) for Enhanced Privacy`**: Through ZKP technology, Graphite plans to implement KYC procedures that confirm identity without revealing sensitive data, thus ensuring security and privacy.
* **`KYC Transaction Filters`**: Users can apply KYC-based filters to incoming transactions, allowing them to block transactions from accounts without KYC. This feature minimizes fraud risks by reinforcing the “One User, One Account” policy.
### **Proof-of-Authority (PoA) with Polymer 2.0 Algorithm**:
* Graphite’s **`PoA consensus mechanism`** improves efficiency by using a set of authorized nodes to validate blocks, minimizing computational and energy costs associated with traditional Proof-of-Work systems.
* **`Top-Tier Authorized Nodes`**: Top-performing nodes are given priority in block validation, incentivizing high performance. These nodes have twice the likelihood of sealing a block, earning a share of transaction fees.
* **`Oracle-Based Randomization`**: To select block sealers fairly, Graphite uses an Oracle system that provides randomized values for each block, ensuring impartiality and reducing potential for collusion.
### **Income Generation for Network Nodes**:
* **`Transport Nodes`**: Graphite allows entry-point transport nodes to earn income, setting it apart from most blockchains. A portion of transaction fees goes to these nodes when users initiate transactions through them, enhancing incentives for participation without heavy resource requirements.
* **`Graphite Foundation Nodes`**: Maintained by the Graphite Foundation, these nodes provide stability, ensuring uptime and network reliability even if other nodes fail.
### **Efficient Transaction and Fee Model**:
* **`Fixed Transaction Fees`**: Graphite applies a consistent fee rate, protecting users from fluctuating gas prices and reducing transaction delays.
* **`Scalability`**: The network supports high throughput, handling up to 1,400 transactions per second, with confirmation times under 10 seconds, ensuring speed and reliability.
# Connect to Graphite
Add Graphite to your wallet or development environment to get started.
Use the information below to connect and submit transactions to Graphite.
## [](https://docs.abs.xyz/overview#testnet)Testnet
# Graphite account activation
## Account Activation Instructions
### With MetaMask
You can activate your account by following [**`this link`**](https://atgraphite.com/account).
{% stepper %}
{% step %}
**Connect MetaMask**
* Open MetaMask and select the address you want to connect.
* A pop-up will appear with the message **`isn't connected to atgraphite.com`** and a **`Connect Account`** button. Click this button to connect the selected address.
{% endstep %}
{% step %}
**Activate Your Account**
* In the interface, find the **`Graphite Account`** card.
* Click the **`Activate`** button.
*A transaction will be required to activate the account, so make sure you have sufficient funds in your wallet.*
{% endstep %}
{% step %}
**Confirm the Transaction**
You will be redirected back to MetaMask to confirm the transaction. Approve it in the MetaMask window.
{% endstep %}
{% step %}
**Activation Pending**
After successful confirmation, your account status will change to **`Pending`**. This indicates that the request is processing, and the activation should only take a short time.
{% endstep %}
{% step %}
**Account Activated**
Once the processing is complete, your status will change to **`Activated`**. Now you can customize your filters and pass KYC.
{% endstep %}
{% endstepper %}
### With Graphite Wallet
{% stepper %}
{% step %}
**Install Graphite Wallet**
* Install Graphite Wallet extension by following [**`this link`**](https://chromewebstore.google.com/detail/graphite-wallet/fbgdgmhhhlimaanngeakidegojjbbbbm).
* Create a new wallet or import mnemonic/private key, and come up with a password.
* Supported browser: **`Chrome`**
{% endstep %}
{% step %}
**Completion of Setup**
* Go to the account settings page to activate your account.
* A transaction will be required to activate the account, so make sure you have sufficient funds in your wallet.
{% endstep %}
{% step %}
**Activate Your Account**
* In the interface, find the **`Not activated`** card. Click on it, and you will be taken to the activation page.
* Click the **`Activate`** button.
{% endstep %}
{% step %}
**Confirm the Transaction**
To activate your account, review the transaction details in the next step and confirm it. The process is quick, and your account will be ready to use soon.
{% endstep %}
{% step %}
**Waiting for Transaction Confirmation**
After confirming the transaction, please wait for it to be processed. This usually takes only a short time. Once completed, your account will be activated automatically.
{% endstep %}
{% step %}
**Account Activated**
Once the processing is complete, your status will change to **`Activated`**. Now you can customize your filters and pass KYC.
{% endstep %}
{% endstepper %}
# Graphite Wrapped Tokens
These are the addresses of the token and the bridge.
### Mainnet
All tokens have the symbol @G.
### Mainnet Bridge
You can use our official interface at [https://bridge.atgraphite.com](https://bridge.atgraphite.com/).\
If you prefer to use the bridge functionality without our frontend, follow the instructions below based on your current network to transfer Graphite tokens from one chain to another.
#### On the Graphite Network
Use the **`swap`** function:
```solidity
function swap(address to, uint256 destChainId) external payable
```
{% hint style="warning" %}
This is a `payable` function — make sure to send the desired amount of native Graphite (@G) along with the transaction.
{% endhint %}
Parameters:
| Name | Type | Description |
| ------------- | --------- | -------------------------------------------------------------------------------------- |
| `to` | `address` | Address on the destination chain to receive the tokens |
| `destChainId` | `uint256` | Destination chain ID (`1` = Ethereum, `56` = BSC, `137` = Polygon, `42161` = Arbitrum) |
#### On Other Networks
Use the **`swapToken`** function:
```solidity
function swapToken(address to, uint256 destChainId, uint256 amount) external
```
Parameters:
| Name | Type | Description |
| ------------- | --------- | ----------------------------------------------------------------------------------------------------------- |
| `to` | `address` | Address on the destination chain to receive the tokens |
| `destChainId` | `uint256` | Destination chain ID (`1` = Ethereum, `56` = BSC, `137` = Polygon, `42161` = Arbitrum, `440017` = Graphite) |
| `amount` | `uint256` | Amount of Graphite tokens to send (18 decimals) |
\
The contract code and full documentation are available at: [https://github.com/atgraphite/graphite-token](https://github.com/atgraphite/graphite-token)\
\
You can find the documentation for all available contract methods here: [https://github.com/atgraphite/graphite-token/blob/main/docs/LiquidityStorager.md](https://github.com/atgraphite/graphite-token/blob/main/docs/LiquidityStorager.md)
# Getting started
Graphite’s Ethereum-compatible VM makes migrating your project onto GRAPHITE very easy. Learn how to interact with Graphite and get all the resources needed to help you get started.
## Why build on Graphite?
The Graphite network offers unparalleled opportunities for developers. With easy contract deployment and a fast TPS rate, you will be able to scale your protocol in no time. Without having to deal with scalability issues, the stage is set for mutually beneficial cooperation.
* EVM compatibility
* Speed
* Users inflow
* Legal cashflows
* Security
* Scalability
## Resources & Learning
The Graphite network is EVM-compatible, so previous experience with Solidity can be applied to our new infrastructure. To start out, review our Developer Documentation. It will help you assess the prospects and potential benefits for your project on the Graphite network.
## Node Setup
[**`Graphite node setup`**](/infrastructure/images-and-media) is effortless and can be done with just a couple lines of code thanks to Docker.
{% hint style="danger" %}
Always have a copy of the blockchain saved locally, parse data and test whatever and whenever you want.
{% endhint %}
## Graphite JS SDK
We adopted the Web3JS library to make your interaction with Graphite blockchain as easy as possible, regardless of scale. Connect your wallet and get access to all the features the Web3JS library has, along with new ones introduced by Graphite Network.
## Graphite Explorer
We’ve created [**`the Graphite Explorer`**](/ecosystem/the-graphite-explorer) and reinforced it with an API to empower developers with direct access to blockchain data via common GET/POST requests. Learn everything you need about blocks, transactions, fees and more.
# System Contracts
## About Graphite
At Graphite, we believe that reputation is the cornerstone of any highly functioning, healthy market. This is why we have built Graphite to be a reputation-based network. Graphite's architecture is designed to eliminate the waste of computational power that comes with PoW blockchains, gas betting, etc., but retains the ability to make an income for network participants without having to invest exorbitant amounts of resources.
All of this is achieved by implementing Graphite Key Features:
* Reputation-based smart contracts
* Efficient and effective KYC-Verification
* Transaction circle filters based on reputation (KYC, etc.)
* Efficient block validation (PoA consensus)
* Low and stable transaction costs
* Income for entry-point nodes.
# Account Activation
## Intro
**`FeeContract.sol`** is a Graphite system smart contract. The contract is used to perform Account Activation. Without Account Activation, an account isn't able to send transactions to the blockchain.
* To activate your account and pay the fee for Account Activation, call **`pay()`**.
* **`changeFee(initialFee)`** is for administrative purposes and changes the fee for Account Activation.
### Network address of the contract
```
FeeContract_address = "0x0000000000000000000000000000000000001000"
```
## Functions
### pay()
* #### **Purpose**
Call **`pay()`** in order to pay the fee for Account Activation and activate the wallet address that called this function.
* #### **Arguments**
*none*
* #### **After Execution**
Upon successful execution of a function, the wallet address becomes activated.
If the currency value of a calling transaction is less than the **`InitialFee`**, the message Not enough Ether **`Provided.`** will be sent and account won't be activated.
* #### **Details**
An Activated Account is an account (wallet address) that is capable of sending outgoing transactions. Transactions from non-activated accounts are rejected by Graphite Nodes. *To determine if an account is activated, Graphite Nodes check if there are any transcations in the blockchain that originated from the account. Account Activation is always the first transaction of any user account on the network.*
The excessive value (fee) for account activation will be returned to the function caller.
### **changeFee(...)**
* #### **Purpose**
Determines the size of the fee for Account Activation. Only Graphite network admins (*owners of the FeeContract smart-contract*) can execute this function.
# Filter Contract (KYC Transaction Filters)
## Intro
**`FilterContract.sol`** is a Graphite system smart contract. It's needed for users to work with KYC-Filters for incoming transactions.
* To set a filter level for your account, call **`setFilterLevel(level)`**.
* To check the current KYC-Filter level of your account, call **`viewFilterLevel()`**.
* To check if a potential transaction from account A to account B goes through (i.e. isn't blocked by KYC-Filter on B), call **`filter(sender, destination)`**.
### Network address of the contract
```
FilterContract_address = "0x0000000000000000000000000000000000001002"
```
## Functions
### **setFilterLevel(level)**
```
setFilterLevel(uint _level)
⎯⎯
_level - uint; KYC-Filter for incoming transactions to be set.
```
* #### **Purpose**
Call **`setFilterLevel(level)`** to set up a value for a KYC transaction filter for incoming transactions, rejecting senders with KYC level lower than the filter value.
* #### **Arguments**
**`level`** - integer value; the value of the KYC Filter (*directly related to sender's KYC Level*)
* #### **After Execution**
Upon successful execution, a caller wallet address will have a KYC Filter for incoming transactions set at a certain value.
* #### **Details**
Since the exact number of available KYC Verification levels is not yet finalized, the level(value) of KYC Filters is not limited on the testnet. Additionally, at the moment there are no KYC Level restrictions that the KYC Center is able to grant. On the mainnet, it's expected that there'll be 2-5 available KYC levels.
Transactions that don't fit the KYC Filter are rejected by Graphite nodes.
### **viewFilterLevel()**
```
viewFilterLevel()
```
* #### **Purpose**
Call **`viewFilterLevel()`** to get the current KYC Filter level that a caller has for incoming transactions.
* #### **Arguments**
*none*
* #### **After Execution**
Function restores the KYC Filter level.
* #### **Details**
A wallet address can call this function only for itself, not for others.
### **filter(sender, destination)**
```
filter(address _sender,address _destination)
⎯⎯
_sender - address; wallet address of a sender in a potential transaction
_destination - address; destination wallet address in this transaction
```
* #### **Purpose**
Call **`filter(sender, destination)`** to check if a transfer from sender address to destination address will or won't be rejected by the blockchain.
* #### **Arguments**
**`sender`** - wallet address of a sender of a potential transaction. destination - wallet address of the receiver (destination).
* #### **After Execution**
Returns **`true`** if sender's KYC level is greater than destination's KYC Filter level (i.e. a potential transaction will go through and won't be rejected by nodes).
Returns **`false`** if sender's KYC level is less than destination's KYC Filter level (i.e. a potential transaction won't go through and will be rejected by nodes).
* #### **Details**
This function uses the **`KYCContract`** smart contact to get KYC level data.
# KYC Contract
## Intro
**`KYCContract.sol`** is a Graphite system smart contract. It's needed for general users and KYC Centers to enable KYC Verification.
The KYC Verification process starts and finishes on the blockchain with function calls of this smart contract. But the KYC verification itself (information providing, verification of the authenticity) happens off-chain between a user and a KYC Center. All private data stays off-chain, only the result of the KYC verification is written on the blockchain.
### **Primary actions**
* As a user, to apply for KYC Verification and transfer the deposit for KYC, call **`createKYCRequest(level, data)`**.
* As a KYC Center, to approve a user's KYC request and verify KYC Level, call **`approveKYCRequest(index)`**.
* As a KYC Center, to decline a user's KYC request in case of a failed verification, call **`declineRequest(index)`**.
### **Status of KYC**
* As a user, to view one of your KYC requests and check its status, call **`viewMyRequest(senderKYCIndex)`**.
* To get the global index of a user's last KYC request, call **`getLastGlobalRequestIndexOfAddress(addr)`**.
* To get a KYC request assigned to a KYC Center, call **`viewRequestAssignedToCentre(KYCCenteraddr, localKYCIndex)`**.
### **Corner-Cases**
* As a user, for a pending KYC Request in which the assigned KYC Center was revoked of its role, call **`repairLostRequest()`** to withdraw the KYC request and return the deposit.
* As a KYC Center, to revoke a user’s granted KYC Level (justification for the action required), call **`decreaseKYCLevel(addr, level)`**.
### **Misc**
* **`setLevelPrice(...)`** is for administrative purposes and changes the deposit size needed for each KYC Level.
### Network address of the contract
```
KYCContract_address = "0x0000000000000000000000000000000000001001"
```
## Functions
### **createKYCRequest(level, data)**
```
createKYCRequest(uint _level, bytes32 _data)
⎯⎯
_level - uint; desired KYC-Level (greater than current)
_data - bytes32; has no use
```
* #### **Purpose**
Call **`createKYCRequest(level, data)`** to request KYC Verification of a desired level for a caller account. *The requested KYC Level should be greater than the account's current KYC Level.*
A successful call starts the KYC Verification process which is carried out by a randomly selected KYC Center.
* #### **Arguments**
**`level`** - integer value; KYCLevel to be granted to a caller account upon successful KYC Verification.
**`data`** - 32 byte array; will be stored in KYCRequest object, has no meaningful use in current v. of Graphite.
* #### **After Execution**
Successful **`createKYCRequest()`** call creates **`KYCRequest`** object holding info (user addr, KYC Level, status, KYC Center, deposit) needed for KYC-Verification and stores it on the blockchain. Instances of**`KYCRequest`** have consecutive integer indexes starting from **`0`**. Pending **`KYCRequest`** has **`status`** equal to **`0`**.
This function appoints a randomly choosen KYC Center from the pool of compliant KYC Centers. The chosen KYC Center is the only one for this and related **`KYCRequest`**. Only this KYC Center has the power to then approve or decline the **`KYCRequest`**.
The verification itself is carried out off-chain by the appointed KYC Center. Upon completing it, the KYC Center calls **`approveKYCRequest(ind)`** or **`declineRequest(ind)`** functions of the KYCContract.sol (current one).
{% hint style="info" %}
*Note:* Only the result of KYC Verification is written on the blockchain. All private data stays off-chain between a user and a KYC Center which follows strict data protection and governance rules.
{% endhint %}
* #### **Details**
If a KYC Level of a function caller account is equal to or greater than the requested KYC level (**`level`** arg.), the error message **`You already have this KYC level`** will be sent and execution will be stopped.
If a caller has not finished KYCVerification, execution will be stopped with a **`Your previous request is still pending answer`** error-message. Approval or decline of an active **`KYCRequest`** is required for the creation of a new one.
If a currency fee bound to a calling transaction is less than the needed amount for the requested KYC Level, the message **`Provided not enough Ether.`** will be sent with no **`KYCRequest`** creation. The exceeding fee amount, if any, will be returned to the function caller.
The KYC Verification can only happen if there is at least one appointed KYC Center on the network. If there is none, **`There are no kyc centres`** error is thrown.
### **approveKYCRequest(index)**
```
approveKYCRequest(uint _index)
⎯⎯
_index - uint; index of KYCReqeust to be approved
```
* #### **Purpose**
As the KYC-Center of a **`KYCRequest`**, call approveKYCRequest(ind) to approve the very **`KYCRequest`**.
* #### **Arguments**
**`index`** - integer value; Index of **`KYCRequest`** object to be approved.
* #### **After Execution**
Successful **`approveKYCRequest(index)`** call approves the **`KYCRequest`** under the **`index`** producing **`KYCLevelChanged(user, level)`**, **`RequestApproved(index)`** events.
Function changes the **`status`** of **`KYCRequest`** to **`2`**. Now the account in **`KYCRequest`** is officially granted the requested KYC-level.
In terms of payment, 50% of the **`KYCRequest`** deposit sum is sent to the user who created **`KYCRequest`**, the other 50% is sent to the KYC-Center responsible for approving **`KYCRequest`** (i.e. calling this function).
* #### **Details**
Execution will only go through if **`approveKYCRequest(index)`** is called by the KYC-Center mentioned **`KYCRequest`** under **`index`**.
Only KYC-Centers can call this function; **`Not allowed to approve`** error is thrown if called by a non-KYC-Center account.
If the **`KYCRequest`** isn't pending (**`status`** != 0), the **`This request is not pending decision`** error is thrown.
### **declineRequest(index)**
```
declineRequest(uint _index)
⎯⎯
_index - uint; index of KYCReqeust to be declined
```
* #### **Purpose**
As the KYC-Center of a **`KYCRequest`**, call **`declineRequest(ind)`** to decline the very **`KYCRequest`**.
* #### **Arguments**
**`index`** - integer value; Index of **`KYCRequest`** object to be approved.
* #### **After Execution**
Successful **`declineRequest`** call declines the **`KYCRequest`** under the **`index`** producing a**`RequestApproved(index)`** event.
This unction changes the **`status`** of **`KYCRequest`** to **`1`**. The KYC-Level of the account in **`KYCRequest`** doesn't change.
In terms of payment, 50% of the **`KYCRequest`** deposit sum is sent to the KYC-Center which declined **`KYCRequest`** (i.e. called this function). The rest goes to the Graphite Foundation.
* #### **Details**
Execution will only go through if **`declineRequest(index)`** is called by the KYC-Center mentioned **`KYCRequest`** under **`index`**.
Only KYC-Centers can call this function; **`Not allowed to approve`** error is thrown if called by a non-KYC-Center account.
For security reasons, it's technically possible to call **`declineRequest(index)`** for both pending (**`status`** = 0) and approved (**`status`** = 2) instances of **`KYCRequest`**.
### **viewMyRequest(senderKYCIndex)**
```
viewMyRequest(uint _senderKYCIndex)
⎯⎯
senderKYCIndex - uint; account-specific index of KYCRequests of function caller
```
* #### **Purpose**
An account calls **`viewMyRequest(senderKYCIndex)`** to get its **`KYCRequest`** object under an index (account-specific).
Then, for example, a user can check a **`status`** of **`KYCReuqest`**: Pending - **`0`**, Declined - **`1`**, Approved - **`2`**, Withdrawn due to loss of KYC-Center - **`3`**.
* #### **Arguments**
**`senderKYCIndex`** - integer value; Consecutive index (from **`0`**) of **`KYCRequest`** objects created by function caller account. This index is account-specific. It's not the same as the general index of**`KYCRequest`** objects mentioned elsewhere in this document.
* #### **After Execution**
Returns a caller account's **`KYCRequest`** under an account-specific index.
* #### **Details**
Calling with an invalid **`senderKYCIndex`** arg. (i.e. an account caller only successfully requested KYC twice; but **`viewMyRequest(4)`** is called) won't return **`KYCRequest`** object.
### **getLastGlobalRequestIndexOfAddress(addr)**
```
getLastGlobalRequestIndexOfAddress(address _addr)
⎯⎯
_addr - address; wallet address of a user
```
* #### **Purpose**
This function returns the index of the last **`KYCRequest`** created by the user under **`addr`**. Returns **`-1`** if there were none **`KYCRequests`** for the **`addr`**.
Anyone on the network can all this function.
### **viewRequestAssignedToCentre(KYCCenteraddr, localKYCIndex)**
```
viewRequestAssignedToCentre(address _KYCCenteraddr, uint _localKYCIndex)
⎯⎯
_KYCCenteraddr - address; address of a KYC-Center
_localKYCIndex - int; KYC-Center-specific index of assigned KYCRequest
```
* #### **Purpose**
Call **`viewRequestAssignedToCentre(KYCCenteraddr, localKYCIndex)`** to get **`KYCRequest`** object that was assigned to the KYC Center(**`KYCCenteraddr`**) under an index (KYC-Center-specific **`localKYCIndex`**).
### **decreaseKYCLevel(addr, level)**
```
decreaseKYCLevel(address _addr, uint _level)
⎯⎯
_addr - address; wallet address of a user
_level - int; desired KYC-Level (greater than current)
```
* #### **Purpose**
Function decreases the KYC Level of a specified account (**`addr`**) to a specified value (**`level`**). It can only be called by a KYC-Center.
The intended purpose of this function is to decrease an account's KYC Level due to fraudulent or suspicious activities. The calling of this function by KYC Centers follows strict guidelines. A KYC Center that abuses the usage of **`decreaseKYCLevel()`** will be removed from its role.
Only decreasing a KYC Level is possible with this mechanism for security reasons.
### **repairLostRequest()**
* #### **Purpose**
In an event that the KYC Center assigned to a pending KYCRequest is to be removed from their KYC Center role, **`KYCRequest`** cannot be resolved in a standard way.
In this case, the user (creator of **`KYCRequest`**) can call **`repairLostRequest()`**, to withdraw **`KYCRequest`** (sets its **`status`** = 3) and return all of the **`KYCRequest`** deposit.
### **setLevelPrice(...)**
* #### **Purpose**
Determines the fee size needed to start verification for a certain KYC Level. Only Graphite network admins (*owners of the KYCContract smart contract*) can call this function.
# Reputation
## Intro
**`Reputation.sol`** is a Graphite system smart contract. It's needed for users to create their own reputation-based smart contracts.
Reputation is calculated as follows:
$$
Reputation=CD+A+KYC+QTx+Diff
$$
Parameter
Сriteria
Reputation Score
Creation date (CD)
more 100000 blocks ago
100
50000 - 100000 blocks ago
70
10000 - 50000 blocks ago
50
less 10000 blocks ago
0
Parameter
Criteria
Reputation Score
Activated (A)
Activated
100
Not Activated
0
Parameter
Criteria
Reputation Score
KYC
Level 0
0
Level 1
100
Parameter
Criteria
Reputation Score
Quantity of txn (QTx)
more 1000
100
500 - 1000
80
100 - 500
50
10 - 100
30
1 - 10
5
0
0
Parameter
Criteria
Reputation Score
Difference (Diff)
(all in - all in) more 0.1 @G
50
(all in - all out) less 0.1 @G
0
### Network address of the contract
```
Reputation_address = "0x0000000000000000000000000000000000001008"
```
## Functions
### getReputation(address addr)
* **Purpose**
Call **`getReputation(address addr)`** to get the reputation of a particular address.
* **Arguments**
**`address`** - wallet address.
* **After Execution**
This function returns the reputation.
# How to Complete KYC in a Testnet
We’ve implemented a simple KYC emulation process for testnet environments. Just send a UUID, and you’ll receive either **`approval or rejection with a 50% probability`**.
Before using the API, you must first submit a KYC request to the contract.\
See the documentation [here](https://docs.atgraphite.com/build-on-graphite/system-contracts/kyc-contract).
Call the method **`createKYCRequest(uint _level, bytes32 _data)`**\
Use **`sha256(uuid)`** as the **`_data`** parameter.
This API is designed to simplify the process of emulating KYC in a testnet environment, allowing developers to efficiently test workflows that depend on KYC outcomes.
> The 50% approval/rejection mechanism is designed for test purposes only. No actual KYC verification is performed.
#### Endpoint:
**`POST https://test.kyc.atgraphite.com/api/kyc/process-request`**
#### Request:
```javascript
{
"data": "uuid"
}
```
Test your KYC workflows easily with this tool.
# How to Deploy Smart Contracts Using Hardhat: A Step-by-Step Guide
This guide will walk you through deploying a smart contract using Hardhat.
## Prerequisites
Before we begin, make sure you have the following:
1. Node.js installed (version 12.0.0 or later).
2. NPM or Yarn.
3. [**`Activated Graphite account`**](/overview/graphite-account-activation).
4. Basic knowledge of Solidity and smart contracts.
### Step 1: Install Node.js and NPM (if not already installed)
Download Node.js from the official site and follow the instructions for installation. This will also install NPM (Node Package Manager), which is needed to install Hardhat and other dependencies.
### Step 2: Create a New Hardhat Project
Open a terminal and create a new directory for your project, then navigate:
```javascript
mkdir my-project
cd my-project
```
Initialize an empty project and install Hardhat:
```javascript
npm init -y
npm install --save-dev hardhat
```
Once the installation is complete, run Hardhat to initialize your project:
```javascript
npx hardhat
```
Hardhat will present a menu of options. Select **`Create an empty hardhat.config.js`** for simplicity.
### Step 3: Install Additional Dependencies
You’ll need to install a few additional libraries that will help with writing and deploying contracts:
```
npm install --save-dev @nomiclabs/hardhat-ethers ethers
npm install dotenv
```
**`ethers.js`** helps interact with the Ethereum blockchain.
**`dotenv`** allows you to store environment variables securely (e.g., private keys).
### Step 4: Write Your Smart Contract
Create a folder named **`contracts`** in the root of your project:
```
mkdir contracts
```
Inside the **`contracts`** folder, create a new Solidity file, **`MyContract.sol`**. Below is a simple example of an ERC20 token contract:
```javascript
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
contract MyToken is ERC20 {
constructor() ERC20("MyToken", "MTK") {
_mint(msg.sender, 1000 * 10 ** 18);
}
}
```
This contract creates an ERC20 token named "MyToken" with the symbol "MTK" and an initial supply of 1000 tokens.
### Step 5: Configure Hardhat for Deployment
In the root of your project, locate or create the **`hardhat.config.js`** file. Configure it to deploy to a specific network. Add the following configuration:
```javascript
require('@nomiclabs/hardhat-ethers');
require('dotenv').config();
module.exports = {
solidity: "0.8.0",
networks: {
graphite: {
url: process.env.RPC_URL,
accounts: [process.env.PRIVATE_KEY]
},
},
};
```
* **`PRIVATE_KEY`** is your wallet private key. **`Do not expose it publicly`**.
To securely store your API keys, create a **`.env file`** in the root of your project:
```javascript
RPC_URL="https://anon-entrypoint-1.atgraphite.com"
PRIVATE_KEY="your-private-key-here"
```
### Step 6: Write a Deployment Script
Create a folder named **`scripts`** and inside it, create a **`deploy.js`** script:
```
mkdir scripts
```
In **`scripts/deploy.js`**, add the following code:
```javascript
async function main() {
const [deployer] = await ethers.getSigners();
console.log("Deploying contracts with the account:", deployer.address);
const balance = await deployer.getBalance();
console.log("Account balance:", balance.toString());
const Token = await ethers.getContractFactory("MyToken");
const token = await Token.deploy();
console.log("Token deployed to:", token.address);
}
main()
.then(() => process.exit(0))
.catch(error => {
console.error(error);
process.exit(1);
});
```
### Step 7: Compile the Contract
Before deploying, compile your Solidity contract:
```
npx hardhat compile
```
If everything is set up correctly, this should compile without errors.
### Step 8: Deploy the Contract
Run the deployment script:
```
npx hardhat run scripts/deploy.js --network graphite
```
This command will deploy your contract to the Graphite network using the configuration provided in **`hardhat.config.js`**.
### Step 9: Verify the Deployment
Once the deployment is successful, Hardhat will print the contract address in the terminal. You can verify the contract on a [**Graphite Explorer**](/ecosystem/the-graphite-explorer) by searching for the deployed contract address.
### Step 10: Interact with the Contract
After deployment, you can interact with your contract using **`ethers.js`**. Here's an example of how to call a function on your contract:
1. Create a new script called **`interact.js`** in the **`scripts`** folder.
```javascript
async function main() {
const Token = await ethers.getContractFactory("MyToken");
const token = await Token.attach("your-deployed-contract-address-here");
const totalSupply = await token.totalSupply();
console.log("Total Supply:", totalSupply.toString());
const name = await token.name();
console.log("Token Name:", name);
}
main()
.then(() => process.exit(0))
.catch(error => {
console.error(error);
process.exit(1);
});
```
2. Run the script to interact with the contract:
```
npx hardhat run scripts/interact.js --network graphite
```
# SDK
# JS SDK
A plugin for working with the Graphite transactions.
### Installation
```javascript
npm install @atgraphite/web3-plugin
# or
yarn add @atgraphite/web3-plugin
```
### Getting Started
To use this plugin simply import it, and add register it to your web3 instance.
```javascript
import { GraphitePlugin } from "@atgraphite/web3-plugin";
const NODE_URL = 'node url';
const web3 = new Web3(NODE_URL)
web3.eth.accounts.wallet.add(privateKey)
web3.registerPlugin(new GraphitePlugin(web3))
```
You can use our nodes instead of **`node_url`**. They are available [here](https://docs.atgraphite.com/overview/publish-your-docs).\
\
And you're ready to go! There are 2 types of nodes, normal and anonymous. Read more about them [here](https://docs.atgraphite.com/).
### First time users
After registering the plugin, you need to activate you account:
```javascript
await web3.graphite.activateAccount()
```
which has a fee, more about that [here](https://docs.atgraphite.com/build-on-graphite/system-contracts/account-activation).
To check the fee amount, use:
```javascript
await web3.graphite.getActivationFeeAmount()
```
### Interface
The following functions are accessible via web3.graphite.(\*)
```javascript
async getActivationFeeAmount()
async activateAccount()
async isActivated(address: string = this.getWalletAddress())
async getFilterLevel()
async setFilterLevel(newLevel: number)
async createKYCRequest(uuid: string, newLevel: number)
async getKycLevel(address: string = this.getWalletAddress())
async getLastKycRequest()
async repairLostKycRequest()
async cancelKycRequest()
async getKYCFee(level: number)
async sendTransaction(txData: TxData)
async patchFields(txData: TxData)
async getReputation(address: string = this.getWalletAddress())
getWalletAddress()
getWalletPrivateKey()
getWallet()
async getEpAddress()
```
# GraphiteTx (Type 100)
### What is it?
**GraphiteTx (type 100)** is a transaction format used in the Graphite network.\
It was introduced to support the **Entry-Point node address** (**`epAddress`**), which identifies the node through which a transaction enters the network.
Thanks to this mechanism, nodes can **legitimately earn a portion of transaction fees** by acting as entry points for user transactions.
### Key Features of GraphiteTx (Type 100)
| Field | Description |
| ------------ | ------------------------------------------------------------- |
| `epAddress` | Address of the Entry-Point node that accepted the transaction |
| `type: 0x64` | Indicates this is a new Graphite transaction |
| `accessList` | Access list support, similar to EIP-2930 |
| Signature | Same as AccessListTx format |
{% hint style="warning" %}
The **`epAddress`** field is optional.\
\
If it is omitted, the transaction is treated as **anonymous**, and the Entry-Point node will **not receive any reward**.
{% endhint %}
You can create and send GraphiteTx (type 100) transactions using our official [**SDK**](/build-on-graphite/sdk).
### Technical Details
**Type:** `0x64`
#### Example structure:
```
[
chainId,
nonce,
gasPrice,
gasLimit,
to,
value,
data,
accessList,
epAddress,
v, r, s
]
```
### How does this relate to Entry-Point node income?
Transactions of type 100 enable the following:
* Include the address of the node through which the transaction entered the network (**`epAddress`**)
* Allow the network to **share transaction fees** with that Entry-Point node
In short, **GraphiteTx (type 100) makes it possible to earn through infrastructure**, not through mining or staking.
### RPC Method: `graphite_getEpAddress`
The **`graphite_getEpAddress`** RPC method allows you to **check if a specific Graphite (Entry-Point) node has a registered blockchain address**, and if so, what it is.
This address is used to receive rewards for handling incoming **GraphiteTx (type 100)** transactions that specify an **`epAddress`**.
**Why is this useful?**
* The public Entry-Point address acts as the **identifier** of a node eligible to receive a portion of transaction fees.
* If a node is anonymous (by choice or config), this method will return `null` or an error.
* This is helpful when you want to:
* Confirm that you're using a node with an active `epAddress` (i.e. one that can earn rewards)
* Check your own node's identity
* Configure infrastructure (e.g. wallet or service backend) to target a specific earning node
**Example Request :**
```bash
curl --data '{
"method":"graphite_getEpAddress",
"params":[],
"id":1,
"jsonrpc":"2.0"
}' \
-H "Content-Type: application/json" \
-X POST https://entrypoint-test-1.atgraphite.com
```
#### Example Response:
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": "0xb95BB87CC1CEE567185ECf61E0C1B5DF19a6e120"
}
```
# Public UI-Kit
**Graphite interface design requirements**: [**UI-kit in Figma**](https://www.figma.com/design/jeovN6z2XhRVvcHDMsFBYK/Graphite-ui-kit?node-id=196-2658\&t=MBFRDI8Cow8GvTly-1)
## Layout and style
### **Layout**
In Graphite we use classic layout with header and footer. Content can be structured in any way within the grid framework.
### **Main breakpoints**
**Desktop**: 1400 px – 1200 px
**Tablet**: 1200 px – 768 px
**Mobile**: 768 px – 360 px
### **Grid**
Columns
Gutter
Side margins
Top/bottom margins
Content weight
Device
12
24px
80px
64px
1200px (max)
Desktop
8
24px
24px
64px
full (max 1152px)
Tablet
4
16px
16px
48px
full (max 736px)
Mobile
### **Corner radius**
Blocks in the interface, controls, and highlighted areas use border radius as follows:
* **Labels**: **2px** — for small ui-elements
* **Inputs**: **4px** — main radius for elements 48 pixels and smaller
* **Small blocks and controls**: **8px** — a universal radius for most UI elements.
* **Large blocks and pop-ups**: **16px** — used for modals and maintains a balanced proportion between element size and rounding.
### **Module**
The 8-pixel module is the basic dimensional unit of Graphite interfaces. The module is used to build typography and controls, select sizes for icons, and calculate indents between elements.
For sizes up to 40 px, a half-module step is acceptable: 0.5 module = 4 px, for sizes smaller than 24 px — 0.25 module = 2 px.
> *We use the module wherever it doesn't compromise aesthetics or common sense. The module is a practical design guide — it helps define sizes and spacing, but it’s not an absolute rule. Layouts don’t need to rigidly follow the 8-pixel grid.*
## Colors and typography
### **Colors and mode**
Graphite uses dark mode exclusively. Main interface colors are black and gray, white for text, green — accent. The background should always be darker than other elements. If you use a modal container or backdrop layer, the inputs and other filled elements should be lighter than the background of the modal window.
### **Text styles**
#### **headline-large**
This style is intended for use **only in the first block of a webpage on desktop**, typically when:
* the section contains **only text** (no images, cards, or complex layout),
* the heading is **short** — no more than 1–2 lines,\
there are **no other dominant elements** competing for attention,
* the goal is to create a **strong, spacious, and minimal first impression**.
It works best in **hero sections** where typography is the focal point — for example, hero headlines. Avoid using this heading style in sections with multiple visual components or dense content — it may appear oversized or out of balance.
#### **headline-medium**
The main header for the desktop and can be used for tablet.
#### **headline-small**
The main header for the mobile also can be used for tablet.
#### **body-large**
This text style is used to create a **strong typographic hierarchy** and guide the reader’s attention. It serves two main purposes:
* **Introductory paragraph in articles or long-form content**\
Used as a **lead paragraph** to set the tone and provide context before the main body text. It should be concise, readable, and visually distinct from regular paragraphs.
* **Subheading beneath a headline-large**\
When paired with a headline-large, this text functions as a **supportive subtitle** — offering additional context or clarifying the message without competing in visual weight.
#### **body-big**
Basic text for descriptions inside cards, modal windows and pop-ups, can be used on all resolutions.
#### **body-medium**
Used for texts inside elements — toggles, inputs for small resolutions, texts in tooltips, in pairs with radio buttons.
#### **body-small**
Used for text labels.
#### **button-big and button-small**
Used for buttons according to size.
## Icons
Graphite interfaces use material design icons with rounded corners with outlining and without filling.
There are four main icon sizes — 12px, 16px, 20px, 24px. Icons could be scaled to other sizes inscribed in the module system.
## Buttons and links
The name of the button is capitalized. The name of the button should be clear and concise, fitting completely within the button boundaries. Do not abbreviate button labels unless the full meaning is immediately clear.
There are 2 standard button sizes — big and small.
* **Small** — when the button is next to small input fields or other types of buttons.
* **Big** — use as main screen or form buttons to save and cancel, move to the next screen.
### **Text buttons**
There are 3 types of text buttons — primary, secondary and plane.
* **Primary button** — represents the **main action** on a screen, section, or component. It draws the most attention and guides the user toward the intended outcome.
> **Primary scenarios**: main CTA on the page or section, highlighting the next step in a flow, single action within a component, destructive confirmation (with visual caution).
* **Secondary button** — used for non-primary actions: actions that are important but not the main focus of the current screen or block.
> **Primary scenarios**: in a pair with a primary CTA, as a standalone action in low-attention areas, for repeated/utility actions, inside components with visual hierarchy.
* **Plain button** — a low-emphasis, minimal button style. It visually resembles a text link, but functions as a button for actions, not navigation.
> **Primary scenarios**: lightweight or secondary actions within components, inline actions within copy or content, supplementary actions in forms or modals.
The name of the button can be complemented with an icon. It helps find the desired button faster and understand its function at a glance. For buttons with an icon apply the same rules as for buttons without an icon.
### **Icon buttons**
Icon buttons are compact, visual-only buttons used for clear, self-explanatory actions. They contain only an icon, without a label, and are designed for high-recognition, low-ambiguity actions. **Only use icon-only buttons for well-known actions — don’t assume users will guess less common ones.**
> **Primary use cases**: essential utility actions (search, copy, close), compact placement in tight UI (edit, delete, clear input).
### **Input Buttons**
Input buttons are small action buttons placed next to input fields, usually inside or beside number or token inputs. They help users quickly insert a contextual value.
> **Common use cases**: set max/min value, quick actions like “Paste”, “Clear”.
### **Links**
Links are used to navigate between pages, sections, or external resources. Different link styles help distinguish their purpose and importance. There are 4 types of links — external link, inner primary link, inner secondary link and socials.
* **External link** — used for links that lead outside the product or ecosystem. Opens in a new browser tab, accompanied by an external link icon.
* **Inner primary link** — used for important internal links within the product or ecosystem. May lead to key pages, styled with accent color to stand out, can be used inline or as part of navigation elements.
* **Inner secondary link** — used for less prominent internal links — still important, but not part of the main flow. Often used in footers, legal blocks, or secondary content, styled more subtly (neutral or gray tones).
* **Social link** — an icon-based link that directs to a company’s social media profile. Opens in a new tab, uses in personal accounts.
> ***Note**: Social links are used to direct users to the company’s official social media profiles. They are styled and behave like secondary icon buttons, not like social links.*
### **Checkboxes**
Use checkboxes for:
* Selecting items from a list. For example, choosing multiple documents for bulk actions.
* Selecting options or preferences. For example, enabling notifications and choosing specific cases when notifications should be sent.
Checkboxes do not trigger an action immediately. Typically, the user needs to press a separate confirmation button to apply the change. If an action needs to happen instantly, a toggle is a better choice.
The checkbox is vertically aligned with the center of the first line of the text it belongs to. If the text spans multiple lines, the checkbox is aligned to the top edge of the text container.
### **Radio buttons**
Use a radio button group when there are only a few options — typically 2 to 5. Radio buttons are vertically aligned with the center of the text line.
> ***Note**: if there are 5 to 25 options, a dropdown is more appropriate.*
## Tabs and toggles
### **Tabs**
Tabs are used for secondary navigation, and for grouping or filtering content.
Do not use tabs to switch between states — use radio buttons, toggles, or switches instead.
There are 3 types of tabs — tab with background and icon, text tab with background, plain text tab.
When to use each type:
Tabs with background are used to switch between sections of content within a page — for example, multiple tables or data views. They should not be used inside other components (like modals). In those cases, use plain text tabs instead.
* **Tab with background and icon** — used when there are only a few tabs (up to 5). The icon helps reinforce the meaning of the text but adds visual noise, so it’s not recommended for large sets.
* **Text tab with background** — no icon is preferred when there are more than 5 tabs, to maintain a cleaner and more readable layout.
* **Plain text tab** — used when tabs appear inside another component, such as a modal window. These tabs can also be placed outside the visual bounds of the component they control.
#### Best practice
Tab styles are flexible — choose the version that fits your layout best while maintaining usability and clarity. Tabs should be easy to use and understand, but should not create unnecessary visual noise.
### **Toggles**
A toggle is used to switch between two states, such as changing the payment currency or switching a content view. Functionally, a toggle is similar to a checkbox, but the context of use is different: toggles are larger and more visually prominent than checkboxes. Ideally, a page should contain no more than 1–2 toggles, with 3 as a maximum.
There are two types of toggles:
**Big toggle** — used when the label is longer — typically 1–3 words, can be placed as a standalone UI element, works well in settings panels or feature switches.
**Small toggle** — used when the label is short such as an abbreviation or icon, best suited for compact interfaces like modals or dropdowns.
Toggles are best used when both states are clearly understood by the user (e.g., On/Off, USD/EUR). The change takes effect immediately. If confirmation is required, use a checkbox and button instead.
## Inputs
There are 2 main types of input fields — standard input fields and search fields with advanced behavior.
### **Standard Input Field**
Used in forms and feedback blocks to collect user data such as email, wallet address, phone number, etc.
Primary use cases:
* can be used with or without a label, but always includes a placeholder
* always includes a clear icon (a cross) to reset the field
* supports various input types: text, email, number, etc.
* used in contact forms, wallet connections, account creation, etc.
### **Search Field**
Used as a standalone UI element, not typically placed inside other components like pop-ups or forms.
Primary use cases:
* taller than a standard input field (on desktop)
* may include a dropdown state — recent search history, autocomplete suggestions, country/region code selectors
* can be full-width inside content container for better usability
* designed for dynamic interaction, not static form submission
Use search fields when the user expects real-time feedback and standard input fields for structured data collection with or without submission confirmation.
> ***Note:** when an input field is placed next to a button, it's important that they are the same height to ensure visual consistency and alignment.*
## Dropdowns
The element that opens a dropdown list visually resembles a button, but behaves differently — does not trigger an action immediately, is used alongside other input fields. This component is best used when the user needs to choose one option from a list, especially in form-like contexts.
Dropdown panel behavior
* The dropdown panel is aligned to the right edge of the trigger button, but may stretch to full width if needed.
* The panel has a shadow to separate it from the background.
* Items inside the dropdown are left-aligned.
* The selected item is highlighted with a gray background.
* Items can include labels and icons to provide additional context.
## Labels
Text labels are small UI elements used to indicate status, type, or category of an object. They are compact, text-based, and serve a semantic and visual tagging function.
Purpose and usage
* Indicate the status of a process or item (e.g., “Pending”, “Success”, “Failed”)
* Show type or category (“Wallet”, “Beta”, “Layer 2”)
* Can be used in lists, cards, tables, or inline with content
Visual style — use the smallest text size available (e.g., body-small). Labels include a background fill and 2px rounded corners.
\
**Label types**
* **Neutral (gray) labels** — used for generic tags
* **Colored status labels** — reflect specific states in a process
Labels should be short and readable, usually 1–2 words, and never behave like interactive elements.
## Tooltips
A tooltip is a small informational element that provides contextual help or explains the state of a control.
**Behavior**
* Appears on hover over an interface element
* Should remain visible when the cursor moves from the target to the tooltip itself
* Should disappear only when the cursor leaves both the target and the tooltip
**Size & Placement**
* The tooltip can appear in any direction, depending on available space and layout
* There must be a 4px gap between the tooltip and the element that triggered it
* The tooltip should not span the full width of the screen, the maximum width of a tooltip is 280px
**Content**
* Use body-medium or body-small text styles inside the tooltip, depending on content length and importance, keep the message concise, informative, and easy to scan.
* The text inside a tooltip should always be left-aligned, regardless of the tooltip’s position on screen.
Tooltips should help users understand interface elements without overwhelming them. Use them only when necessary and never for critical information.
## Notifications
To notify users, you can use either a toast or a modal window, depending on the context.
**Toasts** are used for brief, non-intrusive messages — such as status updates or confirmations. They appear in the top-right corner of the screen. Toasts can contain a short message and and may include a link or action button if needed.
**Behavior**
* A toast with short text only automatically disappears after 5 seconds
* If the toast includes a link, button, or a loading indicator, it remains visible until the user dismisses it
**Modals** are used for secondary content that’s only relevant in certain situations or when you need to focus the user's attention on a specific action.\
\
**Behavior**
* Appears on top of the current page
* The background is dimmed to reduce distraction
* The user must interact with the modal before continuing
## Keyboard Navigation & Focus State
Focus state indicates that an element is active and can be interacted with using the keyboard. It is essential for accessibility and keyboard navigation.
### **Focus Outline**
* The focus state is shown as a 1px outline in the appropriate color
* The corner radius of the focus outline matches the element’s existing border radius
* If the element has no border radius (e.g. a plain text container), a default 8px radius is applied
* If the element already has a border, the focus outline appears on top of it
### **Focus Outline Colors by Element Type**
**Green 900**
Default focus color. Used for:
* Input fields
* Dropdowns and list items
* Secondary icon buttons
* Input clear buttons and copy buttons
* Tabs and toggles
* Any element with a gray background or no background
**White 500**
Used when the element has a green background. Applied to:
* CTA buttons (green 500 background)
* Clickable green icons
* Links on dark backgrounds
**Green 500**
Used for:
* Secondary buttons
* Plain buttons
# Graphite Nodes
{% hint style="success" %}
If you are interested in becoming a validator, please contact us at ****.
{% endhint %}
Graphite has three key types of nodes on its network:
* Entry-point (Transport) Nodes
* Authorized Nodes
* Graphite Foundation Nodes
Each type helps to ensure high network performance and practical usability.
## Transport Nodes Income
Usually, standard transport nodes do not earn incomes on blockchains. So, one of Graphite’s key unique features is that it actually allows its regular entry-point transport nodes to earn an income. Put simply, it is easy to create a transport node and start earning by allowing Graphite users to send transactions to the network from your node.
Income for Entry-Point Nodes; How It Works Step-by-Step:
* The transaction sender includes the ‘originating node’ address in the data field of the transaction
* The transaction is not accepted by the entry-point node if the ‘originating node’ differs from the actual node's address
* After the block containing the transaction is sealed, the entry-point node is rewarded with 50% of the transaction fee (i.e. the fee). The other 50% goes to the authorized node serving as a block sealer.
## Income for Entry-Point Nodes
> Entry-point nodes in Graphite are transport nodes that also act as initial points of transaction entry to the network. Unlike any other blockchain, Graphite allows its entry-point nodes to earn an income from part of the transaction fee. This feature of the network makes it possible for users to start making an income as an entry-point node without the need for huge server resources.
The income for transport nodes in Graphite is technically achieved by adding a field for the incoming node address to a transaction record. When a user fills this field with a valid "originating node" address, the transaction fee will be the standard rate (i.e. the lowest possible fee). On the other hand, the fee for anonymous transactions (i.e. without a complete ‘originating node’ address) will be increased; but, to be clear, we do not in any way prohibit anonymous transactions.
The "originating node" address is necessary for a transport node to receive its reward for the initial admission (i.e. point of entry) of a transaction to the Graphite network. The address of the "originating node" essentially serves as an identifier for the node set to receive the income. Of course, this system inevitably decreases anonymity since everybody on the network will see a particular node related to a specific transaction. But, realistically, most users have no interest in these matters and simply choose the node (i.e. wallet provider) that is the closest and provides the best services.
{% hint style="info" %}
For users who value anonymity and privacy, it will be possible to create a Graphite transport node and use it to send transactions with no "originating node" data; again, Graphite doesn’t make them reveal which node was used as an entry point for a transaction if the user does not wish to reveal it.
In other words, in order to earn money, Graphite network participants should focus on providing great performance and user experience by acting as an entry-point node for other user transactions instead of simply performing pointless and wasteful calculations. We believe this is the best way forward for any blockchain transaction system.
{% endhint %}
## Authorized Nodes
> Authorized nodes on the Graphite network are responsible for the validation of new blocks. The pool of authorized nodes consists of compliant, authorized nodes and Graphite Foundation nodes which are always available.
Graphite-authorized nodes are the primary core of the network and act as block validators. For a server to become a compliant, authorized node on the Graphite network, it must pass a compliance test.
The compliance test for authorized nodes will be described in detail in a dedicated document. For now, we will note that the compliance process involves:
* Passing the highest level KYC verification
* Technical requirements, including:
* SLA for 99.9% server uptime;
* A server hosted in a Tier 3 or Tier 4 data center or higher;
* High server speed and performance;
* 2TB SDD.
After becoming a legitimate authorized node, the node will be able to validate blocks and earn income.
Graphite will take note of its nodes with the best and worst performances and implement a mechanism to reward authorized nodes for good performance.
## Graphite Foundation Nodes
> Graphite Foundation nodes are meant to ensure that the Graphite network is live and functioning in any situation (even when all other nodes are down). 16(incl. 7 validators) high-level Graphite Foundation nodes, managed and maintained by the Graphite Foundation, will support the uptime of the Graphite network.
# Graphite testnet node setup
### Requirements
Make sure you have the latest docker installed.\
Make sure you have opened and not binded with other applications 8575/tcp, 30311/udp ports in order to communicated with node via rpc endpoint(8575) and also node can communicate with other nodes in network via p2p(30311). Websocket modules avialable at 8576 port. Also make sure you dont covered by nat or any other network stuff.
In order to run localy with docker you need to create folder for persist data inside container.
```bash
mkdir graphite-data
chown 10001:10001 graphite-data
```
\
After creating folder you need to run init task to inject genesis and persist it. You can do it with following command:
{% code overflow="wrap" %}
```bash
docker run -it -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3-testnet /bin/sh init-genesis.sh
```
{% endcode %}
### Anonymous entrypoint node setup instructions
Now you can run your node. In order to do it use following command:
{% code overflow="wrap" %}
```javascript
docker run -d --name graphite-testnet --network host -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3-testnet geth --datadir /home/geth/data --config /home/geth/config.toml
```
{% endcode %}
### Keyed entrypoint node setup instructions
Prepare your public key for inject into entrypoint with flag --epaddr. In example we will be using 0x8D1Ee942A92645136c81271460fD7Ec5375B30cC address. Now you can run your node. In order to do it use following command:
{% code overflow="wrap" %}
```javascript
docker run -d --name graphite-testnet --network host -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3-testnet geth --datadir /home/geth/data --config /home/geth/config.toml --epaddr 0x8D1Ee942A92645136c81271460fD7Ec5375B30cC
```
{% endcode %}
Node rpc api is avaialable at **`http://127.0.0.1:8575`**
### **Usefull commands**
You can check node sync proggress with following command. If sync is done you will sync done message if not you will see elapsed blocks:
{% code overflow="wrap" %}
```javascript
docker exec -it graphite-testnet geth --exec 'eth.syncing.currentBlock == eth.syncing.highestBlock ? console.log("sync done") : console.log("sync in progress. elapse blocks: ", eth.syncing.highestBlock - eth.syncing.currentBlock);' attach /home/geth/data/geth.ipc
```
{% endcode %}
To attach node logs:
```bash
docker logs graphite-testnet --follow
```
To interact node with graphite js console use following command:
```bash
docker exec -it graphite-testnet geth attach /home/geth/data/geth.ipc
```
# Graphite mainnet node setup
### Requirements
Make sure you have the latest docker installed.\
Make sure you have opened and not binded with other applications 8575/tcp, 30311/udp ports in order to communicated with node via rpc endpoint(8575) and also node can communicate with other nodes in network via p2p(30311). Websocket modules avialable at 8576 port. Also make sure you dont covered by nat or any other network stuff.
In order to run localy with docker you need to create folder for persist data inside container.
```bash
mkdir graphite-data
chown 10001:10001 graphite-data
```
\
After creating folder you need to run init task to inject genesis and persist it. You can do it with following command:
{% code overflow="wrap" %}
```bash
docker run -it -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3 /bin/sh init-genesis.sh
```
{% endcode %}
### Anonymous entrypoint node setup instructions
Now you can run your node. In order to do it use following command:
{% code overflow="wrap" %}
```bash
docker run -d --name graphite-mainnet --network host -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3 geth --datadir /home/geth/data --config /home/geth/config.toml
```
{% endcode %}
### Keyed entrypoint node setup instructions
Prepare your public key for inject into entrypoint with flag --epaddr. In example we will be using 0x4a0bfdAB7306b2Df31E26aF20fC423803625E4b6 address. Now you can run your node. In order to do it use following command:
{% code overflow="wrap" %}
```bash
docker run -d --name graphite-mainnet --network host -v ./graphite-data:/home/geth/data ghcr.io/atgraphite/graphite:v1.3.3 geth --datadir /home/geth/data --config /home/geth/config.toml --epaddr 0x4a0bfdAB7306b2Df31E26aF20fC423803625E4b6
```
{% endcode %}
Node rpc api is avaialable at **`http://127.0.0.1:8575`**
### **Usefull commands**
You can check node sync proggress with following command. If sync is done you will sync done message if not you will see elapsed blocks:
{% code overflow="wrap" %}
```bash
docker exec -it graphite-mainnet geth --exec 'eth.syncing.currentBlock == eth.syncing.highestBlock ? console.log("sync done") : console.log("sync in progress. elapse blocks: ", eth.syncing.highestBlock - eth.syncing.currentBlock);' attach /home/geth/data/geth.ipc
```
{% endcode %}
To attach node logs:
```bash
docker logs graphite-mainnet --follow
```
To interact node with graphite js console use following command:
```bash
docker exec -it graphite-mainnet geth attach /home/geth/data/geth.ipc
```
# Graphite Wallet
Graphite Wallet is an extension for accessing Graphite Network features and apps on Ethereum-compatible chains in your Chrome browser.
{% stepper %}
{% step %} **`Connect Graphite Wallet`**
Install the Graphite Wallet extension, create a new wallet or import mnemonic and come up with a password.
{% endstep %}
{% step %} **`Activate your account`**
Finish your preparations by hopping onto the Account Settings page and activating your account with a simple transaction.
{% endstep %}
{% step %} **`Explore!`**
Your account is good to go - feel free to tinker with your account settings, pass KYC measures, become a validator and put the Graphite Network to the test!
{% endstep %}
{% endstepper %}
***
{% embed url="" %}
Graphite Wallet
{% endembed %}
# Graphite Web3 Documentation
## Basic Usage
* Detect the provider (**`window.graphite`**)
* Call the **`window.graphite.enable()`** method
* If access is granted, use the available api
## Available methods
### graphite.enable(): Promise\
Calling this method triggers a user interface that allows a user to approve or reject account access for a given dApp. This method returns a Promise that is resolved with an account if the user approves access or is rejected with an Error if the user rejects access.
```js
await window.graphite.enable()
// If success:
// => 0xca8a66887dfbEf870a2d96de536986516a37fa12
// If regected:
// throw Error {
// "code": -1,
// "message": "User rejected the request."
//}
```
### graphite.isEnabled(): Promise\
Returns true if the dApp is already connected to a user's wallet, or if requesting access would return true without user confirmation (e.g. the dApp is whitelisted), and false otherwise.
```js
await window.graphite.isEnabled()
// => true
```
### graphite.request(): Promise\