Noble is a Cosmos application-specific blockchain purpose-built for native asset issuance. Noble brings the efficiency and interoperability of native assets to the wider Cosmos ecosystem, starting with USDC. Noble’s vision is to be the world’s premier issuance hub for digital assets that connect to other blockchains seamlessly. Noble leverages the Cosmos-SDK – a flexible toolkit that allows developers to leverage existing modules, and to seamlessly integrate custom modules that add virtually unlimited functionality for asset issuers onthe Noble blockchain.
The Noble app-chain conforms to industry standard smart contracting capabilities with regards to asset issuance functionality. This functionality allows the minting and burning of tokens by multiple entities and the freezing blacklisting of addresses on the Noble chain.
Key authorities include:
Owner: The Owner role has the ability to reassign all roles and will be held by the asset issuer.
Minter: The Owner has the authority to add/remove Minters which have the authority to both mint and burn tokens on the Noble chain.
Blacklist: The asset issuer has the authority to blacklist addresses. A blacklisted address will be unable to transfer tokens outside of the Noble chain via IBC, or to approve, mint, or burn tokens.
Noble implements a tokenfactory module pattern to enable the minting of generic assets in Cosmos. Further, tokenfactory modules are under the exclusive purview of the asset issuers and are separate and distinct from governance of the Noble chain. Additionally, each tokenfactory module is distinct from one other as they each house unique access controls with ownership over the minting and burning of a specific asset.
The Access Control table below shows the functionality tied to each privileged account.
| Owner | Minter | Master Minter | Minter Controller | Pauser | Blacklister | Is Paused (Actions Allowed) |
|
|---|---|---|---|---|---|---|---|
| Blacklist | x | x | |||||
| Unblacklist | x | x | |||||
| Burn | x | ||||||
| Mint | x | ||||||
| Add Minter Controller | x | x | |||||
| Add Minter with allowance | x | x | |||||
| Pause | x | x | |||||
| Unpause | x | x | |||||
| Remove Minter Controller | x | x | |||||
| Remove Minter | x | x | |||||
| Update Blacklister | x | x | |||||
| Update Master Minter | x | x | |||||
| Update Owner | x | x | |||||
| Update Pauser | x | x | |||||
| Transer Tokens (tokenfactory asset) | x | x | x | x | x | x | |
| Transer Tokens (non-tokenfactory asset) | x | x | x | x | x | x | x |
The initial plans for Noble’s go-to-market entailed leveraging Replicated Security (also known as "Interchain Security”) – the shared security model of the Cosmos Hub. This feature allows validators to secure app-chains using the value of ATOMs staked by Cosmos Hub delegators. Due to uncertainty around the design of replicated security (e.g., the removal of automated slashing packets), Noble has paused integration with Replicated Security.
At launch, Noble will be a Proof of Authority chain with a trusted validator set (a subset of Cosmos Hub validators). The validator set will be permissioned by equal shares of staking tokens placed in vesting accounts. The tokens will have no value. Economic security will derive from fees captured by the chain in USDC and other assets on a block-by-block basis. If a double sign is detected by the chain, the validator address will be “tombstoned,” meaning that their tokens and the address will no longer be usable for validation and resulting in the loss of all future fee revenue. The Proof of Authority model provides real economic cost to faulty validator behavior and thus provides economic security to the network that can be computed in real time based on past and projected fees.
Noble intends to monitor developments in shared security across the blockchain ecosystem to ensure the optimality of the security model.
App-chains are able to permissionlessly connect to Noble via IBC, a universal interoperability protocol that allows two different blockchains to communicate with one another, garaunteeing reliable, ordered, and authenticated communication.
How to integrate with Noble?
To establish a connection to Noble (or any 2 IBC compatible chains), developers will be required to set up a relayer on an existing path. This tutorial gives an overview of how to create a channel, client, and connection and to start relaying IBC packets.
The Noble blockchain (“Noble”) will house a module, referred to as the Noble Maintenance Multisig (or “NMM”), that has the following three functionalities:
- Upgrade authority
- Parameter Changes
- IBC maintenance
Upgrade Authority
A standard multisignature application (the “Noble Multisig”) will form the Noble Maintenance Multisig (“NMM”) which will be able to initiate a chain upgrade when a breaking protocol change requires upgrading the chain binary. The NMM will use an on-chain procedure to instruct the validators to halt the protocol running the Noble chain and which will restart the blockchain with a new binary. Importantly, validators have discretionary authority to follow those instructions. If 1/3 + 1 of the voting power of the Noble chain refuses to follow these upgrade instructions, the chain halts.
Parameter Changes
The NMM has the ability to initiate parameter changes. This authority is distinct from the upgrade functionality as it would not require the Noble validators to run a new chain binary. A parameter change would automatically be introduced into the state machine of the Noble chain.
IBC Connection Maintenance:
The NMM has the ability to both re-establish IBC connections that have expired as well as sever IBC connections. Any such action related to an IBC connection is achieved automatically upon execution by the Noble Multisig. This documentation further outlines situations where IBC maintenance would be required.
Configuration of NMM
The NMM is a 5/7 multisig for passing a Noble Multisig proposal to fulfill the three key functions discussed above. The configuration of the Noble Multisig will include the Noble corporate entity and core validator partners. A key objective of the NMM is to achieve a reasonable level of geographic diversity among Noble Multisig members for resilience. The proposed geographies are noted as follows:
- Noble (the organization): Canada
- Iqlusion: USA
- Strangelove: USA
- Chorus One: Switzerland
- Binary Holdings: Switzerland
- Cosmostation: Korea
- EverStake: Ukraine/ Austria
Stakeholders on the NMM will be able to be rotated in and out of the mulitisg over time.
Noble has selected StrangeLove Labs (“StrangeLove”) as its initial engineering and product partner to implement Noble’s initial app-chain design. StrangeLove has built an MVP and is bringing it to market using battle-proven XP-derived practices like Test-driven Development, Continuous Integration and Continuous Deployment, and short iteration cycles.
In collaboration with StrangeLove, Noble intends to build an in-house team focused on software development and integration to further build the Noble vision related to products and services.
TWITTER: @noble_xyz
WEB: nobleassets.xyz
go will be needed for this install
make install
Come up with a moniker for your node, then run:
nobled init $MONIKER
Prior to launch, some config settings are required by the tokenfactory module in the genesis.json file:
- There must be a designated address for the "owner" role.
- Other roles, such as
masterMinter,blacklister, andpauserare optional at genesis. mintingDenommust be filled out and thedenomspecified must be registered indenom_metadata
tokenfactory Example:
"tokenfactory": {
"params": {},
"blacklistedList": [],
"paused": {
"paused": false
},
"masterMinter": {
"address": "noble1x8rynykqla7cnc0tf2f3xn0wa822ztt70y39vn"
},
"mintersList": [],
"pauser": {
"address": "noble1g3v4qdc83h6m5wdz3x92vfu0tjtt7e6y48qqrz"
},
"blacklister": {
"address": "noble159leclhhuhhcmedu2n8nfjjedxjyrtkee8l4v2"
},
"owner": {
"address": "noble153eyy4uufmrak2swgrn4fjtyslg256ecdngyve"
},
"minterControllerList": [],
"mintingDenom": {
"denom": "urupee"
}
}denom_metadata example:
"denom_metadata": [
{
"display": "rupee",
"base": "urupee",
"name": "rupee",
"symbol": "rupee",
"denom_units": [
{
"denom": "urupee",
"aliases": [
"microrupee"
],
"exponent": "0"
},
{
"denom": "mrupee",
"aliases": [
"milirupee"
],
"exponent": "3"
},
{
"denom": "rupee",
"aliases": null,
"exponent": "6"
}
]
},
]nobled start
- See
noble-networksfor all info around validating for mainnet and testent
The interchaintest test suite has been imported into the noble repo. Tests can be ran and written here.
To quickly spin up a standalone noble chain and setup all privileged accounts, run the play.sh bash script.