- Concepts
- Backends
- Javascript
- Rust
- Go
- Python
- Smart contract
- Program
- Javascript bindings
ACCESS Protocol lays the foundation for digital content monetization using a web3 wallet. Users get access to content by staking ACCESS tokens (through their StakeAccount
) into the content publisher's pool (StakePool
). ACCESS tokens are distributed to stakers and content publishers through an inflation schedule defined in the CentralState
.
The protocol also has the possibility to create and sell bonds (BondAccount
). Bonds allow the protocol to sell locked tokens with linear vesting. The locked tokens can be staked and used to access content of a staked pool.
Publishers need to adapt their backend infrastructures to support authentication and authorization via a web3 wallet. This authentication process relies on signature verifications and a demo example is implemented in the backends
folder in JS, Rust, Go and Python.
The backends
folder contains an example implementation of a REST API using a Solana wallet for authentication and JWT authorization. The example is implemented in Javascript, Rust, Go and Python.
It is strongly recommended to use either the Javascript or Rust implementation as these two language have the best Solana tooling.
The smart contract folder contains two subfolders: js
and program
.
The program
folder contains the Solana smart contract code, documentation can be generated using Rust doc
cargo doc
functional.rs
test can be run using Solana program test
BPF_OUT_DIR=target/deploy cargo test-bpf --features days-to-sec-10s no-mint-check no-bond-signer --test functional
Other Rust tests can be run using
BPF_OUT_DIR=target/deploy cargo test-bpf --features no-mint-check no-bond-signer -- --skip functional_10s
The js
folder contains the Javascript bindings of the smart contract. This package is published on NPM
npm i @access-protocol/js
yarn add @access-protocol/js
End to end tests are implemented using jest
, they can be run using
yarn amman:start
yarn jest
This will:
- Spawn a local solana test validator via Amman
- Deploy the program
- Run all the instructions of the protocol
- Verify the states of each account at each step
- Cannot create two bonds tied to a different pool with the same amount
- Bond functionality is counterintuitive
- Bond unlocking does not start at
unlock_start_date
, but atunlock_start_date + unlock_period
- If bond is claimed after the
unlock_start_date
, the offset of unlock times is counted relative to this date instead of theunlock_start_date
- Bond unlocking does not start at