adex-protocol-eth

Ethereum implementation of the AdEx protocol: payment channels + Identity

Showing:

Popularity

Downloads/wk

6

GitHub Stars

32

Maintenance

Last Commit

20d ago

Contributors

14

Package

Dependencies

7

Size (min+gzip)

179.3KB

License

MIT

Type Definitions

Tree-Shakeable

No?

Categories

Readme

adex-protocol-eth

The Ethereum implementation of the AdEx Protocol.

This replaces adex-core.

This repository implements OUTPACE (off-chain unidirectional trustless payment channel) and a gas abstraction layer called AdEx Identity.

Please note

  • Every channel will eventually expire (after validUntil), allowing the non-withdrawn portion of the initial deposit to be received back by whoever opened the channel.
  • Channels can be created with any ERC20 token; if the underlying token of a channel is insecure or malicious, that also compromises the channel as well; this is out of scope of this contract, since this is a fundamental issue with any system that uses ERC20s; needless to say, the user needs to be aware of what token they're using/earning
  • For more details on how OUTPACE channels work, please read the specs: AdEx Protocol and OUTPACE.

Testing

First, run ganache-cli in a separate terminal

truffle build # This is important cause js/IdentityProxyDeploy uses artifacts from there
npm test

Deployment

The contract AdExCore from version v3.1.0, compiled with solc v0.5.6 is deployed here:

An Identity, initialized with no privileges, to be used as a basis for IdentityProxy:

An IdentityFactory, set up with the AdEx relayer:

And the Registry (now obsolete, no longer used):

v4.1

All contracts here were compiled with solc v0.5.13.

The Identity, initialized with no privileges, to be used as a basis for IdentityProxy:

An IdentityFactory, set up with the AdEx relayer:

And the Staking:

v4.2

The ADXSupplyController contract:

The ADXToken contract:

An instance of IdentityFactory used for staking:

The Staking contract:

The ADXFlashLoans contract:

The ADXLoyaltyPoolToken contract:

The ADXLoyaltyPoolIncentiveController contract:

v5

The SupplyController contract:

New V5 SupplyController (increased cap to account for the to-be burned staking migration ADX):

StakingPool:

StakingMigrator:

GaslessSweeper:

Wallet

IdentityFactory contract:

Identity contract:

Deployment strategy

The full deploy processis as follows

  • Deploy AdExCore
  • Deploy an IdentityFactory
  • Deploy a single Identity, with no owners and no registry
  • Deploy a Staking

Verifying on etherscan

truffle compile
cat build/contracts/AdExCore.json | jq '.bytecode' # this is the bytecode you have to deploy
./scripts/bundle.sh contracts/AdExCore.sol # this will output a bundled .sol code

Gas usage, from the tests

Measured with solc v0.5.6, commit d80fa80424ef7b8932399424f8d919d67b135a30

channelOpen: 69961
channelWithdrawExpired: 70470
channelWithdraw: 137117
execute: 89900
execRoutines: 114440
channelOpen, through execute: 115086
deploying an identity proxy through the IdentityFactory: 127549
addBond  73404
requestUnbond  34807
unbond  41770

ENS

This is not a part of the adex-protocol-eth source code, but it may be useful for anyone building on top of adex-protocol-eth who wishes to integrate with ENS.

  • ENS Contract mainnet address: 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e
  • ENS PublicResolve mainnet address: 0x226159d592E2b063810a10Ebf6dcbADA94Ed68b8
  • adex.eth node hash: 0x4e4e818e9467df5c5d1f8c399b11acc73ea24ad69e9c8e1ba6e5784a302c47d4
  • adex.eth subdomain registrar (adex.eth controller), compiled with solc v0.5.6: 0x7bc082552b1a195813ddb500600ce2b544d579cb

Code style and design principles

  • Minimalistic use of smart contracts in general
    • Avoid putting logic in SCs if it's outcome is controlled by a single entity anyway
    • Do not add complexity and centralization to address various "what ifs" that should be addressed off-chain, e.g. "what if users send tokens to this contract by accident"
  • Detailed tests for every contract
  • No Solidity warnings allowed
  • No modifiers allowed
  • Limited use of inheritance
  • No reentrancy guards allowed, instead we use the Checks-Effects-Interactions pattern
  • All requires should have an error message
  • No delegatecall upgradability; upgradability is achieved via off-chain social consensus
  • No emergency stops or pausability: it dilutes the value of smart contracts

Audits

Credits

Rate & Review

Great Documentation0
Easy to Use0
Performant0
Highly Customizable0
Bleeding Edge0
Responsive Maintainers0
Poor Documentation0
Hard to Use0
Slow0
Buggy0
Abandoned0
Unwelcoming Community0
100