Please contact the owner of the site that linked you to the original URL and let them know their link is broken.
-
+
diff --git a/assets/js/7bf9570a.d3e4c331.js b/assets/js/7bf9570a.d3e4c331.js
deleted file mode 100644
index e5ef6e64b1..0000000000
--- a/assets/js/7bf9570a.d3e4c331.js
+++ /dev/null
@@ -1 +0,0 @@
-"use strict";(self.webpackChunkbeta_BNB_Docs=self.webpackChunkbeta_BNB_Docs||[]).push([[6980],{3905:(e,n,t)=>{t.d(n,{Zo:()=>p,kt:()=>b});var o=t(67294);function s(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function r(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);n&&(o=o.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,o)}return t}function a(e){for(var n=1;n=0||(s[t]=e[t]);return s}(e,n);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(s[t]=e[t])}return s}var i=o.createContext({}),l=function(e){var n=o.useContext(i),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},p=function(e){var n=l(e.components);return o.createElement(i.Provider,{value:n},e.children)},d="mdxType",m={inlineCode:"code",wrapper:function(e){var n=e.children;return o.createElement(o.Fragment,{},n)}},u=o.forwardRef((function(e,n){var t=e.components,s=e.mdxType,r=e.originalType,i=e.parentName,p=c(e,["components","mdxType","originalType","parentName"]),d=l(t),u=s,b=d["".concat(i,".").concat(u)]||d[u]||m[u]||r;return t?o.createElement(b,a(a({ref:n},p),{},{components:t})):o.createElement(b,a({ref:n},p))}));function b(e,n){var t=arguments,s=n&&n.mdxType;if("string"==typeof e||s){var r=t.length,a=new Array(r);a[0]=u;var c={};for(var i in n)hasOwnProperty.call(n,i)&&(c[i]=n[i]);c.originalType=e,c[d]="string"==typeof e?e:s,a[1]=c;for(var l=2;l{t.r(n),t.d(n,{assets:()=>i,contentTitle:()=>a,default:()=>m,frontMatter:()=>r,metadata:()=>c,toc:()=>l});var o=t(87462),s=(t(67294),t(3905));const r={},a="WebSocket Connections",c={unversionedId:"beaconchain/develop/api-reference/dex-api/ws-connection",id:"beaconchain/develop/api-reference/dex-api/ws-connection",title:"WebSocket Connections",description:"Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries.",source:"@site/docs/beaconchain/develop/api-reference/dex-api/ws-connection.md",sourceDirName:"beaconchain/develop/api-reference/dex-api",slug:"/beaconchain/develop/api-reference/dex-api/ws-connection",permalink:"/docs/beaconchain/develop/api-reference/dex-api/ws-connection",draft:!1,editUrl:"https://github.com/bnb-chain/bnb-chain.github.io/blob/master/docs/beaconchain/develop/api-reference/dex-api/ws-connection.md",tags:[],version:"current",frontMatter:{},sidebar:"bscSideBar",previous:{title:"Staking API",permalink:"/docs/beaconchain/develop/api-reference/dex-api/staking"},next:{title:"WebSocket Streams",permalink:"/docs/beaconchain/develop/api-reference/dex-api/ws-streams"}},i={},l=[{value:"Method 1: Connect with stream names in the URL",id:"method-1-connect-with-stream-names-in-the-url",level:3},{value:"Method 2: Subscribe to streams on demand",id:"method-2-subscribe-to-streams-on-demand",level:3}],p={toc:l},d="wrapper";function m(e){let{components:n,...t}=e;return(0,s.kt)(d,(0,o.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,s.kt)("h1",{id:"websocket-connections"},"WebSocket Connections"),(0,s.kt)("p",null,"Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries."),(0,s.kt)("ul",null,(0,s.kt)("li",{parentName:"ul"},"The base endpoint for mainnet is: ",(0,s.kt)("strong",{parentName:"li"},"wss://dex.binance.org/api/"),"."),(0,s.kt)("li",{parentName:"ul"},"The base endpoint for testnet is: ",(0,s.kt)("strong",{parentName:"li"},"wss://testnet-dex.binance.org/api/"),"."),(0,s.kt)("li",{parentName:"ul"},"Each connection can consume a single stream or multiple streams may be multiplexed through one connection for more complex apps."),(0,s.kt)("li",{parentName:"ul"},"All symbols in stream names are lowercase.")),(0,s.kt)("p",null,"Stream names may be provided in the URL ",(0,s.kt)("strong",{parentName:"p"},"or")," there is a mechanism to ",(0,s.kt)("inlineCode",{parentName:"p"},"subscribe")," to consume streams on demand through one connection."),(0,s.kt)("p",null,"Note: Once the connection is established, the websocket server will send ping frame to the client every 30 seconds. The client should reply with pong frame in time (this has already been implemented by most modern browsers, but programmatical users need to be aware of whether your websocket library supports this), otherwise, the connection might be closed."),(0,s.kt)("p",null,"Examples of each of these methods are provided below in JavaScript:"),(0,s.kt)("h3",{id:"method-1-connect-with-stream-names-in-the-url"},"Method 1: Connect with stream names in the URL"),(0,s.kt)("p",null,"Using this method, stream names are specified in the URLs used to connect to the data streams:"),(0,s.kt)("ul",null,(0,s.kt)("li",{parentName:"ul"},"Single streams ",(0,s.kt)("inlineCode",{parentName:"li"},"/ws/"))),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Mainnet Example:")," Various methods of connecting to streams where stream names are provided in URLs:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' // for personal streams, ex: Account & Transfers\n const accountAndOrdersFeeds = new WebSocket("wss://dex.binance.org/api/ws/");\n\n // for all symbols\n const blockHeight = new WebSocket("wss://dex.binance.org/api/ws/$all@blockheight");\n')),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Testnet Example:")," Various methods of connecting to streams where stream names are provided in URLs:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' // for personal streams, ex: Account & Transfers\n const accountAndOrdersFeeds = new WebSocket("wss://testnet-dex.binance.org/api/ws/");\n\n // for all symbols\n const blockHeight = new WebSocket("wss://testnet-dex.binance.org/api/ws/$all@blockheight");\n')),(0,s.kt)("h3",{id:"method-2-subscribe-to-streams-on-demand"},"Method 2: Subscribe to streams on demand"),(0,s.kt)("p",null,"Using this method, streams are be consumed via subscribe and unsubscribe commands, sent through a single WebSocket connection."),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Note: one connection is only allowed to subscribe to one address.")),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"}," const conn = new WebSocket(\"wss://dex.binance.org/api/ws\");\n conn.onopen = function(evt) {\n // send Subscribe/Unsubscribe messages here (see below)\n }\n conn.onmessage = function(evt) {\n console.info('received data', evt.data);\n };\n conn.onerror = function(evt) {\n console.error('an error occurred', evt.data);\n };\n")),(0,s.kt)("p",null,"After connecting successfully you can subscribe/unsubscribe to different topics."),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Example:")," To subscribe to transfer events, you should send a socket message with the ",(0,s.kt)("inlineCode",{parentName:"p"},"subscribe")," payload as below:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' const conn = new WebSocket("wss://dex.binance.org/api/ws/bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x");\n conn.onopen = function(evt) {\n // for personal topics such as accounts & transfers, an `address` is required\n // Note: one connection is only allowed to subscribe to one address.\n // If you subscribe to a new address, regardless of whether the topic is new, the subscriptions for the previous addresses will be removed.\n conn.send(JSON.stringify({ method: "subscribe", topic: "transfers", address: "bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x" }));\n }\n')),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Example:")," To unsubscribe from orders events, you should send a socket message with payloads as below:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' // unsubscribe from topic\n conn.send(JSON.stringify({ method: "unsubscribe", topic: "transfers" }));\n')),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Example:")," To extend connection life, you should send a message with a payload using the ",(0,s.kt)("inlineCode",{parentName:"p"},"keepAlive")," method:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' // This will extend the connection time to another 30 minutes\n // It\'s good to send this message every 30 minutes to maintain the connection life\n conn.send(JSON.stringify({ method: "keepAlive" }));\n')),(0,s.kt)("p",null,(0,s.kt)("strong",{parentName:"p"},"Example:")," To close a connection, you should send a socket message with a payload as below:"),(0,s.kt)("pre",null,(0,s.kt)("code",{parentName:"pre",className:"language-javascript"},' // Connections will auto close after 30 - 60 minutes if no "keepAlive" messages received\n // Connections with no subscriptions will be closed, regardless the keepAlive messages.\n conn.send(JSON.stringify({ method: "close" }));\n')))}m.isMDXComponent=!0}}]);
\ No newline at end of file
diff --git a/assets/js/7bf9570a.dc9cd1cc.js b/assets/js/7bf9570a.dc9cd1cc.js
new file mode 100644
index 0000000000..1c0c54b01d
--- /dev/null
+++ b/assets/js/7bf9570a.dc9cd1cc.js
@@ -0,0 +1 @@
+"use strict";(self.webpackChunkbeta_BNB_Docs=self.webpackChunkbeta_BNB_Docs||[]).push([[6980],{3905:(e,n,t)=>{t.d(n,{Zo:()=>p,kt:()=>b});var o=t(67294);function r(e,n,t){return n in e?Object.defineProperty(e,n,{value:t,enumerable:!0,configurable:!0,writable:!0}):e[n]=t,e}function s(e,n){var t=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);n&&(o=o.filter((function(n){return Object.getOwnPropertyDescriptor(e,n).enumerable}))),t.push.apply(t,o)}return t}function a(e){for(var n=1;n=0||(r[t]=e[t]);return r}(e,n);if(Object.getOwnPropertySymbols){var s=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,t)&&(r[t]=e[t])}return r}var c=o.createContext({}),l=function(e){var n=o.useContext(c),t=n;return e&&(t="function"==typeof e?e(n):a(a({},n),e)),t},p=function(e){var n=l(e.components);return o.createElement(c.Provider,{value:n},e.children)},d="mdxType",m={inlineCode:"code",wrapper:function(e){var n=e.children;return o.createElement(o.Fragment,{},n)}},u=o.forwardRef((function(e,n){var t=e.components,r=e.mdxType,s=e.originalType,c=e.parentName,p=i(e,["components","mdxType","originalType","parentName"]),d=l(t),u=r,b=d["".concat(c,".").concat(u)]||d[u]||m[u]||s;return t?o.createElement(b,a(a({ref:n},p),{},{components:t})):o.createElement(b,a({ref:n},p))}));function b(e,n){var t=arguments,r=n&&n.mdxType;if("string"==typeof e||r){var s=t.length,a=new Array(s);a[0]=u;var i={};for(var c in n)hasOwnProperty.call(n,c)&&(i[c]=n[c]);i.originalType=e,i[d]="string"==typeof e?e:r,a[1]=i;for(var l=2;l{t.r(n),t.d(n,{assets:()=>c,contentTitle:()=>a,default:()=>m,frontMatter:()=>s,metadata:()=>i,toc:()=>l});var o=t(87462),r=(t(67294),t(3905));const s={},a="WebSocket Connections",i={unversionedId:"beaconchain/develop/api-reference/dex-api/ws-connection",id:"beaconchain/develop/api-reference/dex-api/ws-connection",title:"WebSocket Connections",description:"Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries.",source:"@site/docs/beaconchain/develop/api-reference/dex-api/ws-connection.md",sourceDirName:"beaconchain/develop/api-reference/dex-api",slug:"/beaconchain/develop/api-reference/dex-api/ws-connection",permalink:"/docs/beaconchain/develop/api-reference/dex-api/ws-connection",draft:!1,editUrl:"https://github.com/bnb-chain/bnb-chain.github.io/blob/master/docs/beaconchain/develop/api-reference/dex-api/ws-connection.md",tags:[],version:"current",frontMatter:{},sidebar:"bscSideBar",previous:{title:"Staking API",permalink:"/docs/beaconchain/develop/api-reference/dex-api/staking"},next:{title:"WebSocket Streams",permalink:"/docs/beaconchain/develop/api-reference/dex-api/ws-streams"}},c={},l=[{value:"Method 1: Connect with stream names in the URL",id:"method-1-connect-with-stream-names-in-the-url",level:3},{value:"Method 2: Subscribe to streams on demand",id:"method-2-subscribe-to-streams-on-demand",level:3}],p={toc:l},d="wrapper";function m(e){let{components:n,...t}=e;return(0,r.kt)(d,(0,o.Z)({},p,t,{components:n,mdxType:"MDXLayout"}),(0,r.kt)("h1",{id:"websocket-connections"},"WebSocket Connections"),(0,r.kt)("p",null,"Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries."),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"The base endpoint for mainnet is: ",(0,r.kt)("strong",{parentName:"li"},"wss://dex.binance.org/api/"),"."),(0,r.kt)("li",{parentName:"ul"},"Each connection can consume a single stream or multiple streams may be multiplexed through one connection for more complex apps."),(0,r.kt)("li",{parentName:"ul"},"All symbols in stream names are lowercase.")),(0,r.kt)("p",null,"Stream names may be provided in the URL ",(0,r.kt)("strong",{parentName:"p"},"or")," there is a mechanism to ",(0,r.kt)("inlineCode",{parentName:"p"},"subscribe")," to consume streams on demand through one connection."),(0,r.kt)("p",null,"Note: Once the connection is established, the websocket server will send ping frame to the client every 30 seconds. The client should reply with pong frame in time (this has already been implemented by most modern browsers, but programmatical users need to be aware of whether your websocket library supports this), otherwise, the connection might be closed."),(0,r.kt)("p",null,"Examples of each of these methods are provided below in JavaScript:"),(0,r.kt)("h3",{id:"method-1-connect-with-stream-names-in-the-url"},"Method 1: Connect with stream names in the URL"),(0,r.kt)("p",null,"Using this method, stream names are specified in the URLs used to connect to the data streams:"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"Single streams ",(0,r.kt)("inlineCode",{parentName:"li"},"/ws/"))),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Mainnet Example:")," Various methods of connecting to streams where stream names are provided in URLs:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"},' // for personal streams, ex: Account & Transfers\n const accountAndOrdersFeeds = new WebSocket("wss://dex.binance.org/api/ws/");\n\n // for all symbols\n const blockHeight = new WebSocket("wss://dex.binance.org/api/ws/$all@blockheight");\n')),(0,r.kt)("h3",{id:"method-2-subscribe-to-streams-on-demand"},"Method 2: Subscribe to streams on demand"),(0,r.kt)("p",null,"Using this method, streams are be consumed via subscribe and unsubscribe commands, sent through a single WebSocket connection."),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Note: one connection is only allowed to subscribe to one address.")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"}," const conn = new WebSocket(\"wss://dex.binance.org/api/ws\");\n conn.onopen = function(evt) {\n // send Subscribe/Unsubscribe messages here (see below)\n }\n conn.onmessage = function(evt) {\n console.info('received data', evt.data);\n };\n conn.onerror = function(evt) {\n console.error('an error occurred', evt.data);\n };\n")),(0,r.kt)("p",null,"After connecting successfully you can subscribe/unsubscribe to different topics."),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Example:")," To subscribe to transfer events, you should send a socket message with the ",(0,r.kt)("inlineCode",{parentName:"p"},"subscribe")," payload as below:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"},' const conn = new WebSocket("wss://dex.binance.org/api/ws/bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x");\n conn.onopen = function(evt) {\n // for personal topics such as accounts & transfers, an `address` is required\n // Note: one connection is only allowed to subscribe to one address.\n // If you subscribe to a new address, regardless of whether the topic is new, the subscriptions for the previous addresses will be removed.\n conn.send(JSON.stringify({ method: "subscribe", topic: "transfers", address: "bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x" }));\n }\n')),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Example:")," To unsubscribe from orders events, you should send a socket message with payloads as below:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"},' // unsubscribe from topic\n conn.send(JSON.stringify({ method: "unsubscribe", topic: "transfers" }));\n')),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Example:")," To extend connection life, you should send a message with a payload using the ",(0,r.kt)("inlineCode",{parentName:"p"},"keepAlive")," method:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"},' // This will extend the connection time to another 30 minutes\n // It\'s good to send this message every 30 minutes to maintain the connection life\n conn.send(JSON.stringify({ method: "keepAlive" }));\n')),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},"Example:")," To close a connection, you should send a socket message with a payload as below:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-javascript"},' // Connections will auto close after 30 - 60 minutes if no "keepAlive" messages received\n // Connections with no subscriptions will be closed, regardless the keepAlive messages.\n conn.send(JSON.stringify({ method: "close" }));\n')))}m.isMDXComponent=!0}}]);
\ No newline at end of file
diff --git a/assets/js/runtime~main.61008574.js b/assets/js/runtime~main.f829a5c3.js
similarity index 99%
rename from assets/js/runtime~main.61008574.js
rename to assets/js/runtime~main.f829a5c3.js
index d8e95c5e9c..f5be382965 100644
--- a/assets/js/runtime~main.61008574.js
+++ b/assets/js/runtime~main.f829a5c3.js
@@ -1 +1 @@
-(()=>{"use strict";var e,a,c,f,d,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={id:e,loaded:!1,exports:{}};return b[e].call(c.exports,c,c.exports,r),c.loaded=!0,c.exports}r.m=b,r.c=t,e=[],r.O=(a,c,f,d)=>{if(!c){var b=1/0;for(i=0;i=d)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,d0&&e[i-1][2]>d;i--)e[i]=e[i-1];e[i]=[c,f,d]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var d=Object.create(null);r.r(d);var b={};a=a||[null,c({}),c([]),c(c)];for(var t=2&f&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(d,b),d},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({26:"f4b7dbf9",41:"ea7f81af",53:"935f2afb",76:"7da45d1b",78:"1a12b3eb",188:"0e19568b",246:"699b933d",276:"0a24bc6c",495:"0d52c50f",512:"a8c31594",542:"53ba04fa",615:"426df75b",617:"dfd3236d",624:"57dfcb57",715:"56834eaf",740:"9e9695ea",754:"592d8667",775:"c9229a84",836:"0480b142",841:"4904453e",844:"f8f60af7",855:"f0b44263",859:"8c20990f",899:"be68102f",905:"00868d8e",910:"6ecc76ed",913:"7819d3b5",929:"097a92d8",933:"97a1f5f3",956:"ae5b1410",961:"5fa0bca2",1015:"adb40ef5",1050:"f1bcd6ab",1051:"a126a101",1120:"e7245c0e",1166:"ea8e0bfc",1208:"586689e4",1221:"07d04c29",1224:"45b5f33c",1318:"65fc7665",1327:"8882742c",1372:"1db64337",1373:"c29fd1d9",1502:"305f3035",1544:"a8e5477a",1577:"6974a59e",1595:"936cbf1c",1623:"de5cb490",1637:"c0602f71",1639:"bd2f937f",1731:"0e800433",1753:"073e83ba",1805:"6e83d4d1",1806:"c1d67c6f",1824:"e29e6131",1861:"96b89644",1902:"6dd408b0",1915:"9d12552c",1938:"6639555e",1939:"208ad0b7",1950:"db2ee795",1969:"61b88e35",1994:"776f2dca",1998:"70ebf55c",2010:"1bc24ad6",2025:"02e49d04",2042:"9ee78e3d",2076:"c79c6419",2100:"725bcd8a",2136:"38ea6270",2182:"3f4f1b85",2211:"82c6054d",2212:"7d370da3",2221:"69560f14",2239:"b7a29a20",2248:"4af00c2c",2258:"bb56c414",2264:"7d930281",2271:"6b7ff034",2280:"3ca8d367",2284:"2b9377a0",2303:"fb2aac14",2320:"3c355134",2403:"84c6b5d4",2409:"1f96dd1b",2466:"19ee63d5",2506:"df23e008",2544:"4aeca0dd",2596:"049c7c64",2673:"0d73c327",2691:"c52b2720",2692:"af50bec2",2694:"01df7f3f",2698:"49100cb7",2733:"055d8f40",2800:"168c1296",2853:"95314b82",2939:"2727f0e2",2962:"3b7f1d9e",2970:"8bd870ef",2973:"5d256d9e",2980:"0866dc88",3012:"ceddd399",3013:"58fa094e",3085:"1f391b9e",3110:"e3677851",3141:"4c0e0ec5",3160:"1a9c1393",3226:"c24cede4",3231:"dcec6889",3259:"98ee90af",3268:"5724b0c4",3277:"99ef32f4",3306:"03188927",3311:"8c8eed79",3343:"1d23a3cc",3362:"c09d0117",3369:"df71083d",3406:"767b2b71",3409:"0b13d5e8",3436:"a30d6a39",3442:"92a6a6aa",3470:"2033fe1d",3479:"820a1e19",3550:"39c0d873",3719:"8f96c667",3753:"8864f5f8",3770:"14da9b10",3819:"2fa1e944",3831:"d9b93d98",3913:"7cc7300b",3929:"4479d28a",3990:"c8a2ef77",4002:"59fd2fc7",4099:"86e33bb9",4117:"3ffb3654",4132:"9609c8f6",4165:"bba8d026",4195:"c4f5d8e4",4225:"61509a60",4234:"cc32ad1c",4317:"dbb9ff6e",4330:"5df04955",4341:"b694928c",4365:"b66a59f2",4417:"93991a3d",4450:"89381d81",4466:"ffb2b4d8",4526:"379ce79b",4528:"2fe8ce59",4554:"68396417",4581:"cf85ede8",4621:"a35af971",4662:"e64f9346",4663:"337885e6",4835:"7d79a86a",4935:"0d78eb08",4979:"4b96ce56",4995:"39b3fdd1",5074:"bc8da1ef",5090:"320800f4",5160:"d7c447b7",5174:"54a5b3e2",5178:"aba2fd11",5182:"80118b91",5184:"6d5ccf3c",5188:"37c50b0a",5205:"4b15b3ca",5227:"9ea974a1",5333:"7b6b3838",5334:"28682005",5352:"bef893b8",5353:"b0d837a2",5398:"4e426588",5444:"49850653",5456:"eaea0c8e",5478:"5f00e493",5487:"4df2b942",5511:"05720bc7",5534:"12ad0883",5546:"cd5a7ece",5605:"cff456ab",5614:"b79fb02a",5677:"913d1df3",5687:"843b88bc",5756:"52188b66",5766:"ab6ec9c9",5816:"b172b294",5827:"2179e181",5845:"e4fcb135",5894:"841a1ae5",5898:"d2ef7841",6022:"8311baf6",6112:"9233b6a0",6128:"61c2b592",6160:"13cbbc45",6175:"3fe1b31e",6197:"18caa820",6212:"674b291d",6266:"864b21f2",6342:"8388d427",6392:"1fe0b14c",6408:"3d2e3c20",6434:"ac3eef92",6453:"7ca3659a",6670:"7335f490",6711:"db0000f8",6788:"695b1d89",6798:"f4c65d51",6807:"146e3239",6833:"c801e96e",6843:"5dc3c8f6",6865:"42e796b7",6891:"ae1b1adb",6899:"7f9f2386",6911:"2c8e0782",6942:"4356940c",6980:"7bf9570a",7006:"718d2dcc",7009:"039e4454",7021:"b77aed85",7055:"e0350bff",7086:"6794fe4c",7093:"de4a6a6c",7144:"931e9fae",7162:"d589d3a7",7232:"4f0a142f",7337:"4e3e8b54",7372:"9bfac0a1",7414:"393be207",7479:"95a2a291",7554:"aa4704fa",7560:"6cf6a508",7608:"d21a06aa",7631:"a9d4f8dd",7671:"14304958",7724:"e588fe04",7729:"658db2fd",7861:"0d351afe",7903:"ada04912",7906:"37390557",7918:"17896441",7920:"1a4e3797",7958:"6b4e7cc0",7976:"e9e588e3",8060:"58a7e9f4",8090:"4248bf8f",8107:"bc5c4e3f",8148:"695536cb",8209:"a3a80959",8247:"fda3c7b4",8374:"f7810842",8452:"a719f608",8475:"eab1b5b1",8478:"4b768e8d",8489:"e48c32e6",8496:"98315e5f",8566:"74da69c6",8573:"ca21e936",8603:"266edd5c",8609:"b5189564",8629:"b8327182",8776:"44bcb8b6",8795:"7b298cde",8852:"b7a8c418",8915:"d72e2d41",8994:"dca35320",9009:"5d035c0c",9109:"601bd9b3",9247:"12690ca6",9248:"efa021b8",9263:"a1d0e770",9299:"4779363e",9340:"436fdc09",9371:"0a1df218",9373:"31ecfdf3",9392:"76061115",9402:"606e9499",9462:"243acfc7",9514:"1be78505",9539:"a72ad06f",9551:"597afff9",9581:"437509ae",9735:"4ba7e5a3",9835:"6b502c6d",9863:"015c4fcd",9868:"827c765e",9883:"d8c7cd00",9943:"cad38203",9962:"2927d995"}[e]||e)+"."+{26:"5de0a52d",41:"c2164434",53:"30c0d2df",76:"abc56e21",78:"ffb20f02",188:"8e41a52a",246:"e75495ac",276:"eebaecda",495:"4f83f1ff",512:"9f9c36f8",542:"27b3f4f7",615:"52f9255d",617:"df6874f8",624:"61d1804a",715:"35617482",740:"166b4b39",754:"aaf4e619",775:"317f04a9",836:"56db3a83",841:"a41f0df4",844:"96366bb0",855:"09f74229",859:"278db731",899:"0e4ca156",905:"f5114d69",910:"f79bf6de",913:"f5ab313e",929:"6a56be12",933:"b68de373",956:"69fe4652",961:"6037fd81",1015:"4d773597",1050:"1b9e9fb7",1051:"b4763b46",1120:"b5c8f6ad",1166:"01d9a2a2",1208:"6cf81638",1221:"a825ee65",1224:"eb2c4d48",1318:"8afc545e",1327:"3bc7653b",1372:"a79c3910",1373:"a33c9aaa",1426:"8dd36e2c",1502:"02ebf0ef",1544:"64ea3375",1577:"d875ee40",1595:"758e696a",1623:"a9643aa7",1637:"011341fd",1639:"528efff8",1690:"f40fd325",1731:"aeb53d29",1753:"64cd25e7",1805:"66177221",1806:"f0a9c261",1824:"4ff50a8b",1861:"3805e6fb",1902:"0a424570",1915:"a563064b",1938:"bdd3d2ad",1939:"2f8cf96c",1950:"8eb2f414",1969:"f5a178ca",1994:"86c791e2",1998:"8463ffd1",2010:"1a4b16f7",2025:"76f63e95",2040:"b5f0a78a",2042:"76b424a0",2076:"df22ace4",2100:"d5ec46e0",2136:"1fde950a",2182:"5c070d48",2211:"08843ad8",2212:"50e426e8",2221:"bc36e411",2239:"fcbe389e",2248:"2d01ca2e",2258:"4be1cfd5",2264:"c71a45ac",2271:"459a418c",2280:"d62daeac",2284:"135f2275",2303:"f13c7c06",2320:"267174fb",2403:"4b5a7dc9",2409:"9906f65b",2466:"b47d6bf1",2506:"1b715f4c",2544:"d0e61930",2596:"768abe64",2673:"aafaaa67",2691:"588ecd8a",2692:"4ad29e41",2694:"109edf59",2698:"a61d0353",2733:"17268e5a",2800:"04a13696",2853:"cc0717e5",2939:"5a70d7e2",2962:"0f7d89b2",2970:"ca86e8fa",2973:"5e7420d0",2980:"fe724887",3012:"cd148b5b",3013:"42b051a3",3085:"5f336445",3110:"c4a980d1",3141:"977435c6",3160:"9b99f0b8",3226:"09277b4c",3231:"f878ceb5",3259:"2e47c202",3268:"1c68c8d8",3277:"3a758d81",3306:"925d6057",3311:"498f0225",3343:"136e2e41",3362:"10f2862c",3369:"9664893a",3406:"03084b18",3409:"fd4bf487",3436:"324db7c1",3442:"ef165b7d",3470:"a8cb4d73",3479:"820a2ac4",3550:"e813ff8a",3719:"6b690cf4",3753:"99e7bba1",3770:"cfaeff6e",3819:"2d0fe218",3831:"e2aca97a",3913:"2ccf0d2c",3929:"396e9872",3990:"e7f72c02",4002:"1f59410f",4099:"4a30cba0",4117:"cf1f4e27",4132:"4154a89b",4165:"70be96e9",4195:"7b613710",4225:"22ad1e82",4234:"4daca806",4317:"543c6a62",4330:"224e8dcb",4341:"312379b8",4365:"19a069a2",4417:"070d7704",4450:"1604a9f3",4466:"a38c911d",4526:"4ff429f6",4528:"2364f4ef",4554:"8ac20e4f",4581:"ed2b9138",4621:"6879f312",4662:"6bd6f2f2",4663:"4151c518",4835:"482a0500",4935:"13803ac1",4972:"fbceddc1",4979:"b7d4d753",4995:"555236d9",5074:"e5ff997b",5090:"4eaa1d4c",5160:"98f9f208",5174:"a3cc9a39",5178:"48a3a749",5182:"06a0077a",5184:"b4268fac",5188:"ef610503",5205:"f41ac1e7",5227:"43bf702f",5333:"55a8aaaa",5334:"9725e91c",5352:"035b564c",5353:"fedcd4b9",5398:"7d8999e8",5444:"9105b6e6",5456:"442c135e",5478:"453ded89",5487:"dd93cd3f",5511:"1f689ee7",5534:"6ceb7e3f",5546:"14d70dd2",5605:"aebb7353",5614:"7451c26a",5677:"1942bf67",5687:"2db0d2a7",5756:"e9a08c1c",5766:"b6d8bb47",5816:"19bef3e2",5827:"bc0ebca7",5845:"4f30f6f1",5894:"2229c521",5898:"16ec6689",6022:"9af3cc0d",6112:"4920ca6a",6128:"8106cdc6",6160:"4cc1e5f0",6175:"d49efa40",6197:"ba8b7cf0",6212:"75f99d02",6266:"dac78094",6342:"b2e4a2bd",6392:"feb76b78",6408:"117bdc03",6434:"273daae1",6453:"8b12039b",6670:"4f50f82a",6711:"15902fef",6788:"f2bd5fcd",6798:"fba9b0d2",6807:"728c0ca5",6833:"e77ff09a",6843:"76ad2cdf",6865:"9ee5b144",6891:"b19d93e6",6899:"d67e4468",6911:"75653aff",6942:"31c31fc6",6945:"de5501ca",6980:"d3e4c331",7006:"7d822146",7009:"959b31c8",7021:"f44e5f72",7055:"0185cd35",7086:"947a22f7",7093:"e5fd51f1",7144:"c8d6d109",7162:"1344abb9",7232:"71e015c7",7337:"96dfd020",7372:"8c8405b8",7414:"9701482b",7479:"1ceb669a",7554:"58a7ae6a",7560:"659ca8d0",7608:"4ad8a0cc",7631:"e1006075",7671:"2b4693c0",7724:"8f9c19c3",7729:"e1f4ba89",7861:"97a9eb99",7903:"709c7b71",7906:"6d321b7f",7918:"a334583b",7920:"d3e0a077",7958:"db5f2ab8",7976:"40e94a47",8060:"001ac74d",8090:"a56b2b62",8107:"88c0ef04",8148:"59f0088f",8209:"e44ba252",8247:"98115cef",8374:"ea2bddf5",8452:"5862a3e3",8475:"6e20999f",8478:"47bd719e",8489:"49423ed6",8496:"21444c25",8566:"0df1f550",8573:"f37adfe9",8603:"dc0a9bfb",8609:"acba9600",8629:"faf05747",8776:"bd079eea",8795:"4bdb17be",8852:"2ddc9d93",8894:"8b8574c7",8915:"15ccb78b",8994:"bde7e03a",9009:"d9afaea9",9109:"b4df9939",9247:"3b9eaef8",9248:"eb7a1e18",9263:"fb6d6011",9299:"845092cd",9340:"b75e02cc",9371:"076735c7",9373:"a0aa1a83",9392:"b69b0a47",9402:"48372e81",9462:"f0368933",9514:"ec283d5d",9539:"80ea6152",9551:"ac7bb3e3",9581:"38953c8b",9735:"13350f8a",9835:"3fa1a055",9863:"ed1e5e8f",9868:"3476820f",9883:"285b3b93",9943:"17bde2c7",9962:"b8ec92b9"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),f={},d="beta_BNB_Docs:",r.l=(e,a,c,b)=>{if(f[e])f[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var d=f[e];if(delete f[e],t.parentNode&&t.parentNode.removeChild(t),d&&d.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={14304958:"7671",17896441:"7918",28682005:"5334",37390557:"7906",49850653:"5444",68396417:"4554",76061115:"9392",f4b7dbf9:"26",ea7f81af:"41","935f2afb":"53","7da45d1b":"76","1a12b3eb":"78","0e19568b":"188","699b933d":"246","0a24bc6c":"276","0d52c50f":"495",a8c31594:"512","53ba04fa":"542","426df75b":"615",dfd3236d:"617","57dfcb57":"624","56834eaf":"715","9e9695ea":"740","592d8667":"754",c9229a84:"775","0480b142":"836","4904453e":"841",f8f60af7:"844",f0b44263:"855","8c20990f":"859",be68102f:"899","00868d8e":"905","6ecc76ed":"910","7819d3b5":"913","097a92d8":"929","97a1f5f3":"933",ae5b1410:"956","5fa0bca2":"961",adb40ef5:"1015",f1bcd6ab:"1050",a126a101:"1051",e7245c0e:"1120",ea8e0bfc:"1166","586689e4":"1208","07d04c29":"1221","45b5f33c":"1224","65fc7665":"1318","8882742c":"1327","1db64337":"1372",c29fd1d9:"1373","305f3035":"1502",a8e5477a:"1544","6974a59e":"1577","936cbf1c":"1595",de5cb490:"1623",c0602f71:"1637",bd2f937f:"1639","0e800433":"1731","073e83ba":"1753","6e83d4d1":"1805",c1d67c6f:"1806",e29e6131:"1824","96b89644":"1861","6dd408b0":"1902","9d12552c":"1915","6639555e":"1938","208ad0b7":"1939",db2ee795:"1950","61b88e35":"1969","776f2dca":"1994","70ebf55c":"1998","1bc24ad6":"2010","02e49d04":"2025","9ee78e3d":"2042",c79c6419:"2076","725bcd8a":"2100","38ea6270":"2136","3f4f1b85":"2182","82c6054d":"2211","7d370da3":"2212","69560f14":"2221",b7a29a20:"2239","4af00c2c":"2248",bb56c414:"2258","7d930281":"2264","6b7ff034":"2271","3ca8d367":"2280","2b9377a0":"2284",fb2aac14:"2303","3c355134":"2320","84c6b5d4":"2403","1f96dd1b":"2409","19ee63d5":"2466",df23e008:"2506","4aeca0dd":"2544","049c7c64":"2596","0d73c327":"2673",c52b2720:"2691",af50bec2:"2692","01df7f3f":"2694","49100cb7":"2698","055d8f40":"2733","168c1296":"2800","95314b82":"2853","2727f0e2":"2939","3b7f1d9e":"2962","8bd870ef":"2970","5d256d9e":"2973","0866dc88":"2980",ceddd399:"3012","58fa094e":"3013","1f391b9e":"3085",e3677851:"3110","4c0e0ec5":"3141","1a9c1393":"3160",c24cede4:"3226",dcec6889:"3231","98ee90af":"3259","5724b0c4":"3268","99ef32f4":"3277","03188927":"3306","8c8eed79":"3311","1d23a3cc":"3343",c09d0117:"3362",df71083d:"3369","767b2b71":"3406","0b13d5e8":"3409",a30d6a39:"3436","92a6a6aa":"3442","2033fe1d":"3470","820a1e19":"3479","39c0d873":"3550","8f96c667":"3719","8864f5f8":"3753","14da9b10":"3770","2fa1e944":"3819",d9b93d98:"3831","7cc7300b":"3913","4479d28a":"3929",c8a2ef77:"3990","59fd2fc7":"4002","86e33bb9":"4099","3ffb3654":"4117","9609c8f6":"4132",bba8d026:"4165",c4f5d8e4:"4195","61509a60":"4225",cc32ad1c:"4234",dbb9ff6e:"4317","5df04955":"4330",b694928c:"4341",b66a59f2:"4365","93991a3d":"4417","89381d81":"4450",ffb2b4d8:"4466","379ce79b":"4526","2fe8ce59":"4528",cf85ede8:"4581",a35af971:"4621",e64f9346:"4662","337885e6":"4663","7d79a86a":"4835","0d78eb08":"4935","4b96ce56":"4979","39b3fdd1":"4995",bc8da1ef:"5074","320800f4":"5090",d7c447b7:"5160","54a5b3e2":"5174",aba2fd11:"5178","80118b91":"5182","6d5ccf3c":"5184","37c50b0a":"5188","4b15b3ca":"5205","9ea974a1":"5227","7b6b3838":"5333",bef893b8:"5352",b0d837a2:"5353","4e426588":"5398",eaea0c8e:"5456","5f00e493":"5478","4df2b942":"5487","05720bc7":"5511","12ad0883":"5534",cd5a7ece:"5546",cff456ab:"5605",b79fb02a:"5614","913d1df3":"5677","843b88bc":"5687","52188b66":"5756",ab6ec9c9:"5766",b172b294:"5816","2179e181":"5827",e4fcb135:"5845","841a1ae5":"5894",d2ef7841:"5898","8311baf6":"6022","9233b6a0":"6112","61c2b592":"6128","13cbbc45":"6160","3fe1b31e":"6175","18caa820":"6197","674b291d":"6212","864b21f2":"6266","8388d427":"6342","1fe0b14c":"6392","3d2e3c20":"6408",ac3eef92:"6434","7ca3659a":"6453","7335f490":"6670",db0000f8:"6711","695b1d89":"6788",f4c65d51:"6798","146e3239":"6807",c801e96e:"6833","5dc3c8f6":"6843","42e796b7":"6865",ae1b1adb:"6891","7f9f2386":"6899","2c8e0782":"6911","4356940c":"6942","7bf9570a":"6980","718d2dcc":"7006","039e4454":"7009",b77aed85:"7021",e0350bff:"7055","6794fe4c":"7086",de4a6a6c:"7093","931e9fae":"7144",d589d3a7:"7162","4f0a142f":"7232","4e3e8b54":"7337","9bfac0a1":"7372","393be207":"7414","95a2a291":"7479",aa4704fa:"7554","6cf6a508":"7560",d21a06aa:"7608",a9d4f8dd:"7631",e588fe04:"7724","658db2fd":"7729","0d351afe":"7861",ada04912:"7903","1a4e3797":"7920","6b4e7cc0":"7958",e9e588e3:"7976","58a7e9f4":"8060","4248bf8f":"8090",bc5c4e3f:"8107","695536cb":"8148",a3a80959:"8209",fda3c7b4:"8247",f7810842:"8374",a719f608:"8452",eab1b5b1:"8475","4b768e8d":"8478",e48c32e6:"8489","98315e5f":"8496","74da69c6":"8566",ca21e936:"8573","266edd5c":"8603",b5189564:"8609",b8327182:"8629","44bcb8b6":"8776","7b298cde":"8795",b7a8c418:"8852",d72e2d41:"8915",dca35320:"8994","5d035c0c":"9009","601bd9b3":"9109","12690ca6":"9247",efa021b8:"9248",a1d0e770:"9263","4779363e":"9299","436fdc09":"9340","0a1df218":"9371","31ecfdf3":"9373","606e9499":"9402","243acfc7":"9462","1be78505":"9514",a72ad06f:"9539","597afff9":"9551","437509ae":"9581","4ba7e5a3":"9735","6b502c6d":"9835","015c4fcd":"9863","827c765e":"9868",d8c7cd00:"9883",cad38203:"9943","2927d995":"9962"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var f=r.o(e,a)?e[a]:void 0;if(0!==f)if(f)c.push(f[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var d=new Promise(((c,d)=>f=e[a]=[c,d]));c.push(f[2]=d);var b=r.p+r.u(a),t=new Error;r.l(b,(c=>{if(r.o(e,a)&&(0!==(f=e[a])&&(e[a]=void 0),f)){var d=c&&("load"===c.type?"missing":c.type),b=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+d+": "+b+")",t.name="ChunkLoadError",t.type=d,t.request=b,f[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var f,d,b=c[0],t=c[1],o=c[2],n=0;if(b.some((a=>0!==e[a]))){for(f in t)r.o(t,f)&&(r.m[f]=t[f]);if(o)var i=o(r)}for(a&&a(c);n{"use strict";var e,a,c,f,d,b={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={id:e,loaded:!1,exports:{}};return b[e].call(c.exports,c,c.exports,r),c.loaded=!0,c.exports}r.m=b,r.c=t,e=[],r.O=(a,c,f,d)=>{if(!c){var b=1/0;for(i=0;i=d)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,d0&&e[i-1][2]>d;i--)e[i]=e[i-1];e[i]=[c,f,d]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var d=Object.create(null);r.r(d);var b={};a=a||[null,c({}),c([]),c(c)];for(var t=2&f&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>b[a]=()=>e[a]));return b.default=()=>e,r.d(d,b),d},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({26:"f4b7dbf9",41:"ea7f81af",53:"935f2afb",76:"7da45d1b",78:"1a12b3eb",188:"0e19568b",246:"699b933d",276:"0a24bc6c",495:"0d52c50f",512:"a8c31594",542:"53ba04fa",615:"426df75b",617:"dfd3236d",624:"57dfcb57",715:"56834eaf",740:"9e9695ea",754:"592d8667",775:"c9229a84",836:"0480b142",841:"4904453e",844:"f8f60af7",855:"f0b44263",859:"8c20990f",899:"be68102f",905:"00868d8e",910:"6ecc76ed",913:"7819d3b5",929:"097a92d8",933:"97a1f5f3",956:"ae5b1410",961:"5fa0bca2",1015:"adb40ef5",1050:"f1bcd6ab",1051:"a126a101",1120:"e7245c0e",1166:"ea8e0bfc",1208:"586689e4",1221:"07d04c29",1224:"45b5f33c",1318:"65fc7665",1327:"8882742c",1372:"1db64337",1373:"c29fd1d9",1502:"305f3035",1544:"a8e5477a",1577:"6974a59e",1595:"936cbf1c",1623:"de5cb490",1637:"c0602f71",1639:"bd2f937f",1731:"0e800433",1753:"073e83ba",1805:"6e83d4d1",1806:"c1d67c6f",1824:"e29e6131",1861:"96b89644",1902:"6dd408b0",1915:"9d12552c",1938:"6639555e",1939:"208ad0b7",1950:"db2ee795",1969:"61b88e35",1994:"776f2dca",1998:"70ebf55c",2010:"1bc24ad6",2025:"02e49d04",2042:"9ee78e3d",2076:"c79c6419",2100:"725bcd8a",2136:"38ea6270",2182:"3f4f1b85",2211:"82c6054d",2212:"7d370da3",2221:"69560f14",2239:"b7a29a20",2248:"4af00c2c",2258:"bb56c414",2264:"7d930281",2271:"6b7ff034",2280:"3ca8d367",2284:"2b9377a0",2303:"fb2aac14",2320:"3c355134",2403:"84c6b5d4",2409:"1f96dd1b",2466:"19ee63d5",2506:"df23e008",2544:"4aeca0dd",2596:"049c7c64",2673:"0d73c327",2691:"c52b2720",2692:"af50bec2",2694:"01df7f3f",2698:"49100cb7",2733:"055d8f40",2800:"168c1296",2853:"95314b82",2939:"2727f0e2",2962:"3b7f1d9e",2970:"8bd870ef",2973:"5d256d9e",2980:"0866dc88",3012:"ceddd399",3013:"58fa094e",3085:"1f391b9e",3110:"e3677851",3141:"4c0e0ec5",3160:"1a9c1393",3226:"c24cede4",3231:"dcec6889",3259:"98ee90af",3268:"5724b0c4",3277:"99ef32f4",3306:"03188927",3311:"8c8eed79",3343:"1d23a3cc",3362:"c09d0117",3369:"df71083d",3406:"767b2b71",3409:"0b13d5e8",3436:"a30d6a39",3442:"92a6a6aa",3470:"2033fe1d",3479:"820a1e19",3550:"39c0d873",3719:"8f96c667",3753:"8864f5f8",3770:"14da9b10",3819:"2fa1e944",3831:"d9b93d98",3913:"7cc7300b",3929:"4479d28a",3990:"c8a2ef77",4002:"59fd2fc7",4099:"86e33bb9",4117:"3ffb3654",4132:"9609c8f6",4165:"bba8d026",4195:"c4f5d8e4",4225:"61509a60",4234:"cc32ad1c",4317:"dbb9ff6e",4330:"5df04955",4341:"b694928c",4365:"b66a59f2",4417:"93991a3d",4450:"89381d81",4466:"ffb2b4d8",4526:"379ce79b",4528:"2fe8ce59",4554:"68396417",4581:"cf85ede8",4621:"a35af971",4662:"e64f9346",4663:"337885e6",4835:"7d79a86a",4935:"0d78eb08",4979:"4b96ce56",4995:"39b3fdd1",5074:"bc8da1ef",5090:"320800f4",5160:"d7c447b7",5174:"54a5b3e2",5178:"aba2fd11",5182:"80118b91",5184:"6d5ccf3c",5188:"37c50b0a",5205:"4b15b3ca",5227:"9ea974a1",5333:"7b6b3838",5334:"28682005",5352:"bef893b8",5353:"b0d837a2",5398:"4e426588",5444:"49850653",5456:"eaea0c8e",5478:"5f00e493",5487:"4df2b942",5511:"05720bc7",5534:"12ad0883",5546:"cd5a7ece",5605:"cff456ab",5614:"b79fb02a",5677:"913d1df3",5687:"843b88bc",5756:"52188b66",5766:"ab6ec9c9",5816:"b172b294",5827:"2179e181",5845:"e4fcb135",5894:"841a1ae5",5898:"d2ef7841",6022:"8311baf6",6112:"9233b6a0",6128:"61c2b592",6160:"13cbbc45",6175:"3fe1b31e",6197:"18caa820",6212:"674b291d",6266:"864b21f2",6342:"8388d427",6392:"1fe0b14c",6408:"3d2e3c20",6434:"ac3eef92",6453:"7ca3659a",6670:"7335f490",6711:"db0000f8",6788:"695b1d89",6798:"f4c65d51",6807:"146e3239",6833:"c801e96e",6843:"5dc3c8f6",6865:"42e796b7",6891:"ae1b1adb",6899:"7f9f2386",6911:"2c8e0782",6942:"4356940c",6980:"7bf9570a",7006:"718d2dcc",7009:"039e4454",7021:"b77aed85",7055:"e0350bff",7086:"6794fe4c",7093:"de4a6a6c",7144:"931e9fae",7162:"d589d3a7",7232:"4f0a142f",7337:"4e3e8b54",7372:"9bfac0a1",7414:"393be207",7479:"95a2a291",7554:"aa4704fa",7560:"6cf6a508",7608:"d21a06aa",7631:"a9d4f8dd",7671:"14304958",7724:"e588fe04",7729:"658db2fd",7861:"0d351afe",7903:"ada04912",7906:"37390557",7918:"17896441",7920:"1a4e3797",7958:"6b4e7cc0",7976:"e9e588e3",8060:"58a7e9f4",8090:"4248bf8f",8107:"bc5c4e3f",8148:"695536cb",8209:"a3a80959",8247:"fda3c7b4",8374:"f7810842",8452:"a719f608",8475:"eab1b5b1",8478:"4b768e8d",8489:"e48c32e6",8496:"98315e5f",8566:"74da69c6",8573:"ca21e936",8603:"266edd5c",8609:"b5189564",8629:"b8327182",8776:"44bcb8b6",8795:"7b298cde",8852:"b7a8c418",8915:"d72e2d41",8994:"dca35320",9009:"5d035c0c",9109:"601bd9b3",9247:"12690ca6",9248:"efa021b8",9263:"a1d0e770",9299:"4779363e",9340:"436fdc09",9371:"0a1df218",9373:"31ecfdf3",9392:"76061115",9402:"606e9499",9462:"243acfc7",9514:"1be78505",9539:"a72ad06f",9551:"597afff9",9581:"437509ae",9735:"4ba7e5a3",9835:"6b502c6d",9863:"015c4fcd",9868:"827c765e",9883:"d8c7cd00",9943:"cad38203",9962:"2927d995"}[e]||e)+"."+{26:"5de0a52d",41:"c2164434",53:"30c0d2df",76:"abc56e21",78:"ffb20f02",188:"8e41a52a",246:"e75495ac",276:"eebaecda",495:"4f83f1ff",512:"9f9c36f8",542:"27b3f4f7",615:"52f9255d",617:"df6874f8",624:"61d1804a",715:"35617482",740:"166b4b39",754:"aaf4e619",775:"317f04a9",836:"56db3a83",841:"a41f0df4",844:"96366bb0",855:"09f74229",859:"278db731",899:"0e4ca156",905:"f5114d69",910:"f79bf6de",913:"f5ab313e",929:"6a56be12",933:"b68de373",956:"69fe4652",961:"6037fd81",1015:"4d773597",1050:"1b9e9fb7",1051:"b4763b46",1120:"b5c8f6ad",1166:"01d9a2a2",1208:"6cf81638",1221:"a825ee65",1224:"eb2c4d48",1318:"8afc545e",1327:"3bc7653b",1372:"a79c3910",1373:"a33c9aaa",1426:"8dd36e2c",1502:"02ebf0ef",1544:"64ea3375",1577:"d875ee40",1595:"758e696a",1623:"a9643aa7",1637:"011341fd",1639:"528efff8",1690:"f40fd325",1731:"aeb53d29",1753:"64cd25e7",1805:"66177221",1806:"f0a9c261",1824:"4ff50a8b",1861:"3805e6fb",1902:"0a424570",1915:"a563064b",1938:"bdd3d2ad",1939:"2f8cf96c",1950:"8eb2f414",1969:"f5a178ca",1994:"86c791e2",1998:"8463ffd1",2010:"1a4b16f7",2025:"76f63e95",2040:"b5f0a78a",2042:"76b424a0",2076:"df22ace4",2100:"d5ec46e0",2136:"1fde950a",2182:"5c070d48",2211:"08843ad8",2212:"50e426e8",2221:"bc36e411",2239:"fcbe389e",2248:"2d01ca2e",2258:"4be1cfd5",2264:"c71a45ac",2271:"459a418c",2280:"d62daeac",2284:"135f2275",2303:"f13c7c06",2320:"267174fb",2403:"4b5a7dc9",2409:"9906f65b",2466:"b47d6bf1",2506:"1b715f4c",2544:"d0e61930",2596:"768abe64",2673:"aafaaa67",2691:"588ecd8a",2692:"4ad29e41",2694:"109edf59",2698:"a61d0353",2733:"17268e5a",2800:"04a13696",2853:"cc0717e5",2939:"5a70d7e2",2962:"0f7d89b2",2970:"ca86e8fa",2973:"5e7420d0",2980:"fe724887",3012:"cd148b5b",3013:"42b051a3",3085:"5f336445",3110:"c4a980d1",3141:"977435c6",3160:"9b99f0b8",3226:"09277b4c",3231:"f878ceb5",3259:"2e47c202",3268:"1c68c8d8",3277:"3a758d81",3306:"925d6057",3311:"498f0225",3343:"136e2e41",3362:"10f2862c",3369:"9664893a",3406:"03084b18",3409:"fd4bf487",3436:"324db7c1",3442:"ef165b7d",3470:"a8cb4d73",3479:"820a2ac4",3550:"e813ff8a",3719:"6b690cf4",3753:"99e7bba1",3770:"cfaeff6e",3819:"2d0fe218",3831:"e2aca97a",3913:"2ccf0d2c",3929:"396e9872",3990:"e7f72c02",4002:"1f59410f",4099:"4a30cba0",4117:"cf1f4e27",4132:"4154a89b",4165:"70be96e9",4195:"7b613710",4225:"22ad1e82",4234:"4daca806",4317:"543c6a62",4330:"224e8dcb",4341:"312379b8",4365:"19a069a2",4417:"070d7704",4450:"1604a9f3",4466:"a38c911d",4526:"4ff429f6",4528:"2364f4ef",4554:"8ac20e4f",4581:"ed2b9138",4621:"6879f312",4662:"6bd6f2f2",4663:"4151c518",4835:"482a0500",4935:"13803ac1",4972:"fbceddc1",4979:"b7d4d753",4995:"555236d9",5074:"e5ff997b",5090:"4eaa1d4c",5160:"98f9f208",5174:"a3cc9a39",5178:"48a3a749",5182:"06a0077a",5184:"b4268fac",5188:"ef610503",5205:"f41ac1e7",5227:"43bf702f",5333:"55a8aaaa",5334:"9725e91c",5352:"035b564c",5353:"fedcd4b9",5398:"7d8999e8",5444:"9105b6e6",5456:"442c135e",5478:"453ded89",5487:"dd93cd3f",5511:"1f689ee7",5534:"6ceb7e3f",5546:"14d70dd2",5605:"aebb7353",5614:"7451c26a",5677:"1942bf67",5687:"2db0d2a7",5756:"e9a08c1c",5766:"b6d8bb47",5816:"19bef3e2",5827:"bc0ebca7",5845:"4f30f6f1",5894:"2229c521",5898:"16ec6689",6022:"9af3cc0d",6112:"4920ca6a",6128:"8106cdc6",6160:"4cc1e5f0",6175:"d49efa40",6197:"ba8b7cf0",6212:"75f99d02",6266:"dac78094",6342:"b2e4a2bd",6392:"feb76b78",6408:"117bdc03",6434:"273daae1",6453:"8b12039b",6670:"4f50f82a",6711:"15902fef",6788:"f2bd5fcd",6798:"fba9b0d2",6807:"728c0ca5",6833:"e77ff09a",6843:"76ad2cdf",6865:"9ee5b144",6891:"b19d93e6",6899:"d67e4468",6911:"75653aff",6942:"31c31fc6",6945:"de5501ca",6980:"dc9cd1cc",7006:"7d822146",7009:"959b31c8",7021:"f44e5f72",7055:"0185cd35",7086:"947a22f7",7093:"e5fd51f1",7144:"c8d6d109",7162:"1344abb9",7232:"71e015c7",7337:"96dfd020",7372:"8c8405b8",7414:"9701482b",7479:"1ceb669a",7554:"58a7ae6a",7560:"659ca8d0",7608:"4ad8a0cc",7631:"e1006075",7671:"2b4693c0",7724:"8f9c19c3",7729:"e1f4ba89",7861:"97a9eb99",7903:"709c7b71",7906:"6d321b7f",7918:"a334583b",7920:"d3e0a077",7958:"db5f2ab8",7976:"40e94a47",8060:"001ac74d",8090:"a56b2b62",8107:"88c0ef04",8148:"59f0088f",8209:"e44ba252",8247:"98115cef",8374:"ea2bddf5",8452:"5862a3e3",8475:"6e20999f",8478:"47bd719e",8489:"49423ed6",8496:"21444c25",8566:"0df1f550",8573:"f37adfe9",8603:"dc0a9bfb",8609:"acba9600",8629:"faf05747",8776:"bd079eea",8795:"4bdb17be",8852:"2ddc9d93",8894:"8b8574c7",8915:"15ccb78b",8994:"bde7e03a",9009:"d9afaea9",9109:"b4df9939",9247:"3b9eaef8",9248:"eb7a1e18",9263:"fb6d6011",9299:"845092cd",9340:"b75e02cc",9371:"076735c7",9373:"a0aa1a83",9392:"b69b0a47",9402:"48372e81",9462:"f0368933",9514:"ec283d5d",9539:"80ea6152",9551:"ac7bb3e3",9581:"38953c8b",9735:"13350f8a",9835:"3fa1a055",9863:"ed1e5e8f",9868:"3476820f",9883:"285b3b93",9943:"17bde2c7",9962:"b8ec92b9"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),f={},d="beta_BNB_Docs:",r.l=(e,a,c,b)=>{if(f[e])f[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var d=f[e];if(delete f[e],t.parentNode&&t.parentNode.removeChild(t),d&&d.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={14304958:"7671",17896441:"7918",28682005:"5334",37390557:"7906",49850653:"5444",68396417:"4554",76061115:"9392",f4b7dbf9:"26",ea7f81af:"41","935f2afb":"53","7da45d1b":"76","1a12b3eb":"78","0e19568b":"188","699b933d":"246","0a24bc6c":"276","0d52c50f":"495",a8c31594:"512","53ba04fa":"542","426df75b":"615",dfd3236d:"617","57dfcb57":"624","56834eaf":"715","9e9695ea":"740","592d8667":"754",c9229a84:"775","0480b142":"836","4904453e":"841",f8f60af7:"844",f0b44263:"855","8c20990f":"859",be68102f:"899","00868d8e":"905","6ecc76ed":"910","7819d3b5":"913","097a92d8":"929","97a1f5f3":"933",ae5b1410:"956","5fa0bca2":"961",adb40ef5:"1015",f1bcd6ab:"1050",a126a101:"1051",e7245c0e:"1120",ea8e0bfc:"1166","586689e4":"1208","07d04c29":"1221","45b5f33c":"1224","65fc7665":"1318","8882742c":"1327","1db64337":"1372",c29fd1d9:"1373","305f3035":"1502",a8e5477a:"1544","6974a59e":"1577","936cbf1c":"1595",de5cb490:"1623",c0602f71:"1637",bd2f937f:"1639","0e800433":"1731","073e83ba":"1753","6e83d4d1":"1805",c1d67c6f:"1806",e29e6131:"1824","96b89644":"1861","6dd408b0":"1902","9d12552c":"1915","6639555e":"1938","208ad0b7":"1939",db2ee795:"1950","61b88e35":"1969","776f2dca":"1994","70ebf55c":"1998","1bc24ad6":"2010","02e49d04":"2025","9ee78e3d":"2042",c79c6419:"2076","725bcd8a":"2100","38ea6270":"2136","3f4f1b85":"2182","82c6054d":"2211","7d370da3":"2212","69560f14":"2221",b7a29a20:"2239","4af00c2c":"2248",bb56c414:"2258","7d930281":"2264","6b7ff034":"2271","3ca8d367":"2280","2b9377a0":"2284",fb2aac14:"2303","3c355134":"2320","84c6b5d4":"2403","1f96dd1b":"2409","19ee63d5":"2466",df23e008:"2506","4aeca0dd":"2544","049c7c64":"2596","0d73c327":"2673",c52b2720:"2691",af50bec2:"2692","01df7f3f":"2694","49100cb7":"2698","055d8f40":"2733","168c1296":"2800","95314b82":"2853","2727f0e2":"2939","3b7f1d9e":"2962","8bd870ef":"2970","5d256d9e":"2973","0866dc88":"2980",ceddd399:"3012","58fa094e":"3013","1f391b9e":"3085",e3677851:"3110","4c0e0ec5":"3141","1a9c1393":"3160",c24cede4:"3226",dcec6889:"3231","98ee90af":"3259","5724b0c4":"3268","99ef32f4":"3277","03188927":"3306","8c8eed79":"3311","1d23a3cc":"3343",c09d0117:"3362",df71083d:"3369","767b2b71":"3406","0b13d5e8":"3409",a30d6a39:"3436","92a6a6aa":"3442","2033fe1d":"3470","820a1e19":"3479","39c0d873":"3550","8f96c667":"3719","8864f5f8":"3753","14da9b10":"3770","2fa1e944":"3819",d9b93d98:"3831","7cc7300b":"3913","4479d28a":"3929",c8a2ef77:"3990","59fd2fc7":"4002","86e33bb9":"4099","3ffb3654":"4117","9609c8f6":"4132",bba8d026:"4165",c4f5d8e4:"4195","61509a60":"4225",cc32ad1c:"4234",dbb9ff6e:"4317","5df04955":"4330",b694928c:"4341",b66a59f2:"4365","93991a3d":"4417","89381d81":"4450",ffb2b4d8:"4466","379ce79b":"4526","2fe8ce59":"4528",cf85ede8:"4581",a35af971:"4621",e64f9346:"4662","337885e6":"4663","7d79a86a":"4835","0d78eb08":"4935","4b96ce56":"4979","39b3fdd1":"4995",bc8da1ef:"5074","320800f4":"5090",d7c447b7:"5160","54a5b3e2":"5174",aba2fd11:"5178","80118b91":"5182","6d5ccf3c":"5184","37c50b0a":"5188","4b15b3ca":"5205","9ea974a1":"5227","7b6b3838":"5333",bef893b8:"5352",b0d837a2:"5353","4e426588":"5398",eaea0c8e:"5456","5f00e493":"5478","4df2b942":"5487","05720bc7":"5511","12ad0883":"5534",cd5a7ece:"5546",cff456ab:"5605",b79fb02a:"5614","913d1df3":"5677","843b88bc":"5687","52188b66":"5756",ab6ec9c9:"5766",b172b294:"5816","2179e181":"5827",e4fcb135:"5845","841a1ae5":"5894",d2ef7841:"5898","8311baf6":"6022","9233b6a0":"6112","61c2b592":"6128","13cbbc45":"6160","3fe1b31e":"6175","18caa820":"6197","674b291d":"6212","864b21f2":"6266","8388d427":"6342","1fe0b14c":"6392","3d2e3c20":"6408",ac3eef92:"6434","7ca3659a":"6453","7335f490":"6670",db0000f8:"6711","695b1d89":"6788",f4c65d51:"6798","146e3239":"6807",c801e96e:"6833","5dc3c8f6":"6843","42e796b7":"6865",ae1b1adb:"6891","7f9f2386":"6899","2c8e0782":"6911","4356940c":"6942","7bf9570a":"6980","718d2dcc":"7006","039e4454":"7009",b77aed85:"7021",e0350bff:"7055","6794fe4c":"7086",de4a6a6c:"7093","931e9fae":"7144",d589d3a7:"7162","4f0a142f":"7232","4e3e8b54":"7337","9bfac0a1":"7372","393be207":"7414","95a2a291":"7479",aa4704fa:"7554","6cf6a508":"7560",d21a06aa:"7608",a9d4f8dd:"7631",e588fe04:"7724","658db2fd":"7729","0d351afe":"7861",ada04912:"7903","1a4e3797":"7920","6b4e7cc0":"7958",e9e588e3:"7976","58a7e9f4":"8060","4248bf8f":"8090",bc5c4e3f:"8107","695536cb":"8148",a3a80959:"8209",fda3c7b4:"8247",f7810842:"8374",a719f608:"8452",eab1b5b1:"8475","4b768e8d":"8478",e48c32e6:"8489","98315e5f":"8496","74da69c6":"8566",ca21e936:"8573","266edd5c":"8603",b5189564:"8609",b8327182:"8629","44bcb8b6":"8776","7b298cde":"8795",b7a8c418:"8852",d72e2d41:"8915",dca35320:"8994","5d035c0c":"9009","601bd9b3":"9109","12690ca6":"9247",efa021b8:"9248",a1d0e770:"9263","4779363e":"9299","436fdc09":"9340","0a1df218":"9371","31ecfdf3":"9373","606e9499":"9402","243acfc7":"9462","1be78505":"9514",a72ad06f:"9539","597afff9":"9551","437509ae":"9581","4ba7e5a3":"9735","6b502c6d":"9835","015c4fcd":"9863","827c765e":"9868",d8c7cd00:"9883",cad38203:"9943","2927d995":"9962"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var f=r.o(e,a)?e[a]:void 0;if(0!==f)if(f)c.push(f[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var d=new Promise(((c,d)=>f=e[a]=[c,d]));c.push(f[2]=d);var b=r.p+r.u(a),t=new Error;r.l(b,(c=>{if(r.o(e,a)&&(0!==(f=e[a])&&(e[a]=void 0),f)){var d=c&&("load"===c.type?"missing":c.type),b=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+d+": "+b+")",t.name="ChunkLoadError",t.type=d,t.request=b,f[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var f,d,b=c[0],t=c[1],o=c[2],n=0;if(b.some((a=>0!==e[a]))){for(f in t)r.o(t,f)&&(r.m[f]=t[f]);if(o)var i=o(r)}for(a&&a(c);n!function(e,t,a,n,g){e[n]=e[n]||[],e[n].push({"gtm.start":(new Date).getTime(),event:"gtm.js"});var m=t.getElementsByTagName(a)[0],r=t.createElement(a);r.async=!0,r.src="https://www.googletagmanager.com/gtm.js?id=GTM-W9BVQXM",m.parentNode.insertBefore(r,m)}(window,document,"script","dataLayer")
-
+
-
+
diff --git a/docs/BC-FAQs.html b/docs/BC-FAQs.html
index e9b0741e3f..8741a78443 100644
--- a/docs/BC-FAQs.html
+++ b/docs/BC-FAQs.html
@@ -9,7 +9,7 @@
-
+
@@ -90,7 +90,7 @@
Once the proposal is accepted, the owner of the base asset can list the trading pair.
For more information about this process please check the listing guide.
How would a third-party integrate with BNB Beacon Chain and Binance DEX?
A wallet provider may choose to only support the feature set of BNB Beacon Chain , which would just
cover wallets, addresses, balances and transfers.
To improve their implementation further, they could choose to integrate Binance DEX which would add trading (order placement and cancellation), historical order and trade views, charts, etc.
-
+
diff --git a/docs/BEP20.html b/docs/BEP20.html
index 50c51e9de9..b7b2fcf9e8 100644
--- a/docs/BEP20.html
+++ b/docs/BEP20.html
@@ -9,7 +9,7 @@
-
+
@@ -21,7 +21,7 @@
| Transaction fees | Low | High |
| Transaction speed | Fast | Slow |
| Smart contract compatibility | Compatible with Ethereum smart contracts | Not compatible with BSC smart contracts |
To implement a BEP20 token on BNB Smart Chain, you must use the IBEP20 interface. The IBEP20 interface defines the following functions: totalSupply(), balanceOf(address account), transfer(address recipient, uint256 amount), allowance(address owner, address spender), approve(address spender, uint256 amount), transferFrom(address sender, address recipient, uint256 amount).
In addition to these functions, the IBEP20 interface also defines a number of events that can be emitted by tokens, such as the Transfer event when tokens are transferred, the Approval event when an account approves another account to spend its tokens, and the Burn event when tokens are burned.
The IBEP20 interface is used by all tokens on the BSC, and it provides a common set of functions and events that can be used to interact with tokens. This makes it easier for developers to build applications that interact with tokens on the BSC, and it also makes it easier for users to understand how tokens on the BSC work.
All BEP20 tokens must implement the following methods:
totalSupply(): Returns the total supply of tokens.
balanceOf(): Returns the balance of tokens held by a specific address.
transfer(): Transfers a specific number of tokens to another address.
allowance(): Returns the maximum amount of tokens that an address is allowed to transfer on behalf of another address.
approve(): Sets the maximum amount of tokens that an address is allowed to transfer on behalf of another address.
transferFrom(): Transfers a specific number of tokens from one address to another address, on behalf of the first address.
To implement, compile, and deploy BEP20 tokens on BNB Smart Chain, users can use various different IDEs like Remix IDE, Truffle, Hardhat, etc. They can use Web3 wallets like Trust Wallet and Metamask for signing transactions and paying any gas cost that may incur.
from - String|Number: The address for the sending account. Uses the web3.eth.defaultAccount property, if not specified. Or an address or index of a local wallet in web3.eth.accounts.wallet.
to - String: (optional) The destination address of the message, left undefined for a contract-creation transaction.
value - Number|String|BN|BigNumber: (optional) The value transferred for the transaction in wei, also the endowment if it’s a contract-creation transaction.
gas - Number: (optional, default: To-Be-Determined) The amount of gas to use for the transaction (unused gas is refunded).
gasPrice - Number|String|BN|BigNumber: (optional) The price of gas for this transaction in wei, defaults to web3.eth.gasPrice.
data - String: (optional) Either a ABI byte string containing the data of the function call on a contract, or in the case of a contract-creation transaction the initialisation code.
nonce - Number: (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce.
// Make a transaction using the promise web3.eth.sendTransaction({ from: holder, to: '0x0B75fbeB0BC7CC0e9F9880f78a245046eCBDBB0D', value: '1000000000000000000', gas: 5000000, gasPrice: 18e9, }, function(err, transactionHash) { if (err) { console.log(err); } else { console.log(transactionHash); } });
A delegator can delegate its BNB to a chosen validator to participate the consensus and earn rewards. Staking BNB directly contributes to the security of the entire network.
Delegates and validators themselves may choose to unbond their BNB for a variety of reasons. It is important to note that these BNB are subject to what is known as the UnbondingTime, an on-chain parameterized period of time upon which all delegates, including validators, must wait for their BNB to become fully unbonded. In addition, these BNB are still subject to be potentially slashed upon commitment of any byzantine behavior. The UnbondingTime ensures a variety of security measures in the network, such as accounting for network synchrony assumptions, providing a lower bound for the length of a long-range attack and solving the “nothing-at-stake” problem.
The current UnbondingTime in BNB Smart Chain mainnet is 7 days.
Since validatorset info is updated every day UTC 00:00, to make some room for the error handling, we distribute the fees of day N-1 in the next breathe block (day N+1). Thus, after you sent delegate transaction, you will receive your first staking rewards at the second UTC 00:00. Afterwards, you will receive your rewards everyday at UTC 00:00.
Since Unbonding Period is 7 days. Thus, after you sent undelegate transaction, your staked BNB will not receive any rewards since the next UTC 00:00. After 7 days start from the next UTC 00:00, you will receive your BNB .
You can choose to move your staked BNB to a different validator by sending a redelegate transaction. For example, you can redelegate from validator A to validator B. Your BNB are still staked, and you can receive rewards from validator B since next 00:00 UTC
Redelegations between a unique delegator, source validator, and destination validator can only happen once every 7 days
The only risk for delegators is the loss of rewards when their staked validator is slashed. Their staked BNB will not be impacted.
Can a validator run away with their delegators' BNB?
By delegating to a validator, a user delegates voting power. This does not mean that the validator has custody of their delegators' BNB. By no means can a validator run away with its delegator's funds.
Can I receive my staking rewards if my chosen validator is inactive?
Annual Percentage Rate (APR) is the annual rate of interest paid to delegators net of commission. The calculation is based on the income of this validator 2 days ago. It is not compounded and updated every 24 hours.
Refer to here to learn about the different projects deployed on BSC.
What to do if I transferred funds to the exchange wallet but the exchange doesn't support the BSC chain?
Please be careful while doing transactions to other exchanges to check if they support or accept deposits through BSC or not. The confirmed transaction on the blockchain cannot be reverted as we also don't have any access to the wallet address.
What to do in case of a wrong network withdrawal issue?
Please try to use the wallet app which supports both BSC and ETH networks in it. So that you can access any network with the same address and transfer your funds out of the wrong network.
What to do in case of a Missing memo or wrong memo?
Please try to contact the support of the receiver address to help with the deposit. If it's an exchange wallet address then contact them with the correct memo.
The self-service window for BNB Pioneer Burn Program is now live. Eligible users who lose tokens as part of mistakes they made while making transactions on BNB Smart Chain can access this page and fill in the application form. We will investigate your case and help retrieve the assets if your case is qualified for the Program.
It is proposed to accommodate the small or micro projects, intellectual properties, and other small token economies. Similar to SME board in the traditional stock markets, BEP8 tokens markets will increase the liquidity of utility tokens of startups or Intellectual Property (IP) tokens by removing the capital requirements for listing. Besides, any BEP8 token issuer can choose to directly list against BNB and BUSD without the voting process of validators.
The rewards will not be sent to validator right away, instead, they will be distributed and accumulated on a contract. The reward distribution happens on BC around every day UTC 00:00.
Validators can suffer from “Slashing”, a punishment for their bad behaviors, such as double sign and/or instability. Such loss will not be shared by their delegators.
Slashing is a punitive function that is triggered by a validator ’s bad actions. Getting slashed is losing self delegation of a validator. Validators will be slashed for the actions below:
Going offline or unable to communicate with the network.
Double signing: If a validator node tries to split the network by signing two different blocks and broadcasting them, it will be removed from validator set definitely.
What is the process of getting selected as a validator node on BSC?
On BNB Smart Chain (BSC) network, validators are responsible for securing the network by processing transactions and signing blocks. Validator nodes are incentivized in the form of transaction fees for their good behavior. Currently, there are 21 validators on the testnet and 56 validators on the mainnet. Validators are selected every 24 hours. Anyone can become a candidate for the validator. To become part of the selection process of validators, the nodes have to stake their BNB. Validators can self-delegate (self-bound) BNB to themselves and can also receive delegations from any other BNB holders. The minimum amount for self-delegation is 2000BNB. Only the top 40 highest-stake nodes are chosen to be part of the validator set. Get more details here.
How is the bad or malicious behavior of the validator nodes controlled in the BSC?
One of the important on-chain governance implementations is the technique of “slashing” along with jailing. When jailed validator cannot participate in the consensus mechanism or earn rewards for set period of time. Slashing ensures that validators who act maliciously or show bad behavior are punished. Furthermore, it is designed to expose any attacker and make execution of their attempts extremely expensive. Anyone can submit BSC slash request. Even though BSC slash request requires slash evidence and transaction cost fees, huge reward is given in case the request is successful. To ensure that the delegators are not punished for the validator’s bad behavior, only the self-bonded BNB of the validator are slashed. Currently, slashing is applied on any node that processes an invalid transaction, performs double-signing or is unavailable for a defined period of time.
What is 'self-delegation'? How can I increase my 'self-delegation'?
Self-delegation is delegation from a validator to themselves. This amount can be increases by sending a delegate transaction from your validator's operator address.
What to do if one can’t run prune-state command In the event when running the geth snapshot prune-state --datadir /chaindata on geth 1.1.5 return the following error
ERROR[11-02|06:02:55.001] Failed to open snapshot tree err="head doesn't match snapshot: have 0x5c17a8fc0164dabedd446e954b64e8a54fc7c8b4fee1bbd707c3cc3ed1e45fff, want 0x431565cee8b7f3d7bbdde1265304fa4574dc3531e511e9ffe43ae79d28e431d6" head doesn't match snapshot: have 0x5c17a8fc0164dabedd446e954b64e8a54fc7c8b4fee1bbd707c3cc3ed1e45fff, want 0x431565cee8b7f3
This error occurs due to data corruption. You can run geth snapshot verify-state to double confirm whether the data is correct. You can download the latest snapshot from https://github.com/bnb-chain/bsc-snapshots. By doing that, you don't have to prune-state in the future, save precious disk IO, it will help you keep up with syncing.
What to do if Sync is slow on running the following command
Try pruning the state -- stop geth, then run geth --datadir=node - prune-state. Assuming that datadir is node, change that if it's elsewhere then restart after it's done. Follow https://github.com/bnb-chain/bsc/issues/502 to get more tips about how to maintain a synced node.
How to start the geth node through snapshot to get node synced?
The two biggest bottlenecks are CPU and IOPS when syncing. Steps are as follows:
Download the latest version of geth from the official site and make it executable, optionally move it /usr/local/bin/geth
Download mainnet.zip and unzip
Generate genesis using command below, will also create a mainnet folder for blockchain data ./geth_linux --datadir mainnet init genesis.json
[Optional] Open config.toml and delete the Node Log section, just useful for getting logs straight on the terminal or just use tail to look at the logs
[Optional] Create a service or use screen to run the command below, so it doesn't stop if you are using SSH.
Run screen then press enter, anytime you lose connection via ssh, run screen -r to get back the "screen/terminal" where geth was running Geth Command
Why is the tx from my dapp not visible on the bscscan even though its hash is generated?
Due to network congestion, it is possible for the tx to appear after a delay. Another possibility is that the number of pending txs have exceeded the size of the limited tx pool of the network and hence the txs have been dropped.
BNB Smart Chain brings EVM-compatible programmability and native cross-chain communication with BNB Beacon Chain using an innovative consensus of Proof of Staked Authority(PoSA).
Why is BNB Smart Chain designed as a separate chain from BNB Beacon Chain ?
The execution of a Smart Contract may slow down the exchange function and add non-deterministic factors to trading. Even if that compromise could be tolerated, it might be a straightforward idea to introduce a new Virtual Machine specification based on Tendermint, based on the current underlying consensus protocol and major RPC implementation of BNB Beacon Chain . But all these will increase the learning requirements for all existing dApp communities, and will not be very welcomed.
How does BNB Smart Chain work? What is the architecture and consensus used?
BNB Smart Chain relies on a system of 55 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees.
There will be fewer validators on BNB Smart Chain testnet.
Can you tell more about Proof of Staked Authority(PoSA)? What is it?
PoSA is a combination of PoA and PoS. Blocks are produced by a limited set of validators, they are elected in and out based on a staking based governance. Validators take turns to produce blocks in a PoA manner
What are the benefits for developers to build on BNB Smart Chain ?
EVM-compatible: BNB Smart Chain supports all the existing Ethereum tooling
Fast Finality: Fast block time
Cheaper Cost
Native cross-chain transfer & communication: Binance DEX remains a liquid venue of exchange of assets on BNB Beacon Chain and BNB Smart Chain
What are the benefits for developers to build on BNB Chain ?
BNB Chain opens the gate for users to take advantage of the fast transferring and trading
Fast Node does not generate Trie Data when syncing. Once the Fast Node is running, there is no way to switch back to Full Node. Need to re-download snapshot data to restore it to Full Node.
BNB Smart Chain explorers is a graphic user interface designed to allow users to interact with the blockchain. Through this interface, a user can browse information about blocks that have been added to the blockchain, transactions that have occurred on the blockchain, wallet balances, and information about BNB.
Currently, a BSC node has two kinds of state world: MPT and snapshot. MPT(Merkle Patricia Tries) is a tree-structured state world. The key function of MPT is to generate the state root to ensure state consistency, while the query/commit on MPT is quite slow. Snapshot is a flattened key-value-based state world. Snapshot provides fast queries and commits. The storage size of the snapshot increases slowly even with a large transaction volume. Snapshot is usually used for block processing, while MPT is used for state verification.
In order to lower the hardware requirement and keep security, we introduce two types of nodes to make full use of different storage, one is named fast node, and the other is named verify node. The fast node will do block processing with snapshot, it will do all verification against blocks except state root. The verify node receives diffhash from the fast node and then responds MPT root to the fast node.
The fast node doesn’t need to store MPT, so the storage and computation requirement will be much lower.
Fast Node: It does full sync using only Snapshot and generates difflayer. It needs the confirm message from the verify node before freezing the blocks, it has to wait until it receives a confirm message from the verify node for the ancestor block before inserting new blocks.
Verify Node: It is a normal BSC full node that does full sync using Snapshot and MPT, and generates difflayer. It receives diffhash from fast nodes, finds the corresponding difflayer whose diffhash is matched, then responds MPT root message to the fast node.
Introduce a new tries-verify-mode setting, there are four modes:
local: a normal full node with complete state world(both MPT and snapshot), merkle state root will be verified against the block header.
full: a fast node with only snapshot state world. Merkle state root is verified by the trustworthy remote verify node by comparing the diffhash(an identify of difflayer generated by the block) and state root.
insecure: same as full mode, except that it can tolerate without verifying the diffhash when verify node does not have it.
none: no merkle state root verification at all, there is no need to setup or connect remote verify node at all, it is more light comparing to full and insecure mode, but get a very little chance that the state is not consistent with other peers.
If the fast node runs in not local mode, the node will disable diff protocol by default, If the fast node runs in full or light mode, the node will enable trust protocol by default.
When a full node has enabled the trust protocol, it can serve as a verify node, at the same time, we will recommend you to enable persist diff, disable snap protocol and diff protocol when running a verify node.
BNB Smart Chain explorers is a graphic user interface designed to allow users to interact with the blockchain. Through this interface, a user can browse information about blocks that have been added to the blockchain, transactions that have occurred on the blockchain, wallet balances, and information about BNB.
BNB Smart Chain (BSC) explorer is a graphic user interface designed to allow users to interact with the blockchain. Through this interface, a user can browse information about blocks that have been added to the blockchain, transactions that have occurred on the blockchain, wallet balances, and information about BNB.
BNB Smart Chain (BSC) provides explorers for both its mainnet and testnet.
Mainnet is the term used to describe when a blockchain protocol is fully developed and deployed, meaning that cryptocurrency transactions are being broadcasted, verified, and recorded on a distributed ledger technology (blockchain).
BNB Smart Chain's mainnet can be used for deploying actual dApps on the BSC blockchain ad perform real transactions. Since this is the actual network, you will require to purchase real BNB tokens to perform different operations on the network.
There are multiple ways to purchase BNB Tokens for use on the mainnet. Other than the official Binance Extension Wallet, BNB Smart Chain supports several popular wallets like TrustWallet and MetaMask, to learn more about the supported wallets refer here. For a list of tutorials on how to use different supported wallets with BNB Smart Chain, refer here.
There are multiple ways to access the BSC mainnet. One possible method is to join the mainnet as a full node. You can also use the RPC endpoints specified here to connect to the mainnet. RPC endpoints may be used to interact with a node directly over HTTP or websockets. Using RPC, you may perform low-level operations like executing ABCI queries, viewing network/consensus state or broadcasting a transaction. RPC endpoints are also used with web wallets like MetaMask to connect to the BSC mainnet.
To get an overview of the BNB Smart Chain, refer here. To learn more about the ecosystem and the different development tools like APIs, IDEs, wallets, etc., that are available on the BSC network, you can refer here. You can visit DappRadar or BNBProject to view real-time ranking and tracking of BSC projects.
-
+
diff --git a/docs/ERC721.html b/docs/ERC721.html
index 8dc3c11d68..73c766df50 100644
--- a/docs/ERC721.html
+++ b/docs/ERC721.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
In our case we are minting from the account which deployed the token, which is given the minter role.
EIP-721 2 includes an optional metadata extension with a name, symbol and for each tokenID a tokenURI with can point to a JSON file with name, description and image for the given token ID.
How you create and host this metadata is up to you.
I would suggest using a domain that you control to point to where you host the data so that you can move it as required.
For this tutorial, we will use My JSON Server where we can store a single JSON file in a GitHub repository that we can access via a fake JSON server.
For production we need to store our metadata in a permanent location that can exist for the life of the token.
We will mint 1 NFT with token ID 1. Specify the address that you want to be the token holder (0xc7e4bBc4269fdC62F879834E363173aeE7895F45 is one of my test accounts)
A crypto wallet is a device or program used for transfer and storage of cryptocurrency. Crypto wallets can be of different types, such as paper wallets, hardware wallets, and software wallets. There are also several smartphone mobile apps and computer programs that provide a user-friendly way to create and manage wallets. Along with crytocurreny, crypto wallets store a collection of crypto keys that are used for sending, receiving, and taracking ownership of cryptocurrencies.
A keypair is a cryptographically-derived securely generated private and public keys. A private key and its corresponding public key are together known as a keypair. A wallet contains a collection of one or more keypairs and provides some means to interact with them. The security of any crypto wallet depends upon how the private key is stored.
The public key is known as the wallet's receiving address or simply its address. The wallet address may be shared and displayed freely. When another party is going to send some amount of cryptocurrency to a wallet, they need to know the wallet's receiving address. Depending on a blockchain's implementation, the address can also be used to view certain information about a wallet, such as viewing the balance, but has no ability to change anything about the wallet or withdraw any tokens.
In order to send cryptocurrencies to another address or to make any changes to the wallet, the private key is used for digitally signing the transactions. It is important to note that the private key must never be shared and should always be kept securely. If by any means access is gained to the private key attached to a wallet, the attacker can withdraw all the tokens contained. Furthermore, if the private key for a wallet is lost, any tokens that have been sent to or stored in that wallet's address are permanently lost.
Different wallet solutions offer different approaches to keypair security, interacting with the keypair, and signing transactions to use/spend the tokens. Some are easier to use than others. Some store and back up private keys more securely. BNB Smart Chain supports several wallets, giving its users the right to choose the right wallet for their required security and convenience.
If you want to be able to receive BNB and other supported tokens on the BNB Smart Chain blockchain, you will first need to create a wallet and configure key management.
Bitcoin Improvement Proposal (BIP) 39 defines a formula for the generation of a mnemonic sentence (also referred to as mnemonic words, seed phrase, recovery phrase, etc.) the generation of a seed from that mnemonic sentence. The seed phrase is used to produce your private and public keys.
BIP 32 is a specification for creating Hierarchical Deterministic wallets. They are wallets that from a root can generate multiple "child" private keys in a deterministic way. You only need to remember the "path" of the child key.For example hardware wallets use them from a single root you can generate separate keys for Bitcoin (with path m/44'/0'/0'/0) and Ethereum (path m/44'/60'/0'/0).
Binance Extension wallet would use a similar way to generate keys as Ethereum, i.e. derive the private key using BIP32/BIP44 with HD prefix as "44'/60'/", which is the same as Ethereum's derivation path.
Whenever you click on “Add Account”, your seed is extended at the end by a counter value which makes it possible to automatically derive an unlimited number of new addresses in your extension wallet.
Once you have downloaded the binary for your platform, you may drop it into any folder you like. Open a terminal window or cmd.exe in that folder, and then follow the examples on the documentation site.
For mainnet:
$ ./bnbcli
On Windows you would most likely use this instead:
C:\> bnbcli.exe
For testnet:
$ ./tbnbcli
On Windows you would most likely use this instead:
You can manage you keys locally without connecting to any node. But if you want to interact with BNB Beacon Chain, you need to connect to one of BNB Beacon Chain full nodes.
You can run your own full node, which may automatically connect to BNB Beacon Chain, and you can run your CLI there with your own full node. In the mean time, you can connect to any full nodes provided by other people.
chain-id is an important field to fill for every transaction sent from bnbcli. The chain-id for mainnet is Binance-Chain-Tigris, and is Binance-Chain-Ganges for testnet. Please choose the correct one in your case.
This is the default way to sign transactions with bnbcli. It will use the encrypted keystore files saved at bnbcli home. You need to specify which key to decrypt with --from.
Use Private Key in Hardware Wallet
First, you must add --ledger when creating a new address. For example,
bnbcli keys add test --ledger --index 0 --account 0
Then, the private key file in ledger will be used to generate a new address.
You could also specify --account and --index to generate more addresses. After the generation, you could use Ledger for signing.
When you use the address to sign transactions, bnbcli will send transactions to Ledger and get signatures. Then bnbcli build the signed transactions and boardcast them to full nodes.
For instance, if you want to send a token transfer transaction, you can use the above command. The flag --from is used to specify which key should be used to sign the transaction.
Before creating a new ledger key, make sure you have performed these steps:
Ledger device is installed, binance ledger app and the version should be later or equal to v1.1.3.
Connect your ledger device to your machine and input pin code to unlock it.
Open the binance ledger app on your ledger device.
bnbcli keys add test_ledger_key --ledger
Execute the above command to create a ledger key. The private key is only stored in your ledger device. And your local key store will save the corresponding publick key and address.
When you have downloaded BNB Chain CLI, you can use help subcommand to see all the available commands:
$ ./bnbcli help BNBChain light-client Usage: bnbcli [command] Available Commands: init Initialize light client status Query remote nodefor status txs Search for all transactions that match the given tags. tx Matches this txhash over all committed blocks account Query account balance send Create and sign a send tx transfer api-server Start the API server daemon keys Add or view local private keys version Print the app version token issue or view tokens dex dex commands gov gov commands help Help about any command Flags: -e, --encoding string Binary encoding (hex|b64|btc)(default "hex") -h, --help helpfor bnbcli --home string directory for config and data (default "/root/.bnbcli") -o, --output string Output format(text|json)(default "text") --trace print out full stack trace on errors Use "bnbcli [command] --help"formore information about a command.
Note:there is one special flag --trust-node of most subcommands, if not enabled which is by default the CLI
will take an extra 2-4 seconds to verify blockchain proof at current height. You can enable that flag if the peer is trustful so that most commands will accomplish in 500 milliseconds. If your node cannot prove the transaction, there will be the following notice:
Create verifier failed: Commit: Response error: RPC error -32603 - Internal error: runtime error: invalid memory address or nil pointer dereference Please check network connection and verify the address of the node to connect to
To solve this issue, you need to set --trust-node to true
bnbcli will save data about validatorset changes at home of bnbcli. If you want to use bnbcli for different blockchains, for example, you want to change from testnet to mainnet, the data will be stale. In order to switch between blockchains, you need clean the data folder with rm -rf ~/.bnbcli/.bnblite/ or create a new home folder for bnbcli with --home flag.
If you forget to specify a different home folder path, then you will not be able to make queries with bnbcli.
Hash of transaction, it returned as bytes before, and now it returns as hex string
log
string
Log of transaction
data
string
Data of transaction
height
string
Height of transaction
code
integer
Result code of transaction
ok
boolean
tx
object
Detail of transaction, like transaction type, messages and signature
For example, below is the detail of a send transaction. Most of the fields are fixed, but the detail of msg
varies with msg type, if you query with --format=json.
{ "type": "auth/StdTx", // fixed, type of transaction "value": { // fixed, detail of the transaction "data": null, // fixed, data of the transaction "memo": "", // fixed, memo "msg": [ // fixed, msgs of the transaction { "type": "cosmos-sdk/Send", // vary with msg type "value": { // value content vary with mst type "inputs": [ { "address": "bnb1vt4zwu5hy7tyryktud6mpcu8h2ehh6xw66gzwp", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ], "outputs": [ { "address": "bnb1kg8mh20tndur9d9rry4wjunhpfzcud30qzf0qv", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ] } } ], "signatures": [ // fixed, signatures of the transaction { "account_number": "0", "pub_key": { "type": "tendermint/PubKeySecp256k1", "value": "AoWY3eWBOnnvLPTz4RsUlX1pWCkLLPewu1vAAoTEzxzR" }, "sequence": "1", "signature": "6O2TQAgleFNPw4zIWBLaNvOf5dR7DHNSr2DwAPeFK6lokRqZd2KR2BD+WlmaWj4LdLo5N+utN1JtY41E91N0uw==" } ], "source": "0" // fixed, source of the transaction } }
tm.event = 'NewBlock' # new blocks tm.event = 'CompleteProposal' # node got a complete proposal tm.event = 'Tx' AND tx.hash = 'XYZ' # single transaction tm.event = 'Tx' AND tx.height = 5 # all txs of the fifth block tx.height = 5 # all txs of the fifth block
Tendermint provides a few predefined keys: tm.event, tx.hash and tx.height.
Note for transactions, you can define additional keys by providing tags with
DeliverTx response.
DeliverTx{ Tags: []*KVPair{ "agent.name": "K", } } tm.event = 'Tx' AND agent.name = 'K' tm.event = 'Tx' AND account.created_at >= TIME 2013-05-03T14:45:00Z tm.event = 'Tx' AND contract.sign_date = DATE 2017-01-01 tm.event = 'Tx' AND account.owner CONTAINS 'Igor'
Simply speaking, an archive node is a full node running with an additional special option, --gcmode archive. It stores all the historical data of the blockchain starting from the genesis block. As compared to a typical full node that just holds all the state change data for some latest blocks, an archive node always stores them for each block.
Developers are limited to querying the limited recent blocks to check the balance of an address and the state of a smart contract with a full node. It is hard to get all what they want as the blockchain is moving forward at the same time, while they can query any block at a specific point in time with an archive node.
Archive nodes are used by various applications on the blockchain for challenging use cases, including but not limited to the followings:
Automatic trading system needs historical data to optimize trading model
Verification modules need state data to verify transactions in time
Analytical tools need full historical data to do data analysis
Exchange in some wallets depends on archive node for fast and efficient transfers
Running an archive node will take a high cost as it includes all the block and state change data. First of all it needs the disk with sufficient capacity; besides this, the CPU and disk performance should be good enough to catch up with the latest block height.
A segment archive node is a node which has all the data from one starting block height to one ending block height, such as [19000000, latest]. To create such one archive node, you need a snapshot with starting block number, less than 19000000.
You can get snapshot from BNB Chain official documentation:
1.2 Build one full archive node with segmented archive nodes
Instead of putting all archive data on a single Geth instance, it is suggested to create multiple segment instances, each of them only serving part of the chain. To get better performance, it is suggested that each segment's size is better to control under 4TB. There will be around 40TB data in all(up to March, 2023). For all BSC snapshots you can refer to Free public BNB Smart Chain Archive Snapshot. The owner has put all BSC archive snapshots on S3. As described this path is public but is configured as requester-pays. This means you'll need an AWS account in order to download them. After having all the segments, you need one proxy to dispatch the requests to the right segment. And thanks the owner, one proxy was also implemented. Please follow the owner's guide to build.
Erigon has supported BSC mainnet. You can also refer to Free public BNB Smart Chain Archive Snapshot for the guide to run a BSC archive node with an Erigon client. The owner has switched to using an Erigon client for a BSC archive node recently. You can download the archive snapshot which is a tarball from aws s3. The s3 path is "s3://public-blockchain-snapshots/bsc/erigon-latest.tar.zstd". This path is public, but is configured as requester-pays. Also this means you'll need an AWS account in order to download it.
Command to download to local dir:
aws s3 cp --request-payer=requester "s3://public-blockchain-snapshots/bsc/erigon-latest.tar.zstd" local_data_dir tar --use-compress-program=unzstd -xvf erigon-latest.tar.zstd
Command to run:
./erigon --chain=bsc --datadir local_data_dir
The known Issue with an Erigon client is that it does not really keep up with the latest blocks as mentioned in the Github. If you want to keep up with the latest blocks it is suggested to run a BSC archive node with high performance disk such as NVME, or run a BSC full node with a Geth client at the same time which means you need one proxy that will ask Erigon if it has the block height and if not forward it to the Geth client.
Data size: Up to now(June, 2022), the whole data size is about 35TB with Geth client while it is about 6TB with Erigon client, much smaller.
Maturity: Erigon is new and not yet battle tested while Geth has been running a long time, more stable. Archive nodes with Geth client can support all RPC APIs while some of them are not supported well by Erigon client such as eth_getProof.
Complexity: It is easier to run one BSC archive node with an Erigon client than that with a Geth client. And it is nearly the same complexity if you want to keep up the latest blocks with a Erigon archive node & a Geth full node at the same time.
All in all, people can choose one of the methods above to run a BSC archive node based on their own requirements.
Developers building on BNB Smart Chain can now leverage Band’s decentralized oracle infrastructure. With Band’s oracle, they now have access to various cryptocurrency price data to integrate into their applications.
Currently, the following token symbols are supported. Going forward, this list will continue to expand based on developer needs and community feedback.
Currently, there are two methods for developers to query prices from Band’s oracle: through Band’s StdReference smart contract on BNB Smart Chain and through their bandchain.js JavaScript helper library.
To query prices from Band’s oracle through smart contracts, the contract looking to use the price values should reference Band’s StdReference contract. This contract exposes getReferenceData and getReferenceDataBulk functions.
getReferenceData takes two strings as the inputs, the base and quote symbol, respectively. It then queries the StdReference contract for the latest rates for those two tokens, and returns a ReferenceData struct, shown below.
struct ReferenceData { uint256 rate; // base/quote exchange rate, multiplied by 1e18. uint256 lastUpdatedBase; // UNIX epoch of the last time when base price gets updated. uint256 lastUpdatedQuote; // UNIX epoch of the last time when quote price gets updated. }
getReferenceDataBulk instead takes two lists, one of the base tokens, and one of the quotes. It then proceeds to similarly queries the price for each base/quote pair at each index, and returns an array of ReferenceData structs.
For example, if we call getReferenceDataBulk with ['BTC','BTC','ETH'] and ['USD','ETH','BNB'], the returned ReferenceData array will contain information regarding the pairs:
Band’s node helper library bandchain.js also supports a similar getReferenceData function. This function takes one argument, a list of token pairs to query the result of. It then returns a list of corresponding rate values.
-
+
diff --git a/docs/beaconchain.html b/docs/beaconchain.html
index f0af86d2c3..0bd9f0e71c 100644
--- a/docs/beaconchain.html
+++ b/docs/beaconchain.html
@@ -9,7 +9,7 @@
-
+
@@ -25,7 +25,7 @@
More information about how projects can set themselves up for this (via binance.com or partners) will come soon.
Binance DEX is the native marketplace on BNB Beacon Chain , allowing you to exchange digital assets issued and listed on it.
The matching happens within the blockchain nodes and all of the transactions are recorded on-chain, therefore forming a complete, auditable ledger of activity.
ATTENTION: The match logic on DEX is quite different from normal centralized exchange.
Please go over the trading and match spec below to get the best interests for your orders.
-
+
diff --git a/docs/beaconchain/CONTRIBUTING.html b/docs/beaconchain/CONTRIBUTING.html
index db5e8e3699..e45d61db06 100644
--- a/docs/beaconchain/CONTRIBUTING.html
+++ b/docs/beaconchain/CONTRIBUTING.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
appropriate to start the first line of a commit with 'doc' instead of
an issue number.
The first place to start is always looking over the current GitHub issues for the project you are
interested in contributing to. Issues marked with [help wanted][help-wanted] are usually pretty self-contained and a good place to get started.
Of course, feel free to create a new issue if you think something needs to be added or fixed.
Each account contains cryptographic authentication info. It is created by a user of the blockchain. It also includes public key, address, and account number/sequence number for replay protection. Whenever a new address receives an asset, the corresponding transaction would create an Account for that address, which contains balances across all assets that are owned on this address.
The balance (the amount of tokens) of each asset is composed of 3 different parts:
Available: the amount of tokens that can be transferred, and spent to swap (buy) other assets
Locked: the amount of tokens that has been used in any outstanding orders. Once the order terminates (either filled, canceled or expired), the locked amount will decrease.
Frozen: the amount of tokens that has been frozen via Freeze transactions.
You can query the account info with the following command on mainnet:
There are two ways of creating an account on BNB Chain : creating a key in a web wallet and creating a key via bnbcli. Please make sure you backup your mnemonic.
Follow the instructions and set your password (password is used to unlock the keystore file that you will get here):
Then click Download Keystore File and you will get a keystore file and be directed to mnemonic page. Make sure to back up mnemonic here as it will be used to restore your key.
You can get bnbcli by following instructions here.
You should get mnemonic if you follow the instructions above. You can restore you key via bnbcli or tbnbcli.
Restore your key
$ ./bnbcli keys addtest --recover Enter a passphrase for your key: Repeat the passphrase: > Enter your recovery seed phrase: more advice achieve mass clap nose bike bird busy section rigid model doll exchange guard theme catalog junior patrol valley depart decade convince master NAME: TYPE: ADDRESS: PUBKEY: testlocal tbnb14m2gcdjq7aqkdtu2m9qrqrl8eevzpqfj9xc0uu bnbp1addwnpepqt7nf2dwgfxv6kmzgwhzlp556yhdfeakfdejc6lp8xcddsv83kq552m63s9
Create a new key
You can also create a new key and you will get a new mnemonic with bnbcli or tbnbcli.
$ ./bnbcli keys add new_key Enter a passphrase for your key: Repeat the passphrase: NAME: TYPE: ADDRESS: PUBKEY: new_key local tbnb1c5dxrdn9xuw0njwcyevzyjrza550z5au8v0hyz bnbp1addwnpepqwdsud63f5rq2wkgrezlvzdauf4x7wp3defzvhrzkwdzl7p0n6uk666ghpa **Important** write this seed phrase in a safe place. It is the only way to recover your account if you ever forget your password. napkin degree boring custom differ smart bundle ball length lyrics auto forest jeans awake entry vocal there repeat rule churn picnic promote screen skull
BNB Beacon Chain has been through several iterations and evolutions, each time building upon work contributed by members of the blockchain community. We would like to acknowledge the outstanding work that we have been able to achieve during development. Let's build the future together!
There is no doubt that these two projects and their communities provided us from day one with countless creativity. They are the root and ground-zero of thought and keep providing us with brilliant utilities and ideas.
The Binance Dexathon concluded in September 2018, receiving prize winning submissions from teams that sent in some really impressive projects. Our internal work on BNB Beacon Chain was taking place in parallel to this and we are delighted to say that many of the projects helped to improve the final product.
Our current implementation is built on forks of Tendermint and Cosmos SDK. We make use of a revised edition of Tendermint consensus and leverage its p2p networking logic, and Cosmos SDK features such as "bank" which is used for basic token transactions. Some of the changes have been contributed back to the projects.
Projects like BNB Beacon Chain and Binance DEX are often built as forks of Bitcoin or as smart contracts on platforms like Ethereum. With a foundation of clean, well-structured code from Cosmos SDK, we were able to build on a codebase that we saw as a better alternative. Many thanks to the Cosmos developers and its community for their work (and for being really helpful in our issues and pull requests!)
Front-running means someone can get prior knowledge of transactions from other beneficial owners via technology or market advantage, so that they can influence the price beforehand and result in economic gain, which usually brings loss or cost to others. It is a daunting question asked to both centralized and other decentralized exchanges (DEX). Especially on some DEX, front-running actually happens quite often, e.g. via gas or timestamp manipulations, or slow matching.
There are several design points in Binance DEX that make front-running very difficult to execute.
Binance DEX matches orders in every block (with very fast block times). Fast matching leaves very little room for front-runner to react before the orders get executed properly. This is one of the fundamental parts of making front-running difficult, especially for normal market participants.
It is very difficult to argue that the exchange itself is not front-running if it has a centralized matching engine. Binance DEX have decentralized matching engines running on every block producer and full node. This way everyone can replay the order match manually with the transactions in the latest block with the current order book and can see the order matching in real-time if they run a full node.
Periodic auction matching per block lowers the importance of fast orders, i.e. fast orders do not benefit from high frequency trading behaviors even when being several hundreds of milliseconds faster (which is "really long time" for traditional exchanges).
Fast orders do not bring any advantage.
Periodic auction also adds a non-deterministic layer where no one can exactly know the next execution price unless he/she can exactly know all 3 things listed below:
the matching logic
the current order book and trade price from the last match
all incoming orders for the next block
1) and 2) may be visible to participants, especially for validators and others who closely watch the blockchain status, such as fast sync trading bots or full nodes.
But knowing 3) is very hard for normal market participant. Even if they run powerful accelerated node, they still cannot know all the incoming orders for the next block. Without this knowledge, even when someone can send orders faster, they cannot do effective front-running.
So with the above, the usual traders and even trading bots cannot do much to front-run others.
You might point out, that the validators have a chance to get information of 3) when they are "proposers" for the next block, i.e. they would "propose" what transactions to add for the next block. But the BNB Beacon Chain consensus model adds some additional randomness to make it more difficult:
Due to the fast matching, the bad validator have to prepare everything with earlier information in order to front-run the price. However, he cannot be too fast, because he cannot know the execution price of the last block until the last block is concluded, and the last execution price has direct impact on the execution price according to the match logic. Even more, any validator ahead of the bad validator's proposer turn can run into an issue and increase the consensus round, which would ask for re-arrangement on the proposing sequence. This makes it very hard to pre-determine the exact proposal sequence, making it so hard that the validator cannot be 100% sure when they can delay any other transactions and add their own transactions to the block earlier. Besides all of this, the bad validator cannot hold other transactions for too long: it either makes the bad behavior very observable on chain, or other validators would include the transactions anyway via P2P communication.
As a result, it is extremely hard to front-run anyone even while being a validator.
With the above description, you can clearly see that chance of front-running others on Binance DEX is much lower than on centralized exchanges and most of decentralized ones. However, you may still argue that for a very powerful and sophisticated validator, there is still a slim chance to front-run client orders (if they can do every difficult step very fast).
In the future, deterministic randomness may be applied in selecting the next proposer among validators, and the match of orders proposed to block can be postponed into the next 2 block. These two enhancements can greatly destroy the prediction accuracy of trading price, which would push the chance of front-running to 0. The cost of this is some latency in matching.
-
+
diff --git a/docs/beaconchain/atomic-swap.html b/docs/beaconchain/atomic-swap.html
index b3a9433bb9..80e966401b 100644
--- a/docs/beaconchain/atomic-swap.html
+++ b/docs/beaconchain/atomic-swap.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
During the swap process, the related fund will be locked to a purely-code-controlled escrow account.
A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account doesn't have its own private key and it's only controlled by code of the protocol. The code for calculating escrow account is the same that is used in cosmos-sdk:
The account for mainnet is: bnb1wxeplyw7x8aahy93w96yhwm7xcq3ke4f8ge93u and the account for testnet is: tbnb1wxeplyw7x8aahy93w96yhwm7xcq3ke4ffasp3d. Once the swap is claimed or refunded, the fund will be transferred from the purely-code-controlled escrow account to client accounts.
Receiver address, where the asset is to, if the proper condition meets.
No
recipient-other-chain
bytes
a byte array, maximum 32 bytes, in any proper encoding. leave it empty for single chain swap
Yes
sender-other-chain
bytes
a byte array, maximum 32 bytes, in any proper encoding. leave it empty for single chain swap
Yes
RandomNumberHash
32 bytes
hash of a random number and timestamp, based on SHA256. If left out, a random value will be generated
True
Timestamp
int64
Supposed to be the time of sending transaction, counted by second. It should be identical to the one in swap contract. If left out, current timestamp will be used.
No
OutAmount
Coins
similar to the Coins in the original Transfer defined in BEP2, assets to swap out
No
ExpectedIncome
string
Expected income from swap counter party, example: "100:BNB" or "100:BNB,10000:BTCB-1DE" The amount needs to be bumped by e^8
No
HeightSpan
int64
number of blocks to wait before the asset may be returned to From if not claimed via Random. The number must be larger than or equal to 360 (>2 minutes), and smaller than 518400 (< 48 hours)
No
CrossChain
bool
Specify if the HTLT is for cross chain atomic swap
After the deposit, you may observe that the balance of sender is decreased. The amount in deposit transaction must be positive. Besides, you can query the swap by swapID and the in_amount must equal to the amount that you balance decreased.
Claim Hash Timer Locked Transfer is to claim the locked asset by showing the random number value that matches the hash. Each HTLT locked asset is guaranteed to be release once.
const client =newBncClient("https://testnet-dex.binance.org") const privateKey = crypto.getPrivateKeyFromMnemonic(mnemonic) client.setPrivateKey(privateKey) const swapID ="61daf59e977c5f718f5aaedeaf69ccbea1c376db5274a84bca88848696164ffe"// the ID of an existing swap const randomNumber ="e8eae926261ab77d018202434791a335249b470246a7b02e28c3b2fb6ffad8f3"// the random number generated in htlt const res = client.swap.claimHTLT(from, swapID, randomNumber)
const client =newBncClient("https://testnet-dex.binance.org") const privateKey = crypto.getPrivateKeyFromMnemonic(mnemonic) client.setPrivateKey(privateKey) const swapID ="61daf59e977c5f718f5aaedeaf69ccbea1c376db5274a84bca88848696164ffe"// the ID of an existing swap const res = client.swap.refundHTLT(from, swapID, randomNumber)
Common error:
Already complete
ERROR: {"codespace":8,"code":12,"abci_code":524300,"message":"Expected swap status is Open, actually it is Completed"}
Not expired
ERROR:{"codespace":8,"code":8,"abci_code":524296,"message":"Current block height is 40003412, the expire height (40013236) is still not reached"}
Query atomic swap ID allows you to search swap history of an recipient. As this is a heavy query interface, some public nodes might close this query interface.
Query atomic swap ID allows you to search swap history of an initiator. As this is a heavy query interface, some public nodes might close this query interface.
Its corresponding address on testnet is: tbnb1pk45lc2k7lmf0pnfa59l0uhwrvpk8shsema7gron BNB Beacon Chain and 0xD93395B2771914E1679155F3EA58C41d89D96098 on Ethereum testnet
random_number_hash must equal to the randomNumberHash in client HTLT transaction on ethereum
to must equals to client wallet address
timestamp must equal to the timestamp in client HTLT transaction on ethereum
out_amount should be reasonable. Please note that the decimals of bep2 tokens is 8, the out_amount should be something around 10000000000:PPC, deputy will deduct some fees.
expire_height must not be passed and should be enough for send claim transaction
You should see that Deputy has already approved enough tokens and
In its event log, you should see the swapID. Before calling claim function on ethereum, clients should verify the parameters in the HTLT event.
_randomNumberHash must equal to the randomNumberHash in client HTLT transaction on BNB Beacon Chain
_recipientAddr must equal to client ethereum wallet address
_timestamp must equal to the timestamp in client HTLT transaction on BNB Beacon Chain
_outAmount should be reasonable. Please note that the decimals erc20 contract and deputy will deduct some fees.
_expireHeight must not be passed and should be enough for send claim transaction
Then, you can call the claim function:
Function: claim
Parameters:
_swapID: this has been obtained from event, you can also calculate it from calSwapID function in the contract. calSwapID(randomNumberHash, {deputy ethereum address}, {hex encoding client binance address})
-
+
diff --git a/docs/beaconchain/blockchain.html b/docs/beaconchain/blockchain.html
index 17eb2d0267..1ad680ee60 100644
--- a/docs/beaconchain/blockchain.html
+++ b/docs/beaconchain/blockchain.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
It is expected a block will be produced on a-few-of-seconds level among validators, and can include
from 0 up to several thousands of transactions.
please note the transactions are not stored as chain state, because they are stored in blocks, while
trades are not stored as state either, because they can be reproduced via balances and transactions.
For normal users, all the keys and addresses can be generated via Binance Web Wallet.
This default wallet would use a similar way to generate keys as Bitcoin, i.e. use 256 bits entropy to generate a 24-word mnemonic based on BIP39, and then use the mnemonic and an empty passphrase to generate a seed; finally use the seed to generate a master key, and derive the private key using BIP32/BIP44 with HD prefix as "44'/714'/", which is reserved at SLIP 44.
BNB Beacon Chain uses the same elliptic curve cryptography as the current Bitcoin implementation, i.e. secp256k1. Its private key is 32 bytes while public key is 33 bytes.
Addresses on BNB Beacon Chain are 20 bytes and may be expressed as:
Address = RIPEMD160(SHA256(compressed public key))
Typically, an address is encoded in the bech32 format which includes a checksum and human-readable prefix (HRP). However, it doesn't use the SegWit address format (because we do not have SegWit function anyway, so no witness program version etc.).
A BNB Beacon Chain address is therefore more similar to a Bitcoin Cash address, which does not include a SegWit program script.
Address format pseudo-code:
Address_Bech32 = HRP + '1' + bech32.encode(convert8BitsTo5Bits(RIPEMD160(SHA256(compressed public key))))
For BNB Beacon Chain address, the prefix is bnb for production network, and tbnb for testnet.
BNB Beacon Chain uses an ECDSA signature on curve secp256k1 against a SHA256 hash of the byte array of a JSON-encoded canonical representation of the transaction. For more information, please see this page.
-
+
diff --git a/docs/beaconchain/chain-access.html b/docs/beaconchain/chain-access.html
index aadb80547b..505358568a 100644
--- a/docs/beaconchain/chain-access.html
+++ b/docs/beaconchain/chain-access.html
@@ -9,7 +9,7 @@
-
+
@@ -29,7 +29,7 @@
block chain, the Sequence Number will be set to the same number as the one of latest transaction.
This logic forces the client to be aware of the current Sequence Number, either by reading from the
blockchain via API, or keep the counting locally by themselves. The recommended way is to keep
counting locally and re-synchronize from the blockchain periodically.
Note: mutli send transfer is a special kind of TRANSFER. In this case, you can consider this is a bucket, some addresses put tokens into it and other addresses get tokens out of it.
Once you have downloaded the binary for your platform, you may drop it into any folder you like. Open a terminal window or cmd.exe in that folder, and then follow the examples on the documentation site.
For mainnet:
$ ./bnbcli
On Windows you would most likely use this instead:
C:\> bnbcli.exe
For testnet:
$ ./tbnbcli
On Windows you would most likely use this instead:
You can manage your keys locally without connecting to any node. But if you want to interact with BNB Beacon Chain, you need to connect to one of BNB Beacon Chain full nodes.
You can run your own full node, which may automatically connect to BNB Beacon Chain, and you can run your CLI there with your own full node. In the mean time, you can connect to any full nodes provided by other people.
chain-id is an important field to fill for every transaction sent from bnbcli. The chain-id for mainnet is Binance-Chain-Tigris, and is Binance-Chain-Ganges for testnet. Please choose the correct one in your case.
This is the default way to sign transactions with bnbcli. It will use the encrypted keystore files saved at bnbcli home. You need to specify which key to decrypt with --from.
Use Private Key in Hardware Wallet
First, you must add --ledger when creating a new address. For example,
bnbcli keys add test --ledger --index 0 --account 0
Then, the private key file in ledger will be used to generate a new address.
You could also specify --account and --index to generate more addresses. After the generation, you could use Ledger for signing.
When you use the address to sign transactions, bnbcli will send transactions to Ledger and get signatures. Then bnbcli build the signed transactions and boardcast them to full nodes.
For instance, if you want to send a token transfer transaction, you can use the above command. The flag --from is used to specify which key should be used to sign the transaction.
Before creating a new ledger key, make sure you have performed these steps:
Ledger device is installed binance ledger app and the version should be later or equal to v1.1.3.
Connect your ledger device to your machine and input pin code to unlock it.
Open the binance ledger app on your ledger device.
bnbcli keys add test_ledger_key --ledger
Execute the above command to create a ledger key. The private key is only stored in your ledger device. And your local key store will save the corresponding publick key and address.
When you have downloaded BNB Beacon Chain CLI, you can use help subcommand to see all the available commands:
$ ./bnbcli help BNBChain light-client Usage: bnbcli [command] Available Commands: init Initialize light client status Query remote nodefor status txs Search for all transactions that match the given tags. tx Matches this txhash over all committed blocks account Query account balance send Create and sign a send tx transfer api-server Start the API server daemon keys Add or view local private keys version Print the app version token issue or view tokens dex dex commands gov gov commands help Help about any command Flags: -e, --encoding string Binary encoding (hex|b64|btc)(default "hex") -h, --help helpfor bnbcli --home string directory for config and data (default "/root/.bnbcli") -o, --output string Output format(text|json)(default "text") --trace print out full stack trace on errors Use "bnbcli [command] --help"formore information about a command.
Note:there is one special flag --trust-node of most subcommands, if not enabled which is by default the CLI
will take an extra 2-4 seconds to verify blockchain proof at current height. You can enable that flag if the peer is trustful so that most commands will accomplish in 500 milliseconds. If your node cannot prove the transaction, there will be the following notice:
Create verifier failed: Commit: Response error: RPC error -32603 - Internal error: runtime error: invalid memory address or nil pointer dereference Please check network connection and verify the address of the node to connect to
To solve this issue, you need to set --trust-node to true
bnbcli will save data about validatorset changes at home of bnbcli. If you want to use bnbcli for different blockchains, for example, you want to change from testnet to mainnet, the data will be stale. In order to switch between blockchains, you need clean the data folder with rm -rf ~/.bnbcli/.bnblite/ or create a new home folder for bnbcli with --home flag.
If you forget to specify a different home folder path, then you will not be able to make queries with bnbcli.
Note: mutli send transfer is a special kind of TRANSFER. In this case, you can consider this is a bucket, some addresses put tokens into it and other addresses get tokens out of it.
end time in in milliseconds, endTime - startTime should be smaller than 7 days
Yes
long
limit
query
default 10, max 50
No
integer
offset
query
default 0, max 10000
No
integer
startTime
query
start time in milliseconds
Yes
long
type
query
type
No
string
Notes:
The timeframe between endTime and startTime should be less than 7 days. The shorter timeframe will get faster response, and longer timeframe will trigger more strict rate limiter.
Currently, users can't perform any actions with Binance Bridge unless their wallets are connected. This widget is meant to be used client-side to improve the flow of connecting wallets.
This guide will help users migrate their existing calls of /api/v1/transactions-in-block, /api/v2/transactions-in-block, /api/v1/transactions to the new bock and transaction apis.
If you are also using undisclosed APIs from Explorer, you can also refer to this document for migration.
Otherwise, you can skip this document and refer to the api document.
Migration of /api/v1/transactions-in-block, /api/v2/transactions-in-block
The new api can query all historical blocks' transactions, not only blocks in the past 24 hours.
The rate limit is 1000 requests per ip in 5 minutes, which is much bigger comparing to the rate limits of /api/v1/transactions-in-block, /api/v2/transactions-in-block.
All the amount/quantity/price/fee will be returned as Long. For converting them to floats (as old response in /api/v1/transactions-in-block, /api/v2/transactions-in-block), you need to divide them by 10e8.
For the data field, the response in new api could be different, please refer to the tx examples for more details.
You can search CROSS_TRANSFER_OUT transactions by using BC or BSC addresses.
You can search CREATE_SIDECHAIN_VALIDATOR, SIDECHAIN_DELEGATE, SIDECHAIN_REDELEGATE, SIDECHAIN_UNBOND transactions by using validator address.
Optimization of address parameter
You can search multi send transfers by any address involved in the transaction.
You can search HTL_TRANSFER transactions by any address involved in the transaction.
Optimization of asset parameter
You can search NEW_ORDER, CANCEL_ORDER, MINI_TOKEN_LIST, LISTING transactions using base or quote asset.
You can search SUBMIT_PROPOSAL, SIDE_SUBMIT_PROPOSAL transaction if the related proposal is Listing.
You can search DEPOSIT_HTL HTL_TRANSFER, SIDE_DEPOSIT, TIME_LOCK, TIME_RELOCK, TRANSFER transactions by any kind of asset involved in the transactions.
The rate limit is 500 requests per ip in 5 minutes, which is much bigger comparing to the rate limit of /api/v1/transactions.
Some query parameter names changed (e.g., txAsset->asset, txType->type), and some parameters are removed (e.g., blockHeight), please do read the new api docs.
All the amount/quantity/price/fee will be returned as Long. For converting them to floats (as old response in /api/v1/transactions), you need to divide them by 10e8.
For the data field, the response in new api could be different, please refer to the tx examples for more details.
Hash of transaction, it returned as bytes before, and now it returns as hex string
log
string
Log of transaction
data
string
Data of transaction
height
string
Height of transaction
code
integer
Result code of transaction
ok
boolean
tx
object
Detail of transaction, like transaction type, messages and signature
For example, below is the detail of a send transaction. Most of the fields are fixed, but the detail of msg
varies with msg type, if you query with --format=json.
{ "type": "auth/StdTx", // fixed, type of transaction "value": { // fixed, detail of the transaction "data": null, // fixed, data of the transaction "memo": "", // fixed, memo "msg": [ // fixed, msgs of the transaction { "type": "cosmos-sdk/Send", // vary with msg type "value": { // value content vary with mst type "inputs": [ { "address": "bnb1vt4zwu5hy7tyryktud6mpcu8h2ehh6xw66gzwp", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ], "outputs": [ { "address": "bnb1kg8mh20tndur9d9rry4wjunhpfzcud30qzf0qv", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ] } } ], "signatures": [ // fixed, signatures of the transaction { "account_number": "0", "pub_key": { "type": "tendermint/PubKeySecp256k1", "value": "AoWY3eWBOnnvLPTz4RsUlX1pWCkLLPewu1vAAoTEzxzR" }, "sequence": "1", "signature": "6O2TQAgleFNPw4zIWBLaNvOf5dR7DHNSr2DwAPeFK6lokRqZd2KR2BD+WlmaWj4LdLo5N+utN1JtY41E91N0uw==" } ], "source": "0" // fixed, source of the transaction } }
Hash of transaction, it returned as bytes before, and now it returns as hex string
log
string
Log of transaction
data
string
Data of transaction
height
string
Height of transaction
code
integer
Result code of transaction
ok
boolean
tx
object
Detail of transaction, like transaction type, messages and signature
For example, below is the detail of a send transaction. Most of the fields are fixed, but the detail of msg
varies with msg type, if you query with --format=json.
{ "type": "auth/StdTx", // fixed, type of transaction "value": { // fixed, detail of the transaction "data": null, // fixed, data of the transaction "memo": "", // fixed, memo "msg": [ // fixed, msgs of the transaction { "type": "cosmos-sdk/Send", // vary with msg type "value": { // value content vary with mst type "inputs": [ { "address": "bnb1vt4zwu5hy7tyryktud6mpcu8h2ehh6xw66gzwp", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ], "outputs": [ { "address": "bnb1kg8mh20tndur9d9rry4wjunhpfzcud30qzf0qv", "coins": [ { "amount": "100000000000000", "denom": "BNB" } ] } ] } } ], "signatures": [ // fixed, signatures of the transaction { "account_number": "0", "pub_key": { "type": "tendermint/PubKeySecp256k1", "value": "AoWY3eWBOnnvLPTz4RsUlX1pWCkLLPewu1vAAoTEzxzR" }, "sequence": "1", "signature": "6O2TQAgleFNPw4zIWBLaNvOf5dR7DHNSr2DwAPeFK6lokRqZd2KR2BD+WlmaWj4LdLo5N+utN1JtY41E91N0uw==" } ], "source": "0" // fixed, source of the transaction } }
Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries.
The base endpoint for mainnet is: wss://dex.binance.org/api/.
The base endpoint for testnet is: wss://testnet-dex.binance.org/api/.
Each connection can consume a single stream or multiple streams may be multiplexed through one connection for more complex apps.
All symbols in stream names are lowercase.
Stream names may be provided in the URL or there is a mechanism to subscribe to consume streams on demand through one connection.
Note: Once the connection is established, the websocket server will send ping frame to the client every 30 seconds. The client should reply with pong frame in time (this has already been implemented by most modern browsers, but programmatical users need to be aware of whether your websocket library supports this), otherwise, the connection might be closed.
Examples of each of these methods are provided below in JavaScript:
Using this method, stream names are specified in the URLs used to connect to the data streams:
Single streams /ws/<streamName>
Mainnet Example: Various methods of connecting to streams where stream names are provided in URLs:
// for personal streams, ex: Account & Transfers const accountAndOrdersFeeds =newWebSocket("wss://dex.binance.org/api/ws/<USER_ADDRESS>"); // for all symbols const blockHeight =newWebSocket("wss://dex.binance.org/api/ws/$all@blockheight");
Testnet Example: Various methods of connecting to streams where stream names are provided in URLs:
// for personal streams, ex: Account & Transfers const accountAndOrdersFeeds =newWebSocket("wss://testnet-dex.binance.org/api/ws/<USER_ADDRESS>"); // for all symbols const blockHeight =newWebSocket("wss://testnet-dex.binance.org/api/ws/$all@blockheight");
After connecting successfully you can subscribe/unsubscribe to different topics.
Example: To subscribe to transfer events, you should send a socket message with the subscribe payload as below:
const conn =newWebSocket("wss://dex.binance.org/api/ws/bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x"); conn.onopen=function(evt){ // for personal topics such as accounts & transfers, an `address` is required // Note: one connection is only allowed to subscribe to one address. // If you subscribe to a new address, regardless of whether the topic is new, the subscriptions for the previous addresses will be removed. conn.send(JSON.stringify({method:"subscribe",topic:"transfers",address:"bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x"})); }
Example: To unsubscribe from orders events, you should send a socket message with payloads as below:
// unsubscribe from topic conn.send(JSON.stringify({method:"unsubscribe",topic:"transfers"}));
Example: To extend connection life, you should send a message with a payload using the keepAlive method:
// This will extend the connection time to another 30 minutes // It's good to send this message every 30 minutes to maintain the connection life conn.send(JSON.stringify({method:"keepAlive"}));
Example: To close a connection, you should send a socket message with a payload as below:
// Connections will auto close after 30 - 60 minutes if no "keepAlive" messages received // Connections with no subscriptions will be closed, regardless the keepAlive messages. conn.send(JSON.stringify({method:"close"}));
Several data streams are exposed over standard WebSocket connections, which can be consumed by modern web browsers and server-side WebSocket libraries.
The base endpoint for mainnet is: wss://dex.binance.org/api/.
Each connection can consume a single stream or multiple streams may be multiplexed through one connection for more complex apps.
All symbols in stream names are lowercase.
Stream names may be provided in the URL or there is a mechanism to subscribe to consume streams on demand through one connection.
Note: Once the connection is established, the websocket server will send ping frame to the client every 30 seconds. The client should reply with pong frame in time (this has already been implemented by most modern browsers, but programmatical users need to be aware of whether your websocket library supports this), otherwise, the connection might be closed.
Examples of each of these methods are provided below in JavaScript:
Using this method, stream names are specified in the URLs used to connect to the data streams:
Single streams /ws/<streamName>
Mainnet Example: Various methods of connecting to streams where stream names are provided in URLs:
// for personal streams, ex: Account & Transfers const accountAndOrdersFeeds =newWebSocket("wss://dex.binance.org/api/ws/<USER_ADDRESS>"); // for all symbols const blockHeight =newWebSocket("wss://dex.binance.org/api/ws/$all@blockheight");
After connecting successfully you can subscribe/unsubscribe to different topics.
Example: To subscribe to transfer events, you should send a socket message with the subscribe payload as below:
const conn =newWebSocket("wss://dex.binance.org/api/ws/bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x"); conn.onopen=function(evt){ // for personal topics such as accounts & transfers, an `address` is required // Note: one connection is only allowed to subscribe to one address. // If you subscribe to a new address, regardless of whether the topic is new, the subscriptions for the previous addresses will be removed. conn.send(JSON.stringify({method:"subscribe",topic:"transfers",address:"bnb17zw3mqjx64x4dxtwqjqz5tssql6qp2m0cgv06x"})); }
Example: To unsubscribe from orders events, you should send a socket message with payloads as below:
// unsubscribe from topic conn.send(JSON.stringify({method:"unsubscribe",topic:"transfers"}));
Example: To extend connection life, you should send a message with a payload using the keepAlive method:
// This will extend the connection time to another 30 minutes // It's good to send this message every 30 minutes to maintain the connection life conn.send(JSON.stringify({method:"keepAlive"}));
Example: To close a connection, you should send a socket message with a payload as below:
// Connections will auto close after 30 - 60 minutes if no "keepAlive" messages received // Connections with no subscriptions will be closed, regardless the keepAlive messages. conn.send(JSON.stringify({method:"close"}));
tm.event = 'NewBlock' # new blocks tm.event = 'CompleteProposal' # node got a complete proposal tm.event = 'Tx' AND tx.hash = 'XYZ' # single transaction tm.event = 'Tx' AND tx.height = 5 # all txs of the fifth block tx.height = 5 # all txs of the fifth block
Tendermint provides a few predefined keys: tm.event, tx.hash and tx.height.
Note for transactions, you can define additional keys by providing tags with
DeliverTx response.
DeliverTx{ Tags: []*KVPair{ "agent.name": "K", } } tm.event = 'Tx' AND agent.name = 'K' tm.event = 'Tx' AND account.created_at >= TIME 2013-05-03T14:45:00Z tm.event = 'Tx' AND contract.sign_date = DATE 2017-01-01 tm.event = 'Tx' AND account.owner CONTAINS 'Igor'
All kinds of transactions have the same type of Fee and Signatures, the difference is the msg part.
Adding new transaction types would not require fork of blockchain, while upgrading transaction would be done via adding new transaction type: e.g. Burn2 vs. Burn.
type Msg struct{ From sdk.Address `json:"from"` Id string`json:"id"` Pair string`json:"pair"` Type int8`json:"type"` Side int8`json:"side"` Price int64`json:price` Quantity int64`json:"quantity"` TimeInForce int8 `json:"tif" }
type Msg struct{ From sdk.Address `json:"from"` Name string`json:"name"` Symbol string`json:"symbol"` Supply int64`json:"supply"` Decimals int8`json:"decimals"` }
type Msg struct{ From sdk.AccAddress `json:"from"` Name string`json:"name"` Symbol string`json:"symbol"` TotalSupply int64`json:"total_supply"` Mintable bool`json:"mintable"` TokenURI string`json:"token_uri"` }
-
+
diff --git a/docs/beaconchain/develop/node/extra-info.html b/docs/beaconchain/develop/node/extra-info.html
index c27a52dd04..5a49f00d13 100644
--- a/docs/beaconchain/develop/node/extra-info.html
+++ b/docs/beaconchain/develop/node/extra-info.html
@@ -9,7 +9,7 @@
-
+
@@ -30,7 +30,7 @@
Then, the full node will save messages that you are interested into Kafka, and you can consume them in your own apps.
The message is encoded based on Avro serialization system.
Their schemas are shown below:
This error is caused by the handshake failing between two peers.
Solution
To solve this problem, you need to make sure node_key.json is under $BNCHOME/config and nodes will try to re-connect automatically, so this issue should not persist.
The BNB Beacon Chain has a hardfork upgrade and if you failed to upgrade your fullnode to the latest version, bnbchaind process will stop and even if you restart with the latest version, the following error will appear:
panic: Tendermint state.AppHash does not match AppHash after replay. Got , expected 393887B67F69B19CAB5C48FB87B4966018ABA893FB3FFD241C0A94D2C8668DD2 goroutine 1 [running]: github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.checkAppHash(0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, 0x20, ...) /Users/huangsuyu/go/src/github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus/replay.go:464 +0x213 github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.(*Handshaker).ReplayBlocks(0xc000b37980, 0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, ...)
To recover from the state conflict error, you need to:
Backup your home directory, (default is ~/.bnbchaind)
Get the height of upgrade, this height will be announced in the upgrade announcement on the forum. For example, if it's announced as 5000 in the forum and run the following command will make your full node recover to the last block before the upgrade, and that is 4999 :
If you do not download the binaries completely, you will see the following message:
./bnbchaind: line 1: version: command not found ./bnbchaind: line 2: oid: command not found /Library/Developer/CommandLineTools/usr/bin/size: 45160816 No such file or directory
Since the old binaries are stored in git lfs previously, you will see this error if the binary is not complete. Please use this repo to download the binaries.
Once you have your own node running, you can start querying from it. But sometimes you may not be ablt to get the information you want. For example:
curl'localhost:27147/block?height=10'
The reason is because your node is using statesync to catch up. In this way, it will not store all the history blocks before the snapshot height it got. You can only query blocks after that snapshot height.
To enable query history blocks, you need to use fast-sync
The reason is that you didn't enable transaction height indexer. To enable this indexer, you need to make the following changes in your config.toml file:
index_tags= "tx.hash,tx.height"
Meanwhile, if you wish to enable range query, you also need to enable that setting in config.toml
enable_range_query = true
In this way, you can use Operator ["<", ">", ">=", "<="] in your query. For example,
curl"http://localhost:27147/tx_search?query=\"tx.height>59970127 AND tx.height<59973127\"&prove=true"
This error is caused by the handshake failing between two peers.
Solution
To solve this problem, you need to make sure node_key.json is under $BNCHOME/config and nodes will try to re-connect automatically, so this issue should not persist.
The BNB Beacon Chain has a hardfork upgrade and if you failed to upgrade your fullnode to the latest version, bnbchaind process will stop and even if you restart with the latest version, the following error will appear:
panic: Tendermint state.AppHash does not match AppHash after replay. Got , expected 393887B67F69B19CAB5C48FB87B4966018ABA893FB3FFD241C0A94D2C8668DD2 goroutine 1 [running]: github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.checkAppHash(0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, 0x20, ...) /Users/huangsuyu/go/src/github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus/replay.go:464 +0x213 github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.(*Handshaker).ReplayBlocks(0xc000b37980, 0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, ...)
To recover from the state conflict error, you need to:
Backup your home directory, (default is ~/.bnbchaind)
Get the height of upgrade, this height will be announced in the upgrade announcement on the forum. For example, if it's announced as 5000 in the forum and run the following command will make your full node recover to the last block before the upgrade, and that is 4999 :
If you do not download the binaries completely, you will see the following message:
./bnbchaind: line 1: version: command not found ./bnbchaind: line 2: oid: command not found /Library/Developer/CommandLineTools/usr/bin/size: 45160816 No such file or directory
Since the old binaries are stored in git lfs previously, you will see this error if the binary is not complete. Please use this repo to download the binaries.
Once you have your own node running, you can start querying from it. But sometimes you may not be ablt to get the information you want. For example:
curl 'localhost:27147/block?height=10'
The reason is because your node is using statesync to catch up. In this way, it will not store all the history blocks before the snapshot height it got. You can only query blocks after that snapshot height.
To enable query history blocks, you need to use fast-sync
This guide will explain how to install the binaries: bnbchaind and bnbcli, onto your server. With these installed on a server, you can participate in the mainnet or testnet as a Full Node. Full Nodes of BNB Beacon Chain also help the network by accepting transactions from other nodes and then relaying them to the core BNB Chain network.
-
+
diff --git a/docs/beaconchain/develop/node/join-mainnet.html b/docs/beaconchain/develop/node/join-mainnet.html
index f5ea0f9018..85835a0a53 100644
--- a/docs/beaconchain/develop/node/join-mainnet.html
+++ b/docs/beaconchain/develop/node/join-mainnet.html
@@ -9,7 +9,7 @@
-
+
@@ -21,7 +21,7 @@
The latest log file is bnc.log. The process will create a new log file every one hour.
To make sure you have sufficient disk space to keep the log files, we strongly recommend you to change the log location by changing logFileRoot option in $BNCHOME/config/app.toml.
Service Port: RPC service listens on port 27147 and P2P service listens on port 27146 by default.
Make sure these two ports are open before starting a full node, unless the full node has to listen on other ports.
Store: All the state and block data will store under $BNCHOME/data, do not delete or edit any of these files.
-
+
diff --git a/docs/beaconchain/develop/node/join-testnet.html b/docs/beaconchain/develop/node/join-testnet.html
index f03e2e5f9d..dc14855869 100644
--- a/docs/beaconchain/develop/node/join-testnet.html
+++ b/docs/beaconchain/develop/node/join-testnet.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
The latest log file is bnc.log. The process will create a new log file every one hour.
To make sure you have sufficient disk space to keep the log files, we strongly recommend you to change the log location by changing logFileRoot option in $BNCHOME/config/app.toml.
Service Port: RPC service listens on port 27147 and P2P service listens on port 27146 by default.
Make sure these two ports are open before starting a full node, unless the full node has to listen on other ports.
Store: All the state and block data will store under $BNCHOME/data, do not delete or edit any of these files.
-
+
diff --git a/docs/beaconchain/develop/node/nodetypes.html b/docs/beaconchain/develop/node/nodetypes.html
index 68894a5fb6..599ec854dd 100644
--- a/docs/beaconchain/develop/node/nodetypes.html
+++ b/docs/beaconchain/develop/node/nodetypes.html
@@ -9,7 +9,7 @@
-
+
@@ -24,7 +24,7 @@
at the same time around the world (owned by different organizations) and you are encouraged to choose
one of them to use, or allow your Wallet choose one randomly.
For rapid API access, you'd better stay with one Accelerated Node to get better performance.
For mainnet, there are more accelerated nodes.
dex-atlantic.binance.org
dex-asiapacific.binance.org
dex-european.binance.org
For testnet, there are 2 accelerated nodes setup as below. API users should try to use them directly.
testnet-dex-atlantic.binance.org
testnet-dex-asiapacific.binance.org
To see the existing endpoints provided by Accelerated node, check the list here!
This snapshot can be used for jumpstarting a newly setup fullnode to avoid waiting a long time for getting all blocks. In BNB Beacon Chain , the average block time is less than a second. As a result, it will take several weeks to sync from genesis block.
!!! Note
Ensure there is enough disk space for both the tar file AND its uncompressed contents. Double the space or more.
In fast sync, you need to download all the blocks from your peers and execute all the transactions in every block. The sync speed is about 20 blocks/sec, which is slower than state sync.
Configuration is located in $BNCHOME/config/config.toml:
The default way to get newly joined Full Node syncing with other Full Node is state sync. Once your Full Node is synced to a snapshot, it will switch to fast-sync mode to catch up with its peers.
State sync can help fullnode in same status with other peers within short time (according to our test, a one month ~800M DB snapshot in BNB Beacon Chain testnet can be synced in around 45 minutes). As explained in BEP18, State sync will get the application state of your full node to be up to date without downloading all of the blocks.The sync speed is faster than fast sync.
Now you do not need to allocate more memories to your full node for this feature to work.
Configuration is located in $BNCHOME/config/config.toml:
state_sync_reactor Must be set to true
recv_rate Must set to 102428800
ping_interval Recommendation is set to 10m30s
pong_timeout Recommendation is set to 450s
state_sync_height Recommendation is set to 0, so it allows to state sync from the peers's latest height.
State sync can help you receive latest blocks/transactions and query latest status of orderbook, account balances etc.. But state sync DOES NOT download historical blocks before state sync height, if you start your node with state sync and it synced at height 10000, then your local database would only have blocks after height 10000.
If full node has already started, suggested way is to delete the (after backup) $BNCHOME/data directory and $BNCHOME/config/priv_validator_key.json before enabling state sync.
If you turn on the state_sync_reactor, the snapshots of heights will be saved at $HOME/data/snapshot/ automatically. To save disk space, you can delete the directory or turn off the state_sync_reactor.
If state sync did not succeed, please repeat deletion of $BNCHOME/data directory and $BNCHOME/config/priv_validator_key.json before starting full node next time in case of data inconsistency.
Once state sync succeeded, later full node restart would not state sync anymore (in case the local blocks are not continuous).
But if you do want state sync again (don't care that there are missing blocks between last stop and latest state sync snapshot) and you want to keep already synced blocks, you can just delete $BNCHOME/data/STATESYNC.LOCK.
For example, you start your full node at Jan 1st with state sync at height 10000 and after a while you shut it down at height 22000 on Feb 10th. Now its Mar 1st, latest sync-able block height is 50000, you don't care blocks between 22000 and 50000, you can delete $BNCHOME/data/STATESYNC.LOCK before start your node. Then the full node would continue state sync from height 50000.
Turning off state_sync_reactor and state_sync can save your memory after you successfully state synced.
In BNB Beacon Chain network, almost every fullnode operator will first enable state-sync to get synced with peers. After downloading all the state machine changes, the fullnode will go back to fast-sync mode and eventually in consensus mode. In fast-sync mode, the fullnode will have high delay because it needs to be aware of peers’ heights. It downloads all the blocks in parallel and verifying their commits. On the other hand, when a fullnode is under consensus state, it will consume a lot of bandwidth and CPU resources because it receives a lot of redundant messages for consensus engine and writes more WAL. To increase the efficiency for fullnodes, the hot-sync protocol is introduced. A fullnode under hot-sync protocol will pull the blocks from its peers and it will subscribe these blocks in advance. It will skip the message for prevotes and only subscribe to maj23 precommit and block proposal messages. At the same time, it will put its peers in different buckets and subscribe to peers in active buckets. Hot-Sync can help fullnodes gossip blocks in low latency, while cost less network, memory, cpu and disk resources than Tendermint consensus protocol. Even cheap hardware can easily run a fullnode, and a fullnode can connect with more peers than before by saving network and CPU resources.
The state transition of a hot sync reactor can be of three part:
Hot --> Consensus ^ ^ | / | / Mute
Mute: will only answer subscribe requests from others, will not sync from others or from consensus reactor. The Hot Sync reactor stays in Mute when it is fast syncing.
Hot: handle subscribe requests from other peers as a publisher, also subscribe block messages from other peers as a subscriber. A non-validators will stay in Hot when the peer have catch up after fast syncing.
Consensus: handle subscribes requests from other peers as a publisher, but get block/commit message from consensus reactor. A sentry node should stay in Consensus. Or a non-validator should switch from Hot to Consensus when it become a validator.
Configuration is located in $BNCHOME/config/config.toml:
hot_sync_reactor Must be set to true
hot_sync Can be set to false or true
hot_sync_timeout is the max wait time for subscribe a block. It only takes effect when hot_sync is true
The BNB Beacon Chain has a hardfork upgrade and if you failed to upgrade your fullnode to the latest version, bnbchaind process will stop and even if you restart with the latest version, the following error will appear:
panic: Tendermint state.AppHash does not match AppHash after replay. Got , expected 393887B67F69B19CAB5C48FB87B4966018ABA893FB3FFD241C0A94D2C8668DD2 goroutine 1 [running]: github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.checkAppHash(0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, 0x20, ...) /Users/huangsuyu/go/src/github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus/replay.go:464 +0x213 github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.(*Handshaker).ReplayBlocks(0xc000b37980, 0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, ...)
To recover from the state conflict error, you need to:
Backup your home directory, (default is ~/.bnbchaind)
Get the height of upgrade, this height will be announced in the upgrade announcement on the forum. For example, if it's announced as 5000 in the forum and run the following command will make your full node recover to the last block before the upgrade, and that is 4999 :
RPC endpoints may be used to interact with a node directly over HTTP or websockets. Using RPC, you may perform low-level operations like executing ABCI queries, viewing network/consensus state or broadcasting a transaction.
Amino supports JSON encoding natively, which is the same as other usual json marshalers. Except that it can add one more type info for registered type, as shown below.
Binary encoding is a variant of Google's protobuf. The bytes are laid out in the below sequence:
a varint encoded integer - it contains the length of the encoded bytes for the object, which is displayed as SIZE-OF-ENCODED in the below structs. Please note that it contains the length of encoded bytes and also the type prefix (below), but not itself, e.g. if the encoded msg is 20 bytes, then the length would be 20 + 4 = 24, while 4 is used for the type prefix bytes.
an object type prefix of 4-8 bytes - For different type of objects, there will be different type prefixes, and they are displayed as in the specific objects below (data structures).
a binary encoded object - the encoding is mostly the same as protocol buffer encoding mechanism, except the embedded fields of complex type:
to encode data field of some specific types, an object type prefix for the field will be added ahead of the real encoding.
repeated (array) Encoding - it is the same as google protocol buffer, while encoding of the object/struct may contain the type prefix as shown below.
Below are the data types that can be sent to BNB Beacon Chain as requests, and their encoding layout. To simplify the presentation, we will use a variant of Google protocol buffer proto3 language to illustrate how the data fields are organized. Except the all-capitalized fields, other fields will use the default proto3 encoding logic.
Transactions are each wrapped in the below "Standard Transaction": structure:
// please note the field name is the JSON name. message StdTx { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding, please note this includes both the below type prefix (4 bytes) and the all encoding bytes 0xF0625DEE// hardcoded, object type prefix in 4 bytes repeated Msg msgs // array of size 1, containing the transaction message, which are one of the transaction types below. please check the above "Array Encoding" repeated StdSignature signatures // array of size 1, containing the standard signature structure of the transaction sender string memo // a short sentence of remark for the transaction. Please only `Transfer` transaction allows 'memo' input, and other transactions with non-empty `Memo` will be rejected. int64 source // an identifier for tools triggerring this transaction, set to zero if unwilling to disclose. bytes data // byte array, reserved for future use }
A transaction signature is not formed from the Amino-encoded transaction bytes themselves. Rather, a canonical representation of the transaction is generated in JSON format for signing.
This would allow for clients to sign a transaction off-chain, for example, with a hardware HSM device like a Ledger, or within a micro-service in an algorithmic trading system. An external system will not have to understand Amino encoding to be able to approve of the transaction's content and produce the signed JSON string.
The canonical bytes for signing are generated from the StdSignBytes method. It produces a JSON string similar to the format below (formatted for clarity):
This JSON string, with all whitespace removed and keys sorted in alphabetical order, is signed with the private key of the sender. This signature is then attached to the StdTx structure described in the above section. Please note that the transaction broadcasted to the blockchain is not JSON - the JSON is merely used as a canonical representation to generate the signature.
The next section describes how the generated signature is attached to a transaction.
The sender's signature is stored in the Standard Transaction data via a Standard Signature, as shown below. This structure is included in the StdTx (see above).
Please note that StdSignature itself doesn't have type prefix, while the PubKey does.
message StdSignature { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding // please note there is no type prefix for StdSignature message PubKey { 0xEB5AE987// hardcoded, object type prefix in 4 bytes uint64 SIZE-OF-ENCODED // varint encoded length of the bytes below bytes // no name or field id, just encode the bytes } PubKey pub_key // public key bytes of the signer address bytes signature // signature bytes, please check the chain access section for signature generation int64 account_number // another identifier of signer, which can be read from chain by account REST API or RPC int64 sequence // sequence number for the next transaction of the client, which can be read from the chain by account REST API or RPC. Please check the chain access section for details. }
Messages represent the individual operations possible on BNB Beacon Chain , and these can be inserted into the StdTx.msgs field. Message types are otherwise known as "transaction types", and these terms are used interchangebly in this document and in our technical documentation. So far every StdTx transaction "container" can only contain one "message".
NewOrder transaction will create a new order to buy or sell tokens on Binance DEX.
// please note the field name is the JSON name. message NewOrder { 0xCE6DC043// hardcoded, object type prefix in 4 bytes bytes sender // order originating address string id // order id, please check the Order ID section below for details. string symbol // symbol for trading pair in full name of the token int64 ordertype // only accept 2 for now, meaning limit order int64 side // 1 for buy and 2 fory sell int64 price // price of the order, which is the real price multiplied by 1e8 (10^8) and rounded to integer int64 quantity // quantity of the order, which is the real quantity multiplied by 1e8 (10^8) and rounded to integer int64 timeinforce // 1 for Good Till Expire(GTE) order and 3 for Immediate Or Cancel (IOC) }
Cancel transactions (cancel the outstanding/unfilled) orders from the Binance DEX. After cancel success, the locked quantity on the orders will return back to the originating address balance and become free to use, i.e. transfer or send new orders.
// please note the field name is the JSON name. message CancelOrder { 0x166E681B// hardcoded, object type prefix in 4 bytes bytes sender // order originating address string symbol // symbol for trading pair in full name of the token string refid // order id of the order to cancel }
Freeze transaction will move the amount of the tokens into a frozen state, in which they cannot be used for transfers or sending new orders.
// please note the field name is the JSON name. message TokenFreeze { 0xE774B32D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to freeze }
Unfreeze will reversely turn the amount of frozen tokens back to free state.
// please note the field name is the JSON name. message TokenUnfreeze { 0x6515FF0D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to unfreeze }
// please note the field name is the JSON name. message Vote { 0xA1CADD36// hardcoded, object type prefix in 4 bytes int64 proposal_id // ID of the proposal bytes voter // address of the voter uint64 option // option from OptionSet chosen by the voter }
Below are options for option:
OptionYes =0x01// yes OptionAbstain =0x02// abstain OptionNo =0x03// no OptionNoWithVeto =0x04// no with veto
message IssueTokenValue { 0x17EFAB80// hardcoded, object type prefix in 4 bytes bytes from // issuer's address string name // token name string symbol // token symbol string total_supply // total supply bool mintable // is mintable }
Mint is used to increase the total supply of a token.
message Mint { 0x467E0829// hardcoded, object type prefix in 4 bytes bytes from // sender's address string symbol string// token symbol int64 amount // increase amount }
message DexList{ 0xB41DE13F// hardcoded, object type prefix in 4 bytes bytes from // sender's address int64 proposal_id // id of corresponding proposal string base_asset_symbol // token symbol of base asset string quote_asset_symbol // token symbol of quote asset int64 init_price // init price of the new token }
Submit proposal is used to create a proposal for validators about adding trading pairs
message Submit{ 0xB42D614E// hardcoded, object type prefix in 4 bytes string title // Title of the proposal string description // Description of the proposal byte proposal_type // Type of proposal. Initial set {PlainTextProposal, SoftwareUpgradeProposal,ListTradingPair, FixedFeeParams} bytes proposer // Address of the proposer message Coin { string denom int64 amount } int64 VotingPeriod // Length of the voting period (s) }
Deposit is used to increase the total deposit of a proposal.
message Deposit{ 0xA18A56E5// hardcoded, object type prefix in 4 bytes int64 ProposalID // ID of the proposal bytes Depositer // Address of the depositer message Coin { string denom int64 amount } }
You can relock tokens on your own account after a certain period of time.
message Timerelock{ 0x504711DA// hardcoded, object type prefix in 4 bytes bytes from // sender's address int64 Id // lock time id string description // Description of the lock message Coin { string denom int64 amount } repeated Coin amount int64 lock_time // lock time }
Claim Hash Timer Locked Transfer is to claim the locked asset by showing the random number value that matches the hash. Each HTLT locked asset is guaranteed to be release once.
message ClaimHTLTMsg{ 0xC1665300// hardcoded, object type prefix in 4 bytes bytes from // sender's address bytes swap_id bytes random_number }
-
+
diff --git a/docs/beaconchain/exchange-integration.html b/docs/beaconchain/exchange-integration.html
index ee93fecf0e..073b73b4d9 100644
--- a/docs/beaconchain/exchange-integration.html
+++ b/docs/beaconchain/exchange-integration.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
List of all endpoints Node RPC service provides can be found: here
If you intend to add "deposit" and "withdrawal" functionalities to your implementation, it is important that you ensure that transactions are final before the backend system credits or deducts funds from a user account.
In brief, transactions pass through several phases before they are finalised and included in a block.
The status "code" recorded for each of these phases can differ, so be sure to check that it is 0 (meaning success) for each of them. A non-zero "code" indicates that there was a problem with the transaction during processing.
For example, this transaction was invalid because the order was already canceled. You can query that the code for this transaction is 405.
The two phases we should be concerned about are CheckTx and DeliverTx.
We recommend that you broadcast your transactions via REST API or, if you wish to run a Full Node, Node RPC via the BroadcastTxSync command.
While there is an RPC command called BroadcastTxCommit which will wait for both CheckTx and DeliverTx and return with codes for both and a block height, it is unfortunately not recommended for use in production.
Instead, there are two ways that you can go about checking the status of your transaction after you have broadcasted it.
If you haven't received anything after a couple of blocks, resend the transaction. If the same happens again, send it to some other node. This is safe to do so long as you are broadcasting the same transaction. Transactions are unique in the blockchain and you cannot spend the coins twice by retrying the send of the same data.
If you want to be sure that the transaction is included in a block, you can subscribe for the result using JSONRPC via a websocket. See Subscribing to Events via WebSocket.
If the Transaction does not yet exist in the blockchain, this attempt will return with an error.
You should check for an absent "code" field in the tx_result: this indicates a code of 0. You could also perform further checks on the log to make sure that it matches the expected value.
-
+
diff --git a/docs/beaconchain/faq.html b/docs/beaconchain/faq.html
index 906e1a9dbd..0cc3d1fd52 100644
--- a/docs/beaconchain/faq.html
+++ b/docs/beaconchain/faq.html
@@ -9,7 +9,7 @@
-
+
@@ -36,7 +36,7 @@
having to support unnecessary features.
If you have certain must-have feature-s, it might be added as a native implementation instead of using smart contract.
Feel free to talk to BNB Chain community.
How can I transfer tokens, such as Bitcoin, from other blockchains onto BNB Beacon Chain?
Right now, there are 2 ways to transfer tokens cross-chain:
via interoperability among different chains. After the latest “Archimedes” upgrade, BEP3 was introduced and it defines native transactions to support Hash Timelock Contract (HTLC) on BNB Beacon Chain and it also to defines the infrastructure standard and procedure to use HTLC for inter-chain atomic swap to easily swap tokens on different chains. BNB Beacon Chain development community has finished implementing its solution for BEP3 with BEP2 and ERC20 tokens and decided to open-source all of the key components, including：
smart-contract solution that supports Atomic Peg Swap (APS) for Ethereum. Please note that this solution is already audited by 3rd party.
deputy process written in GoLang that handles swap activities
Any developer is welcome to test the solutions in testnet and then use them in mainnet.
via Binance.com. Binance,the largest cryptocurrency exchange, has issued a number of crypto-pegged tokens on BNB Beacon Chain (BEP2 token format): BEP2 Bitcoin, BEP2 BCH,BEP2 XRP, BEP2 LTC. Pegged tokens such as BEP2 Bitcoin, are 100% backed by the native coin in reserve. The reserve addresses are published for anyone to audit. Read this blog to learn about the reserved address. Users are free to convert between native and BEP2 Bitcoin via deposit/withdrawal. This has a higher degree of ease-of-use for most traders. More swap channels will be provided on partner wallets soon.
Atomic swap and this centralized approach are not exclusive to other decentralized approaches, which can also be implemented in parallel. There are many cross-chain solutions being developed and we are very interested in them.
Please do NOT try to transfer anything on existing network to BNB Beacon Chain testnet, you may experience loss by doing so, because testnet doesn't run with real coins.
How would a third-party integrate with BNB Beacon Chain and Binance DEX?
A wallet provider may choose to support the feature set of BNB Beacon Chain, which would cover wallets, addresses, balances, transfers and etc.
How to prevent the occurrence of unconfirmed transactions on BNB Beacon Chain?
-
+
diff --git a/docs/beaconchain/fullnode.html b/docs/beaconchain/fullnode.html
index c7b3e72903..61f950ef32 100644
--- a/docs/beaconchain/fullnode.html
+++ b/docs/beaconchain/fullnode.html
@@ -9,7 +9,7 @@
-
+
@@ -30,7 +30,7 @@
Now its Mar 1st, latest sync-able block height is 50000, you don't care blocks between 22000 and 50000, you can delete $BNCHOME/data/STATESYNC.LOCK before start your node.
Then the full node would continue state sync from height 50000.
Turning off state_sync_reactor and state_sync can save your memory after you successfully state synced.
In most cases, download the new binary and replace it, then restart the full node.
In special cases, you may have to do extra steps for an incompatible version (hard fork).
Full node has the same RPC interface as the one listed here rpc-api
If you want to get extra information about order book, balance changes or block fee changes from blocks, please refer to getting extra data from fullnode.
This error is caused by the handshake failing between two peers.
Solution
To solve this problem, you need to make sure node_key.json is under $BNCHOME/config and nodes will try to re-connect automatically, so this issue should not persist.
The BNB Chain has a hardfork upgrade and if you failed to upgrade your fullnode to the latest version, bnbchaind process will stop and even if you restart with the latest version, the following error will appear:
panic: Tendermint state.AppHash does not match AppHash after replay. Got , expected 393887B67F69B19CAB5C48FB87B4966018ABA893FB3FFD241C0A94D2C8668DD2 goroutine 1 [running]: github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.checkAppHash(0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, 0x20, ...) /Users/huangsuyu/go/src/github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus/replay.go:464 +0x213 github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.(*Handshaker).ReplayBlocks(0xc000b37980, 0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, ...)
To recover from the state conflict error, you need to:
Backup your home directory, (default is ~/.bnbchaind)
Get the height of upgrade, this height will be announced in the upgrade announcement on the forum. For example, if it's announced as 5000 in the forum and run the following command will make your full node recover to the last block before the upgrade, and that is 4999 :
If you do not download the binaries completely, you will see the following message:
./bnbchaind: line 1: version: command not found ./bnbchaind: line 2: oid: command not found /Library/Developer/CommandLineTools/usr/bin/size: 45160816 No such file or directory
Since the old binaries are stored in git lfs previously, you will see this error if the binary is not complete. Please use this repo to download the binaries.
Once you have your own node running, you can start querying from it. But sometimes you may not be ablt to get the information you want. For example:
curl 'localhost:27147/block?height=10'
The reason is because your node is using statesync to catch up. In this way, it will not store all the history blocks before the snapshot height it got. You can only query blocks after that snapshot height.
To enable query history blocks, you need to use fast-sync
-
+
diff --git a/docs/beaconchain/get-extra-data-from-fullnode.html b/docs/beaconchain/get-extra-data-from-fullnode.html
index cdf7494574..114b9cf3e6 100644
--- a/docs/beaconchain/get-extra-data-from-fullnode.html
+++ b/docs/beaconchain/get-extra-data-from-fullnode.html
@@ -9,7 +9,7 @@
-
+
@@ -30,7 +30,7 @@
Then, the full node will save messages that you are interested into Kafka, and you can consume them in your own apps.
The message is encoded based on Avro serialization system.
Their schemas are shown below:
SDKs are also provided as a starting point for your apps.
There are two advanced SDK solutions for BNB Beacon Chain : Java and Golang.
Both solutions provide functions for:
Create wallets and manage keys
Encode/sign transactions and submit to BNB Beacon Chain /DEX, including Transfer, New Order, Cancel Order, etc.
Communicate with BNB Beacon Chain /DEX Node RPC calls through public node RPC services or your own private full nodes
Please refer to specific SDK documentation for more information:
-
+
diff --git a/docs/beaconchain/governance.html b/docs/beaconchain/governance.html
index 84b59128d7..7c14c1c462 100644
--- a/docs/beaconchain/governance.html
+++ b/docs/beaconchain/governance.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
If the initial proposer's deposit is not sufficient, the proposal enters the deposit period. Then, any BNB holder can increase the deposit by sending a deposit transaction.
The deposits are hold by governance escrow account during voting period, and will be refunded or burned later.
After deposit period, votes will be casted to decide whether to accept or reject the proposal.
min-deposit: The threshold for submitting a proposal is 2000BNB.
deposit_period: This is a global parameter and the value for mainnet is two days and testnet is two week. It means the time to deposit enough BNB tokens is two days in mainnet and two weeks in testnet.
fee: Checkout the fee of governance-related transactions here
imToken is a decentralized digital wallet used to manage and safeguard a wide range of blockchain- and token-based assets, identities, and data.imToken allows its users to manage assets on 12 mainstream blockchains, as well as seamlessly connect with DApps via a decentralized applications browser.
$ ./bnbcli keys Keys allows you to manage your local keystore for tendermint. These keys may be in any format supported by go-crypto and can be used by light-clients, full nodes, or any other application that needs to sign with a private key. Usage: bnbcli keys [command] Available Commands: mnemonic Compute the bip39 mnemonic for some input entropy add Create a new key, or import from seed list List all keys show Show key info for the given name delete Delete the given key update Change the password used to protect private key Flags: -h, --help helpfor keys Global Flags: -e, --encoding string Binary encoding (hex|b64|btc)(default "hex") --home string directory for config and data (default "/Users/yourname/.bnbcli") -o, --output string Output format(text|json)(default "text") --trace print out full stack trace on errors Use "bnbcli keys [command] --help"formore information about a command.
$ ./bnbcli keys add testkey Enter a passphrase for your key: Repeat the passphrase: NAME: TYPE: ADDRESS: PUBKEY: testkey local bnc1e8zhj9wmgq4pwzrv264gfru2fk8x2hdvpclx3n bncp1addwnpepqffepxlkrka9n33vyzmjwkpy05gpm46cn5de3x9v0vqswk7st5lkc7alhjv **Important** write this seed phrase in a safe place. It is the only way to recover your account if you ever forget your password. poverty joke nominee enough harsh elder flush noodle gift one limit tree sponsor sun radio above acid air winter inflict profit there brand water
$ ./bnbcli keys add testkey --recover Enter a passphrase for your key: Repeat the passphrase: > Enter your recovery seed phrase: poverty joke nominee enough harsh elder flush noodle gift one limit tree sponsor sun radio above acid air winter inflict profit there brand water NAME: TYPE: ADDRESS: PUBKEY: testkey local bnc1e8zhj9wmgq4pwzrv264gfru2fk8x2hdvpclx3n bncp1addwnpepqffepxlkrka9n33vyzmjwkpy05gpm46cn5de3x9v0vqswk7st5lkc7alhjv
As explained in BEP8,the idea of BEP8 Tokens is raised to accommodate the small or micro projects, intellectual properties, and other small token economies to build a more comprehensive venue for token trading.
Based on the limitation usage of the network, the cost of issuing of such BEP8 tokens are minimized to a different magnitude.
Similar to SME board in the traditional stock markets, BEP8 tokens markets will increase the liquidity of utility tokens of startups or Intellectual Property (IP) tokens by removing the capital requirements for listing. One good example is the open-source license model. A software developer can issue a BEP8 token and link his work to it. This token will be used to cover licensing fees for his work in the future.
Issue is a transaction used to create a new asset. Anyone can issue a new token with fee paid. After issuing, the token would appear in the issuer's account as free balance.
An issuance transaction contains:
Symbol: The length of the string for representing this asset is between 3 and 8 alphanumeric characters and is case insensitive. The symbol will have a suffix autogenerated by the algorithm: the first 3 bytes of the issue transaction hash, plus letter “M”.
TokenURI: Optional field. A distinct Uniform Resource Identifier (URI) for the token. The URI may point to a JSON file that conforms to the "Mini-BEP2 Metadata JSON Schema". The schema is also optional.
TokenType: 1 for tiny token and 2 for Mini token. Total supply range of tiny token is [1-10K] and mini-token is [1, 1 million]. Mini-token will charge more than tiny-token for issue.
TotalSupply: The total supply for this token can have a maximum of 8 digits of decimal and is boosted by 1e8 in order to store as int64. The amount before boosting should not exceed upper bound of supply range.
Owner: The initial issuer of this token, the BNB balance of issuer should be more than the fee for issuing tokens
Mintable: Whether this token could be minted(increased) after the initial issuing, --mintable means the token can be inflationary.
BEP8 Transfer type is the same as BEP2. The difference from BEP2 transfer is that the Mini-BEP2 transfer amount should be larger than or equal to 1, unless the sender sends the total amount of the free Mini-BEP2 token in his account.
The transaction type, message structure and transaction process are the same as BEP2, except that the amount should be larger than or equal to 1, or equal to the free account balance.
The transaction type, message structure and transaction process are the same as BEP2 Tokens, except that the amount should be larger than or equal to 1, or equal to the frozen account balance.
The transaction type, message structure and transaction process are the same as BEP2 Tokens, except that the amount should be larger than or equal to 1.
The transaction type, message structure and transaction process are the same as BEP2 Tokens. The difference from BEP2 burn is that the Mini-BEP2 burn amount should be larger than or equal to 1, or equal to the free account balance.
The SetURI transaction is to change the value of TokenURI. Only token issuer can send this transaction. The URI may point to a JSON file that conforms to the "Mini-BEP2 Metadata JSON Schema".
{ "name":"Mini Token Metadata", "description":"Metadata description for the Mini Token", "external_url":"https://example.com/token", "image":"https://example.com/token/1.png", "attributes":[ { "name":"custom field", "value":"custom value" }, ... ] }
Before implementing BEP82, many token-related transactions, such as token listing, minting, burning, can only be proposed by the token owner. The owner of any BEP2/BEP8 token can not be changed once the token is issued on BNB Beacon Chain .
BEP82 introduced the changes related to the token owner who issued a token on BNB Beacon Chain . It provides more convenience and flexibility for these transactions.
TransferOwnership transaction can transfer ownership of a specific token to another address, and only the original owner has the permission to send this transaction.
Whenever a new address receives an asset, the corresponding transaction would create an Account for that address, which contains balances across all assets that are owned on this address.
The balance (the amount of tokens) of each asset is composed of 3 different parts:
Available: the amount of tokens that can be transferred, and spent to swap (buy) other assets
Locked: the amount of tokens that has been used in any outstanding orders. Once the order terminates (either filled, canceled or expired), the locked amount will decrease.
Frozen: the amount of tokens that has been frozen via Freeze transactions.
You can query the account info with the following command on mainnet:
After Account is created, besides the balances, Account also contains:
Account Number: an internal identifier for the account
Sequence Number: an ever-changing integer.
The Sequence Number is the way how BNB Beacon Chain prevents Replay Attack (the idea is borrowed from Cosmos network, but varies a bit in handling). Every transaction should have a new Sequence Number increased by 1 from the current latest sequence number of the Account, and after this transaction is recorded on the blockchain, the Sequence Number will be set to the same number as the one of latest transaction.
This logic forces the client to be aware of the current Sequence Number, either by reading from the blockchain via API, or keep the counting locally by themselves. The recommended way is to keep counting locally and re-synchronize from the blockchain periodically.
For normal users, all the keys and addresses can be generated via Binance Web Wallet.
This default wallet would use a similar way to generate keys as Bitcoin, i.e. use 256 bits entropy to generate a 24-word mnemonic based on BIP39, and then use the mnemonic and an empty passphrase to generate a seed; finally use the seed to generate a master key, and derive the private key using BIP32/BIP44 with HD prefix as "44'/714'/", which is reserved at SLIP 44.
BNB Beacon Chain uses the same elliptic curve cryptography as the current Bitcoin implementation, i.e. secp256k1. Its private key is 32 bytes while public key is 33 bytes.
Addresses on BNB Beacon Chain are 20 bytes and may be expressed as:
Address = RIPEMD160(SHA256(compressed public key))
Typically, an address is encoded in the bech32 format which includes a checksum and human-readable prefix (HRP). However, it doesn't use the SegWit address format (because we do not have SegWit function anyway, so no witness program version etc.).
A BNB Beacon Chain address is therefore more similar to a Bitcoin Cash address, which does not include a SegWit program script.
Address format pseudo-code:
Address_Bech32 = HRP + '1' + bech32.encode(convert8BitsTo5Bits(RIPEMD160(SHA256(compressed public key))))
For BNB Beacon Chain address, the prefix is bnb for production network, and tbnb for testnet.
BNB Beacon Chain uses an ECDSA signature on curve secp256k1 against a SHA256 hash of the byte array of a JSON-encoded canonical representation of the transaction. For more information, please see this page.
-
+
diff --git a/docs/beaconchain/learn/architecture.html b/docs/beaconchain/learn/architecture.html
index e9ae8a0868..21ce75f153 100644
--- a/docs/beaconchain/learn/architecture.html
+++ b/docs/beaconchain/learn/architecture.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
A simplified overview of the application's architecture might look something like this:
+------------+---------------------+ | RPC API | Web API | +------------------------+---------+ | Staking | Salshing | Cross Chain | +------------------------+---------+ | Asset Management | Match Engine | +----------------------------------+ | Account Management | Governance |---------> crypto and blockchain governance +----------------------------------+ | State Caching and Persisence +-+ +----------------------------------+ | | Consensus Protocol | | +----------------------------------+ |-----> revised Tendermint | P2P Protocol | | +----------------------------------+ | | Networking | Database +-+ +----------------------------------+
For more information about Tendermint, please have a look at the Tendermint Core.
For more information about Cosmos SDK, please have a look at the Cosmos Intro.
BNB Beacon Chain implements a multi-modular blockchain architecture which is easy to extend and use, and also provides the basic functionalities for side chains and other chains to build upon it.
Here are the main moudles:
Asset - A fruitful set of features are implemented for asset management, for example, users can issue, mint/burn, freeze/unfreeze, lock/unlock BEP2 and BEP8 tokens.
Governance - BNB Beacon Chain supports on-chain governance of BNB Beacon Chain and side chains. Holders of the native token (i.e., BNB) can submit proposals and vote on proposals to apply different kinds of changes on chains.
Staking - With this moudle, BNB holders can become validators and can delegate tokens to validators, ultimately determining the effective validator sets for BNB Beacon Chain and side chains (e.g., BSC).
Distribution - BNB Beacon Chain will actively distribute rewards between validators and delegators, for both BNB Beacon Chain itself and its side chains.
Cross Chain - BNB Beacon Chain supports the cross chain transfers of native tokens. Cross chain communication is also built in, to support different kinds of usage scenarios.
Slashing - Slashing module will disincentivize any bad actor by penalizing them.
Params - A globally available parameter store is provided by BNB Beacon Chain. These parameters affects the excution of BNB Beacon Chain itself and its side chains, and can be changed by goverenance.
APIs - RPC, HTTP, and Websocket APIs are provided for interacting with blockchains and the related services. Developers can use these APIs to build their Web3 applications, wallets, data services and so on.
Assets are stored as tokens on BNB Beacon Chain , and the below management actions are available. All the assets are complied with BEP2 standard. BEP stands for BNB Chain Evolution Proposal. Each BEP will be a proposal document providing information to the BNB Beacon Chain /DEX community. The BEP should provide a concise technical specification of the feature or improvement and the rationale behind it. Each BEP proposer is responsible for building consensus within the community and documenting dissenting opinions. Each BEP has a unique index number.
Explanations: Suffix is the first 3 bytes of the issue transaction’s hash, for example: BUSD-BD1. It helps to remove the constraint of requiring unique token names. If this token pegs to an existing blockchain, there should be an additional suffix of “B”.
Issuer signed an issue transaction and broadcast it to one of BNB Beacon Chain nodes
This BNB Beacon Chain node will check this transaction. If there is no error, then this transaction will be broadcasted to other BNB Beacon Chain nodes
Issue transaction is committed on the blockchain by block proposer
Validators will verify the constraints on total supply and symbol and deduct the fee from issuer’s account
New token’s symbol is generated based on the transaction hash. It is added to the issuer’s address and token info is saved on the BNB Beacon Chain
The Build N Build Coin, BNB, is the native asset on BNB Beacon Chain . There are 200MM BNB coins in total. There will be no mining. The existing coin burns and freezes will still be in effect on the new BNB Beacon Chain blockchain.
The exact number of BNB coins will be destroyed based on the same number of BNB ERC20 tokens that have already been destroyed.
Since BNB Beacon Chain is live, all BNB ERC20 tokens will be swapped for BNB Beacon Chain coins. All users who hold BNB ERC20 tokens can deposit them to Binance.com, and upon withdrawal, the new BNB Beacon Chain native coins will be sent to their new wallets.
-
+
diff --git a/docs/beaconchain/learn/atomic-swaps.html b/docs/beaconchain/learn/atomic-swaps.html
index a6ece74a0c..75ff6ebb87 100644
--- a/docs/beaconchain/learn/atomic-swaps.html
+++ b/docs/beaconchain/learn/atomic-swaps.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
During the swap process, the related fund will be locked to a purely-code-controlled escrow account.
A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account has no its own private key and it's only controled by code in protocol. The code for calculating escrow account is the same as how it's done in cosmos-sdk:
The account for mainnet is: bnb1wxeplyw7x8aahy93w96yhwm7xcq3ke4f8ge93u and the account for testnet is: tbnb1wxeplyw7x8aahy93w96yhwm7xcq3ke4ffasp3d. Once the swap is claimed or refunded, the fund will be transferred from the purely-code-controlled escrow account to client accounts.
Receiver address, where the asset is to, if the proper condition meets.
No
recipient-other-chain
bytes
a byte array, maximum 32 bytes, in any proper encoding. leave it empty for single chain swap
Yes
sender-other-chain
bytes
a byte array, maximum 32 bytes, in any proper encoding. leave it empty for single chain swap
Yes
RandomNumberHash
32 bytes
hash of a random number and timestamp, based on SHA256. If left out, a random value will be generated
True
Timestamp
int64
Supposed to be the time of sending transaction, counted by second. It should be identical to the one in swap contract. If left out, current timestamp will be used.
No
OutAmount
Coins
similar to the Coins in the original Transfer defined in BEP2, assets to swap out
No
ExpectedIncome
string
Expected income from swap counter party, example: "100:BNB" or "100:BNB,10000:BTCB-1DE" The amount needs to be bumped by e^8
No
HeightSpan
int64
number of blocks to wait before the asset may be returned to From if not claimed via Random. The number must be larger than or equal to 360 (>2 minutes), and smaller than 518400 (< 48 hours)
No
CrossChain
bool
Specify if the HTLT is for cross chain atomic swap
After the deposit, you may observe that the balance of sender is decreased. The amount in deposit transaction must be positive. Besides, you can query the swap by swapID and the in_amount must equal to the amount that you balance decreased.
Claim Hash Timer Locked Transfer is to claim the locked asset by showing the random number value that matches the hash. Each HTLT locked asset is guaranteed to be release once.
const client =newBncClient("https://testnet-dex.binance.org") const privateKey = crypto.getPrivateKeyFromMnemonic(mnemonic) client.setPrivateKey(privateKey) const swapID ="61daf59e977c5f718f5aaedeaf69ccbea1c376db5274a84bca88848696164ffe"// the ID of an existing swap const randomNumber ="e8eae926261ab77d018202434791a335249b470246a7b02e28c3b2fb6ffad8f3"// the random number generated in htlt const res = client.swap.claimHTLT(from, swapID, randomNumber)
const client =newBncClient("https://testnet-dex.binance.org") const privateKey = crypto.getPrivateKeyFromMnemonic(mnemonic) client.setPrivateKey(privateKey) const swapID ="61daf59e977c5f718f5aaedeaf69ccbea1c376db5274a84bca88848696164ffe"// the ID of an existing swap const res = client.swap.refundHTLT(from, swapID, randomNumber)
Common error:
Already complete
ERROR: {"codespace":8,"code":12,"abci_code":524300,"message":"Expected swap status is Open, actually it is Completed"}
Not expired
ERROR:{"codespace":8,"code":8,"abci_code":524296,"message":"Current block height is 40003412, the expire height (40013236) is still not reached"}
Query atomic swap ID allows you to search swap history of an recipient. As this is a heavy query interface, some public nodes might close this query interface.
Query atomic swap ID allows you to search swap history of an initiator. As this is a heavy query interface, some public nodes might close this query interface.
Its corresponding address on testnet is: tbnb1pk45lc2k7lmf0pnfa59l0uhwrvpk8shsema7gron BNB Beacon Chain and 0xD93395B2771914E1679155F3EA58C41d89D96098 on Ethereum testnet
random_number_hash must equal to the randomNumberHash in client HTLT transaction on ethereum
to must equals to client wallet address
timestamp must equal to the timestamp in client HTLT transaction on ethereum
out_amount should be reasonable. Please note that the decimals of bep2 tokens is 8, the out_amount should be something around 10000000000:PPC, deputy will deduct some fees.
expire_height must not be passed and should be enough for send claim transaction
You should see that Deputy has already approved enough tokens and
In its event log, you should see the swapID. Before calling claim function on ethereum, clients should verify the parameters in the HTLT event.
_randomNumberHash must equal to the randomNumberHash in client HTLT transaction on BNB Beacon Chain
_recipientAddr must equal to client ethereum wallet address
_timestamp must equal to the timestamp in client HTLT transaction on BNB Beacon Chain
_outAmount should be reasonable. Please note that the decimals erc20 contract and deputy will deduct some fees.
_expireHeight must not be passed and should be enough for send claim transaction
Then, you can call the claim function:
Function: claim
Parameters:
_swapID: this is get from event, you can also calculate it from calSwapID function in the contract. calSwapID(randomNumberHash, {deputy ethereum address}, {hex encoding client binance address})
!!! Note
Please note that BC <-> BSC Token Bridge is a module of BNB Beacon Chain fullnode to facilitate cross-chain transfer between BNB Beacon Chain and BNB Smart Chain , while Binance Bridge, a bridge service providing access to inter-blockchain liquidity for BNB Beacon Chain , BNB Smart Chain decentralized applications, and bring valuable assets to BNB Beacon Chain ecosystems.
BC <-> BSC token bridge for self transfers of BEP2 tokens to BEP20 (ERC20 representation). The BC <-> BSC bridge connects two chains (BC and BSC). When a user deposits BEP2 into the BC <-> BSC bridge contract contract on BC they get the same amount of BEP20 tokens on BSC, and they can convert them back as well.
A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account doesn't have its own private key and it's only controlled by code in protocol. The code for calculating escrow account is the same as how it's done in cosmos-sdk:
The account for mainnet is: bnb1v8vkkymvhe2sf7gd2092ujc6hweta38xadu2pj and the account for testnet is: tbnb1v8vkkymvhe2sf7gd2092ujc6hweta38xnc4wpr. Once the swap is claimed or refunded, the fund will be transferred from the purely-code-controlled escrow account to client accounts.
Slashing is part of the on-chain governance, to ensure the malicious or negative behaviors are punished. BSC slash can be submitted by anyone. The transaction submission requires slash evidence and cost fees but also brings a larger reward when it is successful.
Two block headers have same height and same parent block hash
Two block headers are sealed by the same validator
Two signatures of these two blocks must not be the same
The time of these two blocks must be within the validity of the evidence, which is 24 hours
If the evidence is valid:
1000BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 1000BNB, then the unbonding delegation balance would be slashed if it exists until totally 1000BNB slashed from self-delegator of the validator. However, if all the slashed BNB is less than 1000, all the remaining stake of the self-delegator will be slashed
100 of slashed BNB would allocate to the submitter as a reward
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with duration of 7 days, and remove it from validator set by an instance BSC validator set update Cross-Chain update
There can be an internal smart contract responsible for recording the missed blocking metrics of each validator.
If a validator missed more than 50 blocks in 24h, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. If it missed more than 150 blocks in 24h, then this will be propagated back to BC where another Slashing will happen:
50BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 50BNB, then the unbonding delegation balance would be slashed if it exists until totally 50BNB slashed from self-delegator of the validator. However, if all the slashed BNB is less than 1000, all the remaining stake of the self-delegator will be slashed
10 of slashed BNB would allocate to the validators on BC as block fee
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with duration of 2 days, and remove it from validator set by an instance BSC validator set update Cross-Chain update
The malicious validators who are slashed by the previous cases will be set to jailed along with a duration setting as well due to the malicious or negative behaviors. We can set it to ‘unjailed’ by sending a side-unjail transaction if the validation passed.
When your validator is unjailed on BNB Beacon Chain, it must wait for the next UTC 0:00 to join validatorsest again.
Slashing validators of BSC for the malicious behavior of double-sign by submitting evidence consisting of two block headers with same height but signed by one signer
BNB Smart Chain is an innovative solution to bring programmability and interoperability to BNB Beacon Chain. BNB Smart Chain relies on a system of 55 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality.
Ideally, BNB Smart Chain should build such staking and reward logic into the blockchain, and automatically distribute rewards as the blocking happens. Cosmos Hub, who also build on top of Tendermint consensus like BNB Beacon Chain , works in this way.
However, as BSC wants to remain compatible with Ethereum as much as possible. On the other side, BNB Beacon Chain already has a staking module and could be extended to support both BC and BSC. In this way, all the staking related operations are recorded in BC. Once there are any changes about BSC's validator set or voting power, the new message will be transferred to BSC through cross-chain communication.
The staking token is BNB, as it is a native token on both blockchains anyway
The staking, i.e. token bond and delegation actions and records for BSC, happens on BC.
The BSC validator set is determined by its staking and delegation logic, via a staking module built on BC for BSC, and propagated every day UTC 00:00 from BC to BSC via Cross-Chain communication.
The reward distribution happens on BC around every day UTC 00:00 after.
Validators are ranked by their power and operator address. The more its delegation tokens, the higher ranking is. If two validators get the same amount of delegated tokens, validator with smaller address bytes has higher ranking.
ValidatorSet is updated in BreatheBlock, the frequency is once a day. let’s assume it happens on day N.
The info of validator set changes of day N would be transmitted to BSCthrough interchain communication.
The validator set contract on BSC would receive and update the new validatorset. After that, it would trigger several interchain transfer to transfer the fees that every previous validators collected in this period to their addresses on BC. we can see that fees belongs to the validators of day N-1.
To make some room for the error handling, we distribute the fees of day N-1 in the next breathe block (day N+1).
even if validator set or any their voting powers are not changed on that day, we still transmit the validator set info to BSC.
the validator set contract maintains the history of the fees that every validators collected after the previous period(We define the period as the time between two contract calls of validator set changes). The actual fees are collected on the contract address.
the interchain transfer to send fees from the contract address to each validator’s distribution address on BC. Note the distribution address is auto generated on BC when handling the create-validator tx, so no private key is corresponded to that address and no one except the distribution module can move the tokens on that address. This address is displayed as Distribution Addr in validator info.
Validator Fee Address: tbnb15mgzha93ny878kuvjl0pnqmjygwccdadpw5dxf Operator Address: bva15mgzha93ny878kuvjl0pnqmjygwccdad08uecu Validator Consensus Pubkey: Jailed: false Status: Bonded Tokens: 5000000000000 Delegator Shares: 5000000000000 Description: {Elbrus "" www.binance.org This is Elbrus org on chapel network.} Bond Height: 74158 Unbonding Height: 0 Minimum Unbonding Time: 1970-01-01 00:00:00 +0000 UTC Commission: {rate: 75000000, maxRate: 90000000, maxChangeRate: 3000000, updateTime: 2020-05-22 12:24:19.478568234 +0000 UTC} Distribution Addr: tbnb1srkkfjk8qctvvy4s3cllhpnkz9679jphr30t2c Side Chain Id: chapel Consensus Addr on Side Chain: 0xF474Cf03ccEfF28aBc65C9cbaE594F725c80e12d Fee Addr on Side Chain: 0xe61a183325A18a173319dD8E19c8d069459E2175
we have a lower limit of the value of interchain transfer, at least the value can cover the transfer fee. Also, interchain transfer will only allow max 8 decimals for the amount. The tiny left part would be kept in the contract or put into the system reward pool.
the reward: (totalfees * (1-commissionRate)) would be distributed in proportion to the delegations, the left part would be sent to the validator fee address.
if the cross-chain transfer failed, the tokens would be sent back to a specified address(i.e. the SideFeeAddr in the store section, validators can change this address via the EditValidator tx). After that, validators can manually deposit the tokens to its own DistributionAddr on BC via Transfer tx. We do not force the validator to do so, but it’s an indicator that can help delegators choose validators.
The initial commission rate percentage, it has 8 decimal places.
Yes
--commission-max-rate
95000000 (0.95 or 95%)
The maximum commission rate percentage, it has 8 decimal places. You can not update this rate.
Yes
--commission-max-change-rate
3000000 (0.03 or 3%)
The maximum commission change rate percentage (per day). You can not update this rate.
Yes
--side-chain-id
chapel
chain-id of the side chain the validator belongs to
Yes
--side-cons-addr
0x1234abcd
consensus address of the validator on side chain, please use hex format prefixed with 0x
Yes
--side-vote-addr
0x1234abcd
vote pub key of the validator on side chain, please use hex format prefixed with 0x
Yes
--bls-wallet
/path/to/bls/wallet
absolute path of BLS wallet
Yes
--side-fee-addr
0xabcd1234
address that validator collects fee rewards on side chain, please use hex format prefixed with 0x.
Yes
--home
/path/to/cli_home
home directory of bnbcli data and config, default to “~/.bnbcli”
No
Some address parameters we need to highlight here:
Field Name
Usage
DelegatorAddr
Self delegator address. For BC, this address also used to collect fees.
ValidatorAddr
validator operator’s address, used in governance ops like voting.
SideConsAddr
block producer’s address on side chain, i.e. consensus address. BC has another parameter named PubKey, here SideConsAddr replaced that for BSC. Only BSC validators need this parameter.
SideVoteAddr
A bls public key. It's used by validators to vote for blocks, so the BSC chain can finalize blocks within two block periods in normal.
SideFeeAddr
fees are collected in this address on BSC, Only BSC validators need this parameter. Due to different token units, there are some BNB left as dust when sending block rewards from BNB Smart Chain to BNB Beacon Chain . Those BNB will be sent to fee address.
If you want a separated self-delegator address, both self-delegator and validator operator need to sign this transaction. Here we need to use another two commands to support multiple signatures.
a. use the following commands appended with a parameter “--generate-only” and save the result to a json file which would be used to be signed.
-
+
diff --git a/docs/beaconchain/learn/breathe-block.html b/docs/beaconchain/learn/breathe-block.html
index 6a33f46168..902c4be9d4 100644
--- a/docs/beaconchain/learn/breathe-block.html
+++ b/docs/beaconchain/learn/breathe-block.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
A breathe block is the first block of a day in UTC time, for example, block 288644676 is
a breathe block because it is the first block of 06/01/2023.
In breathe block, some special logics will be executed, for example, validator set update, staking reward allocations, parameter changes, and so on.
There are several approaches to find breathe blocks:
Messages (e.g., kafka messages) can be published to receive breathe blocks, for more information please refer to breathe block.
You can also find breathe blocks by accessing local logs if you are running a BNB Beacon Chain node. In node.log log file, the heights of breathe blocks will be logged.
Another option is using Explorer by looking at the block time. Please do check the surrounding blocks if you find a potential one (multiple blocks can be mined in the same second).
Breathe blocks can execute any logics as normal blocks. Besides, there are some logics only happened in breathe blocks,
to unify some handlings or avoid any burden on normal blocks (e.g., for performance).
Validator set update - In breathe blocks, validator set updates will take effect, i.e., updating validators on BNB Beacon Chain or triggering cross chain communication for side chain's validator set update.
Staking reward calculation and allocation - the staking rewards will be calculated and allocated in breathe blocks.
Proposal execution and parameter change - some proposals will be only executed in breathe blocks, for example, fee change proposals, cross chain parameter changes.
There are many system parameters to control the behavior of the BSC:
All these parameters of BSC system contracts should be flexible: slashing threshold, cross-chain transfer fees, relayer reward amount and so on.
params of Staking/Slash/Oracle/IBC modules on BC
All these parameters will be determined by BSC Validator Set together through a proposal-vote process based on their staking. Such process will be carried on BC, and the new parameter values will be picked up by corresponding system contracts via cross-chain communication when needed.
-
+
diff --git a/docs/beaconchain/learn/encoding.html b/docs/beaconchain/learn/encoding.html
index a745482dab..1bfbaef5be 100644
--- a/docs/beaconchain/learn/encoding.html
+++ b/docs/beaconchain/learn/encoding.html
@@ -9,7 +9,7 @@
-
+
@@ -35,7 +35,7 @@
Marshaler interface contract for these types (e.g. MarshalAccount). Note, they
should still use a HybridCodec internally. These extended contracts will typically
use concrete types with unique oneof messages.
Amino supports JSON encoding natively, which is the same as other usual json marshalers. Except that it can add one more type info for registered type, as shown below.
Binary encoding is a variant of Google protocol buffer. The bytes are layed out in the below sequence:
a varint encoded integer - it contains the length of the encoded bytes for the object, which is displayed as SIZE-OF-ENCODED in the below structs. Please note that it contains the length of encoded bytes and also the type prefix (below), but not itself, e.g. if the encoded msg is 20 bytes, then the length would be 20 + 4 = 24, while 4 is used for the type prefix bytes.
an object type prefix of 4-8 bytes - For different type of objects, there will be different type prefixes, and they are displayed as in the specific objects below (data structures).
a binary encoded object - the encoding is mostly the same as protocol buffer encoding mechanism, except the embedded fields of complex type:
to encode data field of some specific types, an object type prefix for the field will be added ahead of the real encoding.
repeated (array) Encoding - it is the same as google protocol buffer, while encoding of the object/struct may contain the type prefix as shown below.
Let's take a look at an example function of BNB Beacon Chain go-sdk. The signed transaction needs to be amino-encoded, thus ready to be posted to BncChain API.
Below are the data types that can be sent to BNB Beacon Chain as requests, and their encoding layout. To simplify the presentation, we will use a variant of Google protocol buffer proto3 language to illustrate how the data fields are organized. Except the all-capitalized fields, other fields will use the default proto3 encoding logic.
Transactions are each wrapped in the below "Standard Transaction": structure:
// please note the field name is the JSON name. message StdTx { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding, please note this includes both the below type prefix (4 bytes) and the all encoding bytes 0xF0625DEE// hardcoded, object type prefix in 4 bytes repeated Msg msgs // array of size 1, containing the transaction message, which are one of the transaction types below. please check the above "Array Encoding" repeated StdSignature signatures // array of size 1, containing the standard signature structure of the transaction sender string memo // a short sentence of remark for the transaction. Please only `Transfer` transaction allows 'memo' input, and other transactions with non-empty `Memo` will be rejected. int64 source // an identifier for tools triggerring this transaction, set to zero if unwilling to disclose. bytes data // byte array, reserved for future use }
A transaction signature is not formed from the Amino-encoded transaction bytes themselves. Rather, a canonical representation of the transaction is generated in JSON format for signing.
This would allow for clients to sign a transaction off-chain, for example, a hardware HSM device like a Ledger, or within a micro-service in an algorithmic trading system. For example an external system will not have to understand Amino encoding to be able to approve of the transaction's content and produce the signed JSON string.
The canonical bytes for signing are generated from the StdSignBytes method. It produces a JSON string similar to the format below (formatted for clarity):
This JSON string, with all whitespace removed and keys sorted in alphabetical order, is signed with the private key of the sender. This signature is then attached to the StdTx structure described in the above section. Please note that the transaction broadcasted to the blockchain is not JSON - the JSON is merely used as a canonical representation to generate the signature.
The next section describes how the generated signature is attached to a transaction.
The sender's signature is stored in the Standard Transaction data via a Standard Signature, as shown below. This structure is included in the StdTx (see above).
Please note that StdSignature itself doesn't have type prefix, while the PubKey does.
message StdSignature { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding // please note there is no type prefix for StdSignature message PubKey { 0xEB5AE987// hardcoded, object type prefix in 4 bytes uint64 SIZE-OF-ENCODED // varint encoded length of the bytes below bytes // no name or field id, just encode the bytes } PubKey pub_key // public key bytes of the signer address bytes signature // signature bytes, please check chain access section for signature generation int64 account_number // another identifier of signer, which can be read from chain by account REST API or RPC int64 sequence // sequence number for the next transaction of the client, which can be read from the chain by account REST API or RPC. Please check chain acces section for details. }
Messages represent the individual operations possible on BNB Beacon Chain , and these can be inserted into StdTx.msgs field. Message types are otherwise known as "transaction types", and these terms are used interchangeably in this document and in our technical documentation. So far every StdTx transaction "container" can only contain one "message".
Freeze transaction will move the amount of the tokens into a frozen state, in which they cannot be used for transfers or sending new orders.
// please note the field name is the JSON name. message TokenFreeze { 0xE774B32D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to freeze }
Unfreeze will reversely turn the amount of frozen tokens back to free state.
// please note the field name is the JSON name. message TokenUnfreeze { 0x6515FF0D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to unfreeze }
// please note the field name is the JSON name. message Vote { 0xA1CADD36// hardcoded, object type prefix in 4 bytes int64 proposal_id // ID of the proposal bytes voter // address of the voter uint64 option // option from OptionSet chosen by the voter }
Below are options for option:
OptionYes =0x01// yes OptionAbstain =0x02// abstain OptionNo =0x03// no OptionNoWithVeto =0x04// no with veto
message IssueTokenValue { 0x17EFAB80// hardcoded, object type prefix in 4 bytes bytes from // issuer's address string name // token name string symbol // token symbol string total_supply // total supply bool mintable // is mintable }
Mint is used to increase the total supply of a token.
message Mint { 0x467E0829// hardcoded, object type prefix in 4 bytes bytes from // sender's address string symbol string// token symbol int64 amount // increase amount }
Submit proposal is used to create a proposal for validators about adding trading pairs
message Submit{ 0xB42D614E// hardcoded, object type prefix in 4 bytes string title // Title of the proposal string description // Description of the proposal byte proposal_type // Type of proposal. Initial set {PlainTextProposal, SoftwareUpgradeProposal,ListTradingPair, FixedFeeParams} bytes proposer // Address of the proposer message Coin { string denom int64 amount } int64 VotingPeriod // Length of the voting period (s) }
Deposit is used to increase the total deposit of a proposal.
message Deposit{ 0xA18A56E5// hardcoded, object type prefix in 4 bytes int64 ProposalID // ID of the proposal bytes Depositer // Address of the depositer message Coin { string denom int64 amount } }
You can relock tokens on your own account after a certain period of time.
message Timerelock{ 0x504711DA// hardcoded, object type prefix in 4 bytes bytes from // sender's address int64 Id // lock time id string description // Description of the lock message Coin { string denom int64 amount } repeated Coin amount int64 lock_time // lock time }
Claim Hash Timer Locked Transfer is to claim the locked asset by showing the random number value that matches the hash. Each HTLT locked asset is guaranteed to be release once.
message ClaimHTLTMsg{ 0xC1665300// hardcoded, object type prefix in 4 bytes bytes from // sender's address bytes swap_id bytes random_number }
A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account doesn't have its own private key and it's only controlled by code of the protocol. The code for calculating escrow account is the same that is used in cosmos-sdk.
Trading fees are subject to complex logic that may mean that individual trades are not charged exactly by the rates below, but between them instead; this is due to the block-based matching engine in use on the DEX.
The current fee for trades, applied on the settled amounts, is as follows:
Transaction Type
Pay in non-BNB Asset
Pay in BNB
Trade
0.1%
0.05%
Trading fee can be queried at here. It's under the "params/DexFeeParam/". "FeeRate" and "FeeRateNative" are both under unit of 10^-6.
The difference between BNB Chain and Ethereum is that there is no notion of gas. As a result,
fees for the rest transactions are fixed. The details are showned in the table below:
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Mainnet as of 2021-03-21 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Testnet as of 2021-03-17 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
bnbcli offers you a multi-send command to transfer multiple tokens to multiple people. 20% discount is available for multi-send transactions. For now, multi-send transaction will send some tokens from one address to multiple output addresses. If the count of output address is bigger than the threshold, currently it's 2, then the total transaction fee is 0.001 BNB per token per address.
For example, if you send 3 ABC token,1 SAT token and 1 ABC to 3 different addresses.
If you have a fullnode running, you can also get the rewards details exported. To achieve this, you need to set publishBlockFee to be true in your app.toml. To receive rewards stream, there aretwo options publishKafka and publishLocal
-
+
diff --git a/docs/beaconchain/learn/genesis.html b/docs/beaconchain/learn/genesis.html
index b8c70c73bc..e62a570d7f 100644
--- a/docs/beaconchain/learn/genesis.html
+++ b/docs/beaconchain/learn/genesis.html
@@ -9,7 +9,7 @@
-
+
@@ -40,7 +40,7 @@
weighted by voting power) that are the recipient of a valid gentx come online after genesis_time.
A gentx is just a signed message that validator signed to agree to be validators. Let us break down the parameters:
Signature related info
pub_key: pubkey is used for verifying signature
signature: the signature from validator
account_number: Unique identifier for the account. It is generated the first time a transaction including this
account is included in a block. In gentx, they are all 0
sequence: This number is used to count the number of transactions sent by this account. It is incremented each
time a transaction is included in a block, and used to prevent replay attacks. Initial value is 0.
memo, source and data are all customized details regarding this transaction
Delegation related info
moniker: the name of validator
delegator_address: this is the address that is listed in app_state section
validator_address: this is the validator pubkey in bech32 encoding with prefix of bva
delegation: this is the delegation amount. It's shifted by 8 digits for representing decimals.
Binance DEX is the native marketplace on BNB Beacon Chain , allowing you to exchange digital assets issued and listed on it.
The matching happens within the blockchain nodes and all of the transactions are recorded on-chain, therefore forming a complete, auditable ledger of activity.
ATTENTION: The match logic on DEX is quite different from normal centralized exchange.
Please go over the trading and match spec below to get the best interests for your orders.
Order Types
Binance DEX only accept LIMIT orders, which is adhering to SEC definitions of LIMIT orders
TimeInForce:
* GTE: Good Till Expire. Order would stay effective until expire time. Order may expire in the UTC midnight after more than 259, 200 blocks, which is 72 hours in term of blocking time. * IOC: Immediate or Cancel. Orders would be executed as much as it can in the booking block round and then got canceled back if there is still quantity left.
Match Logic
Binance DEX uses periodic auction to match all available orders. Maker/Taker concepts are introduced to enhance the current periodic auction match algorithm. The match is still executed only once in each block while the execution prices may vary for maker and taker orders.
Anti-front-running
Front-running means someone can get prior knowledge of transactions from other beneficial owners via technology or market advantage, so that they can influence the price beforehand and result in economic gain, which usually brings loss or cost to others. It is a daunting question asked to both centralized and other decentralized exchanges (DEX). Especially on some DEX, front-running actually happens quite often, e.g. via gas or timestamp manipulations, or slow matching.
There are several design points in Binance DEX that make front-running very difficult to execute.
Signature is the evidence to prove the sender owns the transaction. It will be created from the actions outlined below:
Compose a data structure. please note msgs, memo, source, data are the same as in the above payload.
- `chain_id`: a string, unique ID for the Chain, it stays the same for most time, but may vary as BNB Beacon Chain evolves; - `account_number`: a string for a 64-bit integer, an identifier number associated with the signing address - `sequence`: a string for a a 64-bit integer, please check [accounts](/docs/beaconchain/learn/accounts) - `memo`: a string, a short sentence of remark for the transaction - `msgs`: a byte array, **json encoded** transaction messages, please check the [encoding](/docs/beaconchain/learn/encoding/) doc. - `source`: a string for a 64 bits integer, which is an identifier for transaction incoming tools - `data`: byte array, reserved for future use
Encode the above data structure in json, with ordered key, Specifically:
Maps have their keys sorted lexicographically
Structs keys are marshalled in the order defined in the struct
Sign SHA256 of the encoded byte array, to create an ECDSA signature on curve Secp256k1 and serialize the R and S result into a 64-byte array. (both R and S are encoded into 32-byte big endian integers, and then R is put into the first 32 bytes and S are put into the last 32 bytes of the byte array. In order to break S 's malleability, S set to curve.Order() - S if S > curnve.Order()/2.)
The signature will be encoded together with transaction message and sent as payload to BNB Beacon Chain node via RPC or http REST API, as described in the above section.
Threshold Signature Scheme (TSS) is a cryptographic protocol for distributed key generation and signing. TSS allows constructing a signature that is distributed among different parties (for example three users), and each user receives a share of the private signing key. To sign a transaction, at least two of these three users need to join. For individuals, threshold signatures allow for two-factor security or splitting the ability to sign between two devices so that a single compromised device won’t put the money at risk. For businesses, threshold signatures allow for the realization of access control policies that prevent both insiders and outsiders from stealing corporate funds. TSS technology allows us to replace all signing commands with distributed computations.The private key is no longer a single point of failure.
A physical key must fit exactly into a keyhole to unlock a physical vault. But if this key is compromised or lost, the funds locked in the vault may no longer be safe. This simple approach of key management may make sense when a small sum is at stake. However, when the amount stored in the vault is large, it is wise to consider spreading the responsibility of key ownership between several trusted parties.
Traditional MultiSig (multi-signature) is a more refined unlocking system that requires multiple independent keys to unlock the vault. MultiSig requires generating a larger private key and the vault has multiple locks - one for each key . More processing power is needed as participants have to sign additional signatures, which must then be checked individually by the network. This is not ideal, because a participant must leave traces showing exactly who signed and multiple parties must be online at the same time.
With Threshold Signatures, all of the parties must forge the vault’s lock together, in a modular way, where each party owns a share of the key. A TSS vault is indistinguishable from a regular vault and is hence universal, and it has the same privacy and verification cost of a regular vault. Even if only a subset of the keys is available, the vault may still be unlocked (this is known as meeting a threshold of participation).
Combining TSS feature with BNB Beacon Chain client will help users manage their funds in a much safer way. TSS will be offered in an independent binary, but it will have some impact on the existing functions of bnbcli/tbnbcli.
Many development resources have been poured into implementing TSS, a cryptographic protocol for distributed key generation and signing. TSS is now compatible and reusable for ECDSA-based blockchains, including BNB Beacon Chain , Bitcoin, and Ethereum networks. We expect that members of the BNB Chain ecosystem and partner community can integrate this TSS library with their applications, such as wallets and custodians, and further develop this exciting new technology.
The implementation of a multi-party threshold ECDSA library is open source so it can be publicly audited by anyone. An independent third party auditors from Kudelski Security are hired to validate the security of the cryptography in TSS solution. The latest report in October by can be found here.
Security checks are routinely and continuously planed for all parts of TSS lib implmentations and future audits will be reported to BNB Beacon Chain community.
Vault Initialization: the first step is for setting up tss parameters of each party. This will initialize the node's p2p listen address and setup a directory to save key. It's recommended that you should save your tss key in a different folder other than normal key info.
Key Generation: the second step is also the most complex. We need to define the quorum policy: count of total parties (n) that holds secret shares and threshold (t) which means at least t + 1 parties need to take part in the signing process. We need to generate a key which will be public and used to verify future signatures. However, we also have to generate an individual secret for each party, which is called a secret share. The functions guarantee the same public key to all parties and a different secret share for each. In this way, we achieve: (1) privacy: no secret shares data is leaked between any parties, and (2) correctness: the public key is intact with secret share. They need to agree on the channel which they want to use for sending messages between each other. The channel will have its corresponding password. Both ID and password needs to be shared offline.
Signing: this step involves a signature generation function. The input of each party will be its own secret share, created as output of the distributed key generation in the previous step. There is also public input known to all, which is the message to be signed. The output will be a digital signature, and the property of privacy ensures that no leakage of secret shares occurred during the computation.
Verification: the verification algorithm remains as it is in the classical setting. To be compatible with single key signatures, BNB Beacon Chain validator nodes can be able to verify the signature with the public key. The transaction will be no different from others.
Vault Regroup: Regroup will reset secret share and configs between all parties.It's recommend to switch the configuration periodically, say once a month. If some party lost his key, it's also necessory to reset the distribution once some party lost their key. Regroup will generate new_n secret share with new_t threshold. At least old_t + 1 should participant
This command will generated the private key and share the secret. Everyone needs to agree on the password of this private key. The lenght of password must be more than eight.
Note: you need to make sure that all the parties are online.
Here are the flags for tss keygen:
Name
Type
Description
Note
address_prefix
string
prefix of bech32 address
the default value is bnb
channel_id
string
channel id for this session
channel_password
string
password to this channel
This password has to be set offline. And its length should be more than eight.
p2p.peer_addrs
[]sting
peer's multiplex addresses
parties
int
total parities of this scheme
threshold
int
threshold of this scheme, at least threshold + 1 parties need participant signing
if you want to add the generated key files in the bnbcli home, you can copy it to the home folder:
This command will generate new_n secret from the same private key, and it will be shared with new_t threshold. At least old_t + 1 should participante in signing
Here are the flags for tss regroup:
Name
Type
Description
Note
channel_password
string
channel password of this session
channel_id
string
channel id of this session
is_old
string
whether this party is old committee. If it is set to true, it will participant signing in regroup. There should be only t+1 parties set this to true for one regroup
is_new_member
string
whether this party is new committee, for new party it will changed to true automatically. if an old party set this to true, its share will be replaced by one generated one
new_parties
int
new total parties of regrouped scheme
new_threshold
int
new threshold of regrouped scheme
p2p.new_peer_addrs
[]sting
unknown peer's multiple addresses
parties
int
total parities of this scheme
threshold
int
threshold of this scheme, at least threshold + 1 parties need participant signing
In this example, A, B and C are the parties who decided to share a private key together. They decided that any two of them can sign a transaction. To complete a TSS signing process, they need to follow the following steps:
During this step, all parties from different machines have to initialite their P2P settings before generate the shared key.
A
B
C
command
./tss init
./tss init
./tss init
Interactive input
> please set moniker of this party: tss1 > please set vault of this party: vault1 > please set password of thisvault: [input password] > please input again: [input password]
> please set moniker of this party: tss2 > please set vault of this party: vault1 > please set password of this vault: [input password] >please input again: [input password]
> please set moniker of this party: tss3 > please set vault of this party:vault1 > please set password of this vault: [input password] > please input again: [input password]
output
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
In this step, the parties will create a secrect communication channel between them. One of then will generate the channel ID and share with others. In this example, A will generate the channel ID. B and C will not have to do anything. A can also specify the length for this channel session and the default time is 30 mins.
A
B
C
command
./tss channel
N/A
N/A
Interactive input
> please set expire time in minutes, (default: 30): [input time]
In this step, the private key will be generated and shared between these three parties. All the parties have to be online at the sme time.
A
B
C
command
./tss keygen --vault_name vault1
./tss keygen --vault_name vault1
./tss keygen --vault_name vault1
Interactive input
> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session [enter ID] > please input password (AGREED offline with peers) of this session: [enter password] > please input password of this tss vault: [enter password]
>please input> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session [enter ID] >please input password (AGREED offline with peers) of this session: [enter password] >please input password of this tss vault: [enter password]
> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session 3085D3EC76D > please input password (AGREED offline with peers) of this session: [enter password] Password of this tss vault: [enter password]
output
18:00:09.777 INFO tss-lib: party {0,tss1}: keygen finished! party.go:11318:00:09.777 INFO tss: [tss1] received save data client.go:30418:00:09.777 INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss1_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
18:00:09.777 INFO
: party {1,tss2}: keygen finished! party.go:11318:00:09.777 INFO tss: [tss2] received save data client.go:30418:00:09.777 INFO tss: [tss2] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss2_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
18:00:09.773 INFO tss-lib: party {2,tss3}: keygen finished! party.go:11318:00:09.773 INFO tss: [tss3] received save data client.go:30418:00:09.773 INFO tss: [tss3] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss3_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
Password to sign with tss_tss1_vault1: [Enter password] > Channel id: 5185D3EF597 please input password (AGREED offline with peers) of this session: [Enter password]
Password to sign with tss_tss2_vault1: [Enter password] > Channel id: 5185D3EF597 please input password (AGREED offline with peers) of this session: [Enter password]
N/A
output
Committed at block 33600477 (tx hash: 4FB8096A93D545612A3B5DCE520622608C299C7742103A6BE34C444829BD83A5
ERROR: broadcast_tx_commit: Response error: RPC error -32603 - Internal error: Error on broadcastTxCommit: Tx already exists in cache
First, please generate a new channel for messaging:
A
B
C
command
./tss channel
N/A
N/A
Interactive input
> please set expire time in minutes, (default: 30): [input time]
N/A
N/A
output
channel id: 3415D3FBE00
N/A
N/A
Then, we can switch to the new channel for sending messages to each others.
A
B
C
command
./tss regroup
./tss regroup
./tss regroup
Interactive input
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
output
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
New committee having different t-n from old committee
Change 1-3 into 2-4 scheme.
old parties (A, B) join new committee
new parties (D, E) are newly-joined
D
E
command
./tss init --vault_name vault1
./tss init --vault_name vault1
Interactive input
> please set moniker of this party: tss4 > please set password for key share: [Enter password] > please intput again: [Enter password]
> please set moniker of this party: tss4 > please set password for key share: [Enter password] > please intput again: [Enter password]
output
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
Regroup from 1-3 to 2-4, with 2 old parties (A and B) and 2 new parties (D and E)
A (old&new committee)
B (old&new committee)
D (new committee)
E (new committee)
command
./tss regroup/ --vault_name vault1
./tss regroup --vault_name vault1
./tss regroup --vault_name vault1
./tss regroup --vault_name vault1
Interactive input
> please input password: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new commitee? [Y/n]: Y > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > please set Old total parties(n): 3 > please set Old threshold(t), at least t + 1 parties need participant signing: 1 > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > please set Old total parties(n): 3 > please set Old threshold(t), at least t + 1 parties need participant signing: 1 > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
In the bottom left-hand side of the interface, you can locate Open Orders, Order History, Trade History, and Balances.
Open Orders: This section shows which orders are not filled in their entirety and are still currently open. You can view all of the orders on the blockchain by looking at their TxHash.
Order History: This section shows the orders you have placed, filled, unfilled or canceled. You can view all of the orders on the blockchain by looking at their TxHash.
Trade History: This section shows your executed trades on the exchange.
Balances: This section displays the current balance of your BNB Chain Wallet.
Binance DEX currently only supports Limit orders. The Limit order section allows you to define the bid/ask price and the quantity you wish to trade. Please note that all order’s parameters’ constrains:
Price: Order price must be changed by multiple of tick size. Tick size stands for the smallest unit on price change
Quantity: Order quantity must be multiple of lot size. Lot size stands for the smallest quantity change
Timeinforce: It is Good Till Expire (GTE). The order would stay effective until expire time. The order may expire in the UTC midnight after more than 259, 200 blocks, which is 72 hours in terms of blocking time.
A blockchain is a globally shared, transactional database. This means that everyone can read entries in the database just by participating in the network. If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others. The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied. Furthermore, while your transaction is being applied to the database, no other transaction can alter it.
As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.
Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
A blockchain is a globally shared, transactional database. This means that everyone can read entries in the database just by participating in the network. If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others. The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied. Furthermore, while your transaction is being applied to the database, no other transaction can alter it.
As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.
Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
WalletConnect is an open protocol for connecting desktop Dapps to mobile Wallets using end-to-end encryption by scanning a QR code. Opening up a whole world of Dapps that were once only available to Metamask. The user can interact with any Dapp without comprising their private keys and will be notified to sign any transaction requests on their mobile.
WalletConnect is a simple infrastructure that can be setup by any developer. Using a Bridge server to relay the messages without having access to any of its contents. The contents are encrypted using the session data shared by the QR code between the desktop and mobile. There are libraries for Web, iOS and Android. Read more about it in our documentation introduction.
Wallets with WalletConnect Support for BNB Beacon Chain
List of Wallets Supporting WalletConnect on BNB Beacon Chain
Currently the WalletConnect protocol has references implementations written in Typescript for the Client (browser/react-native/nodejs), the Bridge Server and the Push server.
Wallet providers should make use of the WalletConnect Client SDK for their target programming language and OS. There are implementations on GitHub for iOS, Android, React Native, etc.
Since we do not use Ethereum transactions, there are some differences:
Typically sendTransaction is used with Ethereum transaction parameters in WalletConnect dApp integrations. But in BNB Beacon Chain 's case, instead of invoking sendTransaction in the WalletConnect flow, the new sendCustomRequest call is used instead with a method called bnb_sign (see below).
The external wallet provider is responsible for sending back the signature and public key of the transaction but should not broadcast the transaction itself. We have instead defined a custom result format in the form of stringified JSON containing the signature and public key. The reason for this is that the wallet app probably does not have access to the complete serialized binary form of the transaction (as this requires Amino encoding).
The web wallet will send back a second custom call (after bnb_sign) called bnb_tx_confirmation, which contains the boolean result of the transaction build/broadcast and any error message encountered by the web wallet during broadcasting. In a complete implementation, this confirmation callback should be responded to with a call to approveRequest.
-
+
diff --git a/docs/beaconchain/light-client.html b/docs/beaconchain/light-client.html
index 451c2b75b8..067cedb3cf 100644
--- a/docs/beaconchain/light-client.html
+++ b/docs/beaconchain/light-client.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
depends on how many requests the light client handles concurrently.
Light client is faster than a full node even if it lagged behind the core network for a few months. It only needs a few seconds
to catch up with core network.
Download the configuration files according to the network you want to join in.
Help info:
./lightd --help This node will run a secure proxy to a binance rpc server. All calls that can be tracked back to a block header by a proof will be verified before passing them back to the caller. Other that that it will present the same interface as a full binance node, just with added trust and running locally. Usage: lite [flags] Flags: --cache-size int Specify the memory trust store cache size (default 10) --chain-id string Specify the BNB Beacon Chain ID (default "bnbchain") -h, --help help for lite --home-dir string Specify the home directory (default ".binance-lite") --laddr string Serve the proxy on the given address (default "tcp://localhost:27147") --max-open-connections int Maximum number of simultaneous connections (including WebSocket). (default 900) --node string Connect to a binance node at this address (default "tcp://localhost:27147")
You can specify all the parameters above.
Start the light client node according to the Platform. Replace the platform variable with mac, windows or linux in the following command:
We supply a bunch of full nodes that you can connect to for both mainnet and testnet.
You cat get full nodes info through a simple python script(notice to replace domain according to different network):
import requests, json d = requests.get('https://dex.binance.org/api/v1/peers').text # replace dex.binance.org with testnet-dex.binance.org for testnet l = json.loads(d) seeds =",".join([(seed["id"]+"@"+seed["original_listen_addr"])for seed in l if seed["accelerated"]==False]) print(seeds)
Only BEP2 tokens issued on BNB Beacon Chain can be listed. Learn how to issue BEP2 tokens here. If a token's listing proposal has been passed by valdiators, then a list transaction must be sent before expire-time.
Please refer to this governance doc to learn about how to create a proposal about listing a new trading pair on BNB Beacon Chain .
Please ensure that you test EVERYTHING on our testnet (multiple times at least) before you officially execute this on the mainnet.
Community Thread Proposal (Recommended)
It is recommended that Token Issuers first create a thread under the “Token Issuance & Listings” category in the BNB Beacon Chain Community Forum (https://community.binance.org/). The whole guideline is here
Simply allowing trading between two assets seems easy enough, however it is expensive for not only the network but also its users in long term (and liquidity costs can be much larger). In order to efficiently use the network, BNB Beacon Chain only list assets against BNB and other widely accepted market quote assets.
The design philosophy of Binance DEX adheres to the idea that the most efficient and low cost way to perform trading and price-discovery is still to use single order book. This single order book is managed and replicated across all full nodes with the same, deterministic matching logic.
- For scenarios that all the the equivalent surplus amounts are positive, if all the prices are below the reference price plus an upper limit percentage (e.g. 5%), then algorithm uses the highest of the potential equilibrium prices. If all the prices are above the reference price plus an upper limit, use the lowest price; for other cases, use the reference price plus the upper limit. - Conversely, if market pressure is on the sell side, if all prices are above the reference price minus a lower percentage limit, then the algorithm uses the lowest of the potential prices. If all the price are below the reference price minus the lower percentage limit, use the highest price, otherwise use the reference price minus the lower percentage limit. If both positive and negative surplus amounts exist, precede to Step 4.
Step 4: When both positive and negative surplus amounts exists at the lowest, if the
reference price falls at / into these prices, the reference price should be chose, otherwise
the price closest to the reference price would be chosen.
-
+
diff --git a/docs/beaconchain/match.html b/docs/beaconchain/match.html
index 1684ac4356..9707aca13c 100644
--- a/docs/beaconchain/match.html
+++ b/docs/beaconchain/match.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
would be allocated to each order in proportion to their quantity (floored if the number has a partial lot).
If the allocation cannot be accurately divided, a deterministic algorithm would guarantee that no consistent
bias to any orders.
After the execution price P is concluded, buy orders with price equal to or larger than P, and sell orders with price equal to or less than P will match. For the orders that come into match in the new block, the trades will be allocated according to the below principles:
All new incoming buy orders into this current block (called "new orders" in this context) will get executed with the same price, so do all the sell orders; so that there is no chance for front-running on the same side.
All the executed price will honor the order limit price;
All the executed price for the new orders will be equal to or better than the concluded auction price P, so no front-running from the opposite side.
For other orders that have arrived in the previous blocks, they will join match together with the new orders from the new block, and be considered as "Maker" role. The detailed explanation of Maker/Taker is as below:
Among all the orders to be allocated, between buy and sell sides, this specification defines four concepts.
Name
Definition
Maker Order
order from the previous blocks
Taker Order
new incoming order in the current block
Maker Side
buy or sell side which has maker orders. May also have taker orders.
Taker Side
buy or sell side which only has taker orders.
In each round of match, for all the orders that can be filled with the concluded price P, the algorithm ensures only one of the below two circumstances can happen,
Both buy and sell side are Taker Side, when there is no leftover orders from all the previous blocks;
One side is Maker Side that has orders from previous blocks (and may/may not have orders from this current block), and the other is Taker Side that only has orders from this current block.
-
+
diff --git a/docs/beaconchain/memo-validation.html b/docs/beaconchain/memo-validation.html
index bdd3f7c11c..cb408ba6a0 100644
--- a/docs/beaconchain/memo-validation.html
+++ b/docs/beaconchain/memo-validation.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
First, this script will check the following conditions:
The transaction type is sent.
The target address is the receiving address.
Then this script will ensure that the transaction memo is not empty and the memo only contains digital letters.
This is the pseudocode:
func memoValiation(addr, tx) error { if tx.Type != “send” { return nil } if ! isReceiver(tx, addr) { return nil } if tx.memo.length == 0 { return err(“tx memo is empty”) } if tx.memo.length > 100 { return err(“tx memo is too long”) } if !isAllDigital(tx.memo) { return err(“tx memo contains non digital character”) } return nil }
bnbcli support generating and signing all types of transactions offline, then broadcast them. This feature will let users generate and sign their transactions at an offline machine, then use another machine to broadcast it to the network
As explained in BEP9, some business plans decide to lock certain amount tokens for pre-defined periods of time, and the only vest in the future according to the schedules. For example, some projects may lock some allocation of the issued tokens as a commitment by the founding team; some business scenarios also need to lock some tokens as collateral for value.
You can only lock tokens on your own account. TimeLock will transfer locked tokens to a purely-code-controlled escrow account and before the lock time expires. A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account doesn't have its own private key and it's only controlled by code of the protocol. The code for calculating escrow account is the same that is used in cosmos-sdk:
The account for mainnet is: bnb1hn8ym9xht925jkncjpf7lhjnax6z8nv24fv2yq and the account for testnet is: tbnb1hn8ym9xht925jkncjpf7lhjnax6z8nv2mu9wy3
The specific user will not be able to claim them back, including restrictions where they cannot use, transfer or spend these tokens.
Description of the lock operation. Max length of description is 128 bytes.
Amount
[]Coin
A set of tokens to be locked
LockTime
int64
The time when these tokens can be unlocked. LockTime is a future timestamp (seconds elapsed from January 1st, 1970 at UTC) and max LockTime should be before 10 years from now.
broadcast
bool
if you want to submit your transaction to the blockchain
Example output for trying to unlock tokens whose locking period is not expired:
ERROR: {"codespace":7,"code":7,"abci_code":458759,"message":"Can not unlock: lock time(2019-06-28 09:26:54 +0000 UTC) is after now(2019-06-27 08:31:54.680643156 +0000 UTC)"}
The time when these tokens can be unlocked. LockTime is a future timestamp(seconds elapsed from January 1st, 1970 at UTC) and max LockTime should be before 10 years from now.
broadcast
bool
if you want to submit your transaction to the blockchain
Output if you don't add more tokens or don't extend your locking period, you will get the following error:
ERROR: {"codespace":7,"code":6,"abci_code":458758,"message":"Invalid lock amount: new locked coins(100000000BNB) should be more than original locked coins(100000000BNB)"}
-
+
diff --git a/docs/beaconchain/tokens.html b/docs/beaconchain/tokens.html
index c9814e242a..b9a8dae7e0 100644
--- a/docs/beaconchain/tokens.html
+++ b/docs/beaconchain/tokens.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
The symbol doesn't have to be unique, "-" followed by random 3 letters will be appended to the provided symbol to avoid uniqueness constraint.
Those 3 letters are the first three letters of tx hash of the issue transaction.
For example, "NNB-B90". Only BNB does not have this suffix.
Total Supply: an int64 boosted by 1e8 for decimal part. The max total supply is 90 billion.
Mintable: that means whether this token can be minted in the future. To set the tokes to be mintable, you need to add --mintable, otherwise just omit this field to set this token to be non-mintable.
Example on mainnet:
# To issue a NNB mintable token with total-supply 1 billion on mainnet > ./bnbcli token issue --token-name "new token" --total-supply 100000000000000000 --symbol NNB --mintable --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
# To issue a NNB non-mintable token with total-supply 1 billion on mainnet > ./bnbcli token issue --token-name "new token" --total-supply 100000000000000000 --symbol NNB --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
Example on testnet:
# To issue a NNB mintable token with total-supply 1 billion on testnet > ./tbnbcli token issue --token-name "new bnb" --total-supply 100000000000000000 --symbol NNB --mintable --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node Committed at block 1887(tx hash: B90A055DDD570AE42A7050182993A0B4DBC81A0D, ... Issued NNB-B90...)
# To issue a NNB non-mintable token with total-supply 1 billion on testnet > ./tbnbcli token issue --token-name "new bnb" --total-supply 100000000000000000 --symbol NNB --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node Committed at block 1887(tx hash: B90A055DDD570AE42A7050182993A0B4DBC81A0D, ... Issued NNB-B90...)
Tokens that is "mintable"(specified when issue) can use this function. The amount is boosted by 1e8 for decimal part. The total supply after mint is still restricted by 90 billion. Note only the owner of the token can use this transaction.
Example on mainnet:
> ./bnbcli token mint --amount 100000000000000000 --symbol NNB-B90 --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
Example on testnet:
> ./tbnbcli token mint --amount 100000000000000000 --symbol NNB-B90 --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node
Burn is to destroy certain amount of token, after which that amount of tokens will be subtracted from the operator's balance. The total supply will be updated at the same time. Notice that only the owner of the token has the permission to burn token. The amount is boosted by 1e8 for decimal part.
Freeze would move the specified amount of token into "frozen" status, so that these tokens can not transferred, spent in orders or any other transaction until they are unfreezed.
Anyone can (only) freeze or unfreeze tokens on their account with status in "free". The amount is boosted by 1e8 for decimal part.
Binance DEX is the native marketplace which allows you to exchange digital assets issued and listed on it. The matching happens within the blockchain nodes and all of the transactions are recorded on-chain, therefore forming a complete, auditable ledger of activity. The following commands are available for trading:
-
+
diff --git a/docs/beaconchain/trading-spec.html b/docs/beaconchain/trading-spec.html
index 0734c78126..3f87cbd215 100644
--- a/docs/beaconchain/trading-spec.html
+++ b/docs/beaconchain/trading-spec.html
@@ -9,7 +9,7 @@
-
+
@@ -32,7 +32,7 @@
existing orders on the order book can still be traded.
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Mainnet as of 2021-03-21 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
bnbcli offers you a multi-send command to transfer multiple tokens to multiple people. 20% discount is available for multi-send transactions. For now, multi-send transaction will send some tokens from one address to multiple output addresses. If the count of output address is bigger than the threshold, currently it's 2, then the total transaction fee is 0.0003 BNB per token per address.
For example, if you send 3 ABC token,1 SAT token and 1 ABC to 3 different addresses.
Trading fees are subject to complex logic that may mean that individual trades are not charged exactly by the rates below, but between them instead; this is due to the block-based matching engine in use on the DEX.
The current fee for trades, applied on the settled amounts, is as follows:
Transaction Type
Pay in non-BNB Asset
Pay in BNB
Trade
0.1%
0.05%
Trading fee can be queried at here. It's under the "params/DexFeeParam/". "FeeRate" and "FeeRateNative" are both under unit of 10^-6.
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Testnet as of 2021-03-17 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
Trade fee is calculated based on trade notional value, while fees for other transactions are fixed.
It is free to send new GTE order, cancel a partially filled order, and you will not be charged a fee when the system expires a partially filled order (GTE or IOC).
Non-Trade related transactions will be charged a fee when the transactions happen, and can only be paid in BNB. The transaction will be rejected if the address does not have enough BNB.
Trade related transaction would be charged with fee when an order is filled, or canceled/expired/IOC-expired with no fills. If there is enough BNB to pay, BNB fee structure would be used, otherwise, non-BNB fee structure would be used to charged.
If the whole order value and free balance for the receiving asset are not enough to pay the fee, all the receiving asset and its residual balance would be charged.
-
+
diff --git a/docs/beaconchain/transfer.html b/docs/beaconchain/transfer.html
index 6061128811..2371a05274 100644
--- a/docs/beaconchain/transfer.html
+++ b/docs/beaconchain/transfer.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
format is showed above. In the same time, you can write the transaction detail in a file and specify --transfers-file
flag and read from the file contains transaction.
Example, you can specify --transfers and send it to mainnet:
As you can see from the example output, this transaction is executed at block height 1412766 and you could read about the details.
Double check with blockchain explorer if you interact with the network through a full-node.
Threshold Signature Scheme (TSS) is a cryptographic protocol for distributed key generation and signing. TSS allows constructing a signature that is distributed among different parties (for example three users), and each user receives a share of the private signing key. To sign a transaction, at least two of these three users need to join. For individuals, threshold signatures allow for two-factor security or splitting the ability to sign between two devices so that a single compromised device won’t put the money at risk. For businesses, threshold signatures allow for the realization of access control policies that prevent both insiders and outsiders from stealing corporate funds. TSS technology allows us to replace all signing commands with distributed computations.The private key is no longer a single point of failure.
A physical key must fit exactly into a keyhole to unlock a physical vault. But if this key is compromised or lost, the funds locked in the vault may no longer be safe. This simple approach of key management may make sense when a small sum is at stake. However, when the amount stored in the vault is large, it is wise to consider spreading the responsibility of key ownership between several trusted parties.
Traditional MultiSig (multi-signature) is a more refined unlocking system that requires multiple independent keys to unlock the vault. MultiSig requires generating a larger private key and the vault has multiple locks - one for each key . More processing power is needed as participants have to sign additional signatures, which must then be checked individually by the network. This is not ideal, because a participant must leave traces showing exactly who signed and multiple parties must be online at the same time.
With Threshold Signatures, all of the parties must forge the vault’s lock together, in a modular way, where each party owns a share of the key. A TSS vault is indistinguishable from a regular vault and is hence universal, and it has the same privacy and verification cost of a regular vault. Even if only a subset of the keys is available, the vault may still be unlocked (this is known as meeting a threshold of participation).
Combining TSS feature with BNB Beacon Chain client will help users manage their funds in a much safer way. TSS will be offered in an independent binary, but it will have some impact on the existing functions of bnbcli/tbnbcli.
Many development resources have been poured into implementing TSS, a cryptographic protocol for distributed key generation and signing. TSS is now compatible and reusable for ECDSA-based blockchains, including BNB Beacon Chain, Bitcoin, and Ethereum networks. We expect that members of the BNB Chain ecosystem and partner community can integrate this TSS library with their applications, such as wallets and custodians, and further develop this exciting new technology.
The implementation of a multi-party threshold ECDSA library is open source so it can be publicly audited by anyone. An independent third party auditors from Kudelski Security are hired to validate the security of the cryptography in TSS solution. The latest report in October by can be found here.
Security checks are routinely and continuously planned for all parts of TSS lib implementations and future audits will be reported to BNB Beacon Chain community.
Vault Initialization: the first step is for setting up tss parameters of each party. This will initialize the node's p2p listen address and setup a directory to save key. It's recommended that you should save your tss key in a different folder other than normal key info.
Key Generation: the second step is also the most complex. We need to define the quorum policy: count of total parties (n) that holds secret shares and threshold (t) which means at least t + 1 parties need to take part in the signing process. We need to generate a key which will be public and used to verify future signatures. However, we also have to generate an individual secret for each party, which is called a secret share. The functions guarantee the same public key to all parties and a different secret share for each. In this way, we achieve: (1) privacy: no secret shares data is leaked between any parties, and (2) correctness: the public key is intact with secret share. They need to agree on the channel which they want to use for sending messages between each other. The channel will have its corresponding password. Both ID and password needs to be shared offline.
Signing: this step involves a signature generation function. The input of each party will be its own secret share, created as output of the distributed key generation in the previous step. There is also public input known to all, which is the message to be signed. The output will be a digital signature, and the property of privacy ensures that no leakage of secret shares occurred during the computation.
Verification: the verification algorithm remains as it is in the classical setting. To be compatible with single key signatures, BNB Beacon Chain validator nodes can be able to verify the signature with the public key. The transaction will be no different from others.
Vault Regroup: Regroup will reset secret share and configs between all parties.It's recommend to switch the configuration periodically, say once a month. If some party lost his key, it's also necessory to reset the distribution once some party lost their key. Regroup will generate new_n secret share with new_t threshold. At least old_t + 1 should participant
This command will generate the private key and share the secret. Everyone needs to agree on the password of this private key. The password length must be larger than eight.
Note: you need to make sure that all the parties are online.
Here are the flags for tss keygen:
Name
Type
Description
Note
address_prefix
string
prefix of bech32 address
the default value is bnb
channel_id
string
channel id for this session
channel_password
string
password to this channel
This password has to be set offline. And its length should be more than eight.
p2p.peer_addrs
[]sting
peer's multiplex addresses
parties
int
total parities of this scheme
threshold
int
threshold of this scheme, at least threshold + 1 parties need participant signing
if you want to add the generated key files in the bnbcli home, you can copy it to the home folder:
This command will generate new_n secret from the same private key, and it will be shared with new_t threshold. At least old_t + 1 should participante in signing
Here are the flags for tss regroup:
Name
Type
Description
Note
channel_password
string
channel password of this session
channel_id
string
channel id of this session
is_old
string
whether this party is old committee. If it is set to true, it will participant signing in regroup. There should be only t+1 parties set this to true for one regroup
is_new_member
string
whether this party is new committee, for new party it will changed to true automatically. if an old party set this to true, its share will be replaced by one generated one
new_parties
int
new total parties of regrouped scheme
new_threshold
int
new threshold of regrouped scheme
p2p.new_peer_addrs
[]sting
unknown peer's multiple addresses
parties
int
total parities of this scheme
threshold
int
threshold of this scheme, at least threshold + 1 parties need participant signing
In this example, A, B and C are the parties who decided to share a private key together. They decided that any two of them can sign a transaction. To complete a TSS signing process, they need to follow the following steps:
During this step, all parties from different machines have to initialite their P2P settings before generate the shared key.
A
B
C
command
./tss init
./tss init
./tss init
Interactive input
> please set moniker of this party: tss1 > please set vault of this party: vault1 > please set password of thisvault: [input password] > please input again: [input password]
> please set moniker of this party: tss2 > please set vault of this party: vault1 > please set password of this vault: [input password] >please input again: [input password]
> please set moniker of this party: tss3 > please set vault of this party:vault1 > please set password of this vault: [input password] > please input again: [input password]
output
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
In this step, the parties will create a secrect communication channel between them. One of then will generate the channel ID and share with others. In this example, A will generate the channel ID. B and C will not have to do anything. A can also specify the length for this channel session and the default time is 30 mins.
A
B
C
command
./tss channel
N/A
N/A
Interactive input
> please set expire time in minutes, (default: 30): [input time]
In this step, the private key will be generated and shared between these three parties. All the parties have to be online at the sme time.
A
B
C
command
./tss keygen --vault_name vault1
./tss keygen --vault_name vault1
./tss keygen --vault_name vault1
Interactive input
> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session [enter ID] > please input password (AGREED offline with peers) of this session: [enter password] > please input password of this tss vault: [enter password]
>please input> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session [enter ID] >please input password (AGREED offline with peers) of this session: [enter password] >please input password of this tss vault: [enter password]
> Password to sign with this vault: [enter password] > please set total parties(n): 3 > please set threshold(t), at least t + 1 parties need participant signing: 1 > please set channel id of this session 3085D3EC76D > please input password (AGREED offline with peers) of this session: [enter password] Password of this tss vault: [enter password]
output
18:00:09.777 INFO tss-lib: party {0,tss1}: keygen finished! party.go:11318:00:09.777 INFO tss: [tss1] received save data client.go:30418:00:09.777 INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss1_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
18:00:09.777 INFO
: party {1,tss2}: keygen finished! party.go:11318:00:09.777 INFO tss: [tss2] received save data client.go:30418:00:09.777 INFO tss: [tss2] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss2_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
18:00:09.773 INFO tss-lib: party {2,tss3}: keygen finished! party.go:11318:00:09.773 INFO tss: [tss3] received save data client.go:30418:00:09.773 INFO tss: [tss3] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp client.go:309Password of this tss vault:NAME: TYPE: ADDRESS: PUBKEY:tss_tss3_vault1 tss tbnb19277gzv934ayctxeg5k9zdwnx3j48u6tydjv9p bnbp1addwnpepqwazk6d3f6e3f5rjev6z0ufqxk8znq8z89ax2tgnwmzreaq8nu7sx2u4jcc
Password to sign with tss_tss1_vault1: [Enter password] > Channel id: 5185D3EF597 please input password (AGREED offline with peers) of this session: [Enter password]
Password to sign with tss_tss2_vault1: [Enter password] > Channel id: 5185D3EF597 please input password (AGREED offline with peers) of this session: [Enter password]
N/A
output
Committed at block 33600477 (tx hash: 4FB8096A93D545612A3B5DCE520622608C299C7742103A6BE34C444829BD83A5
ERROR: broadcast_tx_commit: Response error: RPC error -32603 - Internal error: Error on broadcastTxCommit: Tx already exists in cache
First, please generate a new channel for messaging:
A
B
C
command
./tss channel
N/A
N/A
Interactive input
> please set expire time in minutes, (default: 30): [input time]
N/A
N/A
output
channel id: 3415D3FBE00
N/A
N/A
Then, we can switch to the new channel for sending messages to each others.
A
B
C
command
./tss regroup
./tss regroup
./tss regroup
Interactive input
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
> please set vault of this party: vault1 > Password to sign with this vault: Password to sign with tss_tss1_vault1: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set new total parties(n): 3 > please set new threshold(t), at least t + 1 parties participant signing: 1 > Channel id: 3415D3FBE00 please input password (AGREED offline with peers) of this session: Password to sign with tss_tss1_vault1: [Enter password]
output
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
INFO tss: [tss1] bech32 address is: tbnb1mcn0tl9rtf03ke7g2a6nedqtrd470e8l8035jp
New committee having different t-n from old committee
Change 1-3 into 2-4 scheme.
old parties (A, B) join new committee
new parties (D, E) are newly-joined
D
E
command
./tss init --vault_name vault1
./tss init --vault_name vault1
Interactive input
> please set moniker of this party: tss4 > please set password for key share: [Enter password] > please intput again: [Enter password]
> please set moniker of this party: tss4 > please set password for key share: [Enter password] > please intput again: [Enter password]
output
Local party has been initialized under: ~/.tss/vault1
Local party has been initialized under: ~/.tss/vault1
Regroup from 1-3 to 2-4, with 2 old parties (A and B) and 2 new parties (D and E)
A (old&new committee)
B (old&new committee)
D (new committee)
E (new committee)
command
./tss regroup/ --vault_name vault1
./tss regroup --vault_name vault1
./tss regroup --vault_name vault1
./tss regroup --vault_name vault1
Interactive input
> please input password: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > Participant as an old committee? [Y/n]: Y > Participant as a new committee? [Y/n]: Y > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > please set Old total parties(n): 3 > please set Old threshold(t), at least t + 1 parties need participant signing: 1 > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
> please input password: [Enter password] > please set Old total parties(n): 3 > please set Old threshold(t), at least t + 1 parties need participant signing: 1 > please set NEW total parties(n): 4 > please set NEW threshold(t), at least t + 1 parties need participant signing: 2 > Channel id: 3415D3FBE00 > please input password (AGREED offline with peers) of this session: [Enter password]
Send a create-validator-open transaction to declare the candidacy. The minimal self-delegation asset amount is 10000 BNB.
Make users delegate on your validator. All the validators will be ranked by their accumulated BNB stake amount.
There is an on-chain parameter MaxValidators. Only the validator candidates whose rank meets the requirement can be elected.
Use the command below to generate a consensus key. It will be used in the full node to sign the consensus message if the validator gets bonded.
$ bnbcli utils gen-consensus-key The consensus key has been generated and saved to ./priv_validator_key.json successfully The consensus pubkey is bcap1zcjduepqg6glk780f4ynvjjk82drnycty7zjl0uz79a6h2depnhavshvg39sm0c5tl
-
+
diff --git a/docs/beaconchain/validator/overview.html b/docs/beaconchain/validator/overview.html
index 3c259f086c..2f15a35d32 100644
--- a/docs/beaconchain/validator/overview.html
+++ b/docs/beaconchain/validator/overview.html
@@ -9,7 +9,7 @@
-
+
@@ -29,7 +29,7 @@
BSC security. It will happen in the block reward distribution period. The initial ratio will be decided through governance.
The block proposer and its delegators receive between 1% and 5% of block fee rewards. It includes 2 parts:
base: fees * baseProposerReward
bonus: fees * bonusProposerReward * P, where P = (total number of validators with included precommits / total bonded validator number).
The more precommits the proposer includes, the larger P is. P can never be larger than 1.00
(since only bonded validators can supply valid precommits) and is always larger than 2/3.
Any remaining fees are distributed among all validators equally, including the proposer.
The fees will be distributed and accumulated in the system-controlled addresses in every block. The FeeForAll part will go to a fixed address and the FeeForProposer part will go to a custody address which is derived from the proposer’s validator address. Nobody can spend money on the FeeForAll address and validators’ custody addresses. They can only be distributed to validators and delegators during the reward distribution period.
To reduce the cost of frequent block reward distribution, the reward distribution to delegators will happen every day around UTC 00:00(in the breath block).
The BEP-128 introduced an optimized mechanism that distributes staking rewards in many consecutive blocks, to minimize the burden on the specific block. It's expected to use the same mechanism in BC reward distribution. The BC reward distribution will happen right after the BSC reward distribution.
Alternatively, if you choose a different $BNCHOME location and you are not using the suggested default ~/.bnbchaind, you may start the full node by using below script, where $BNCHOME is your selected directory.
Example: If you set /usr/local/beacon-chain as your home directory. Run the Full Node with:
Open imToken, click "Create Identity" and click to agree to the terms of service.
Fill in your identity name and wallet password. Next, click "Create", copy the backup mnemonic phrase with pen and paper and keep it in a safe place. Confirm the mnemonic words in order again and click "Next" to successfully create a wallet.
BSC is the abbreviation of BNB Smart Chain . The chain adopts PoSA (Proof of Staked Authority), which means holders of BNB (BSC's native token) vote to select 50 validators that are responsible for on-chain transaction verification and block production.
Since BSC is EMV-compatible, developers can easily deploy smart contracts and build DApps on the chain. Compared with Ethereum, BSC has lower gas fees and faster transaction settlement with lower security guarantees.
With imToken wallet we do not only support BSC DApps and watching token balances but also the DeFi Portfolio feature, providing a holistic BSC experience.
Click on "Ecosystem Applications" on the asset homepage to view and experience recent popular DApps on the BSC chain.
How to send funds from Binance to your imToken Wallet
To withdraw BSC assets from Binance to imToken, you can follow the steps below. We use the BNB token as an example.
Click on the wallet address, enter the payment page, and click "Copy".
Open Binance, click "Funds"-"Withdraw", select "BNB" or other BSC-supported assets.
Select "BEP20 (BSC)" in "Network", paste the copied address, and enter the withdrawal password to proceed with withdrawal. Make sure it’s the correct address.
Withdraw coins from imToken wallet to Binance Exchange
If you want to recharge assets on BSC from imToken to Binance Exchange, you can follow the steps below, here is BNB as an example.
Enter Binance Exchange, click "Assets"-"Recharge", select "BNB" or other BSC-supported assets.
Select "BEP20 (BSC)" in "Network" and click to copy the BNB recharge address.
On the asset page, click BNB to enter the transfer page, click "Transfer", paste Binance's recharge address, enter the withdrawal amount, and click "Next" to complete the transfer after paying the miner's fee.
Risk Warning: The content of this article does not constitute any form of investment advice or recommendation. imToken does not make any guarantees and promises for the third-party services and products mentioned in this article, nor assume any responsibility. Digital asset investment has risks. You should carefully evaluate these investment risks and consult with relevant professionals to make your own decisions.
-
+
diff --git a/docs/beaconchain/wallet/tutorial/how-to-create-a-wallet-on-trustwallet.html b/docs/beaconchain/wallet/tutorial/how-to-create-a-wallet-on-trustwallet.html
index d169d5ae72..5a4e138d60 100644
--- a/docs/beaconchain/wallet/tutorial/how-to-create-a-wallet-on-trustwallet.html
+++ b/docs/beaconchain/wallet/tutorial/how-to-create-a-wallet-on-trustwallet.html
@@ -9,7 +9,7 @@
-
+
@@ -25,7 +25,7 @@
30+ Blockchains, including Bitcoin, Ethereum,
BNB, XRP and many more.
Exchange these cryptocurrencies with our upcoming coin swap function and buy Bitcoin, Ethereum and more with your credit card.
2) Click "Unlock wallet" on the top right navigation bar
The recommended way for unlocking is by WalletConnect or Ledger.
If you use Ledger, please select the address you want to use for this session.
After unlocking your wallet, make sure that your balance is correct by clicking the "Balance" button on the navigation bar. Then, you will go to: https://www.binance.org/en/balances
4) Place your order (Found on the bottom right of the page)
At the moment, Binance DEX only supports Limit Orders.
You can use the "Best Ask" to input the minimum price that you can currently buy for.
You use the "Best Bid" to input the highest price that you can currently sell for.
"Price" - The number of tokens per token that you are willing to buy / sell for. "Price" can only be changed with "Tick Size". For $ONE, the tick size is 0.00000001
"Amount" the number of tokens you wish to buy / sell. "Amount" can only be changed with "Lot Size". For $ONE, the lot size is 10.
"25% / 50% / 75% / 100%" This will allocate the selected percentage of your funds to either be sold or used to buy.
For example on the buy side if you want to buy 100$ONE and your limit price is 0.0006625. Then, the total notional for this order is 0.06625.
Click "Buy ONE" Confirm the submission of your order.
"Not enough balance" A common error that will occur if the number of tokens required to execute the order is more than the total number of tokens displayed in your "Total" balance.
Price warning - if the price you inputted an order at is above 2% higher than the latest market price then you will be notified. Proceed with caution.
A note will pop up on the right corner of your screen after you confirmed your order.
5) Verifying your order was created and placed
Once you made an order, you can see that in your order history on the first tab at the bottom left of the page.
Once filled you can view your completed trades under "Order History" on the second tab at the bottom left of the page.
To check wallet balance click the "Balance" button
6) Cancelling open orders
To cancel an order that has either not been filled or has only been partially filled you can click on the "X" at the right side of the "Open Orders" tab on the bottom right of the screen.
-
+
diff --git a/docs/beaconchain/wallet/tutorial/ledger-nano-s-usage-guide.html b/docs/beaconchain/wallet/tutorial/ledger-nano-s-usage-guide.html
index cd0c10328e..0b01b118e6 100644
--- a/docs/beaconchain/wallet/tutorial/ledger-nano-s-usage-guide.html
+++ b/docs/beaconchain/wallet/tutorial/ledger-nano-s-usage-guide.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
If it is, the installation has been successful.
Choose one address to use for this session and click on "Confirm".
You will then be redirected to the Trading Interface.
For your security, please read the information displayed in the following popup and confirm that the address shown on your Ledger device matches the one shown on-screen.
Press the right button on your device to confirm that the address matches (You must do this to continue).
This guide will show you how to use your Trezor Model T hardware wallet with BNB Beacon Chain and Binance DEX.
Please follow best security practices when using any hardware wallet to store cryptocurrency.
Please note that the Trezor Model One is not supported yet.
Wallet providers should make use of the WalletConnect Client SDK for their target programming language and OS. There are implementations on GitHub for iOS, Android, React Native, etc.
Since we do not use Ethereum transactions, there are some differences:
Typically sendTransaction is used with Ethereum transaction parameters in WalletConnect dApp integrations. But in BNB Beacon Chain 's case, instead of invoking sendTransaction in the WalletConnect flow, the new sendCustomRequest call is used instead with a method called bnb_sign (see below).
The external wallet provider is responsible for sending back the signature and public key of the transaction but should not broadcast the transaction itself. We have instead defined a custom result format in the form of stringified JSON containing the signature and public key. The reason for this is that the wallet app probably does not have access to the complete serialized binary form of the transaction (as this requires Amino encoding).
The web wallet will send back a second custom call (after bnb_sign) called bnb_tx_confirmation, which contains the boolean result of the transaction build/broadcast and any error message encountered by the web wallet during broadcasting. In a complete implementation, this confirmation callback should be responded to with a call to approveRequest.
BSC and BC work together to ensure that one token can circulate in both formats with confirmed total supply and be used in different use cases. Token Binding can happen at any time after BEP2/BEP8 and BEP20 are ready. The token owners of either BEP2/BEP8 or BEP20 only need to complete the Binding process when a cross-chain feature is necessary.
The total supply of the ABC-A64 token is 100 million. The above bind transfer will transfer 60 million to a pure-code-controlled address. And then there are 40 million flowable tokens in BC. According to our bind mechanism, we have to lock 40 million token to TokenManager contract and leave 60 million flowable token on BSC. Thus the sum of flowable tokens on both chains is 100 million. Please remember that the amounts I mentioned above don’t include decimals.
In myetherwallet, call the approve of the BEP20 to grant a 40 million allowance to TokenManager contract. The spender value should be 0x0000000000000000000000000000000000001008, and the amount value should be 4e25. The transaction sender should be the BEP20 owner.
Approve Bind
In myetherwallet, call approveBind in TokenManager contract with the latest ABI to approve the bind request from the BEP20 owner address.
The value here should be no less than miniRelayFee/1e18. The initial miniRelayFee is 1e16. So miniRelayFee/1e18 equals to 0.01. Besides, miniRelayFee can be changed by on-chain governance
Confirm bind result on BC
Wait for about 20 seconds and execute this command:
## mainnet bnbcli token info --symbol ABC-A64 --trust-node --node https://dataseed1.bnbchain.org:443 ## testnet tbnbcli token info --symbol ABC-A64 --trust-node --node https://data-seed-pre-0-s1.bnbchain.org:443
Suppose you have 20 million on your treasure, you decide to lock some tokens via the bind tx:
Send bind transfer on BNB Chain and specify the 20 million as the lock amount.
Your BEP20 has 100 million supplies, you need to run the approve to grant allowance to the tokenHub contract, then you run approveBind, along these step, you don't have to specify how much exactly you need to transfer to the tokenHub contract, it will figure it out (here actually it is 80 million), as long as you approve it with enough amount.
If your approveBind runs successfully, the bind is done. Your 20 million treasures actually will be on your owner address on BSC, and this is your CHOICE.
After your bind, you can spend your 20 million whatever you want (including transferring back to BC), and for other holders of your token on BC, they can transfer their token to BSC at their own choice without your help or your permission.
Suppose you choose not to touch your 20 million in treasure at all:
When you have 20 million on your treasure, you can choose to lock ZERO when you run the bind tx.
Suppose Your BEP20 has 100 million supplies, you need to run the approve to grant 100 million allowance to the tokenHub contract, then you run approveBind.
If your approveBind runs successfully, the bind is done. Your 20 million treasures stay at BC in your treasure address, nothing happens to it, and this is your CHOICE. Meanwhile, on BSC, no one has any BEP20 tokens, except the tokenHub. However, because the bind is done, ANYONE, including yourself, can get BEP20 whenever they want by a simple cross-chain transfer.
Binance Extension Wallet is a Crypto Wallet for BNB Beacon Chain and BNB Smart Chain. You can send and receive funds on both BNB Beacon Chain and BNB Smart Chain as well as perform cross-chain transfers between both of BNB Chain’s blockchains.
In the future, Binance Extension Wallet will add support for Ethereum blockchain and enable access for distributed applications, or "Dapps" in your browser!
It’s supported in Firefox and Chrome browsers.
!!! Tip
Firefox users are more likely to access the latest version timely
Through the maintenance release v1.2.12 4, Boot Nodes were introduced on the BSC mainnet. BSC Boot Nodes are similar to Ethereum Boot Nodes, refer here for more details. The main benefit of Boot Nodes is that it would be easier for user to connect to the BSC network. Users would no longer need to setup the StaticNodes in config.toml, just leave it empty and make sure delete the BootstrapNodes field in config.toml.
Previously, BSC provides a list of StaticNodes for users to connect to the network, they are working as a full node and also serving the P2P discovery protocol. New BSC nodes connect to the BSC network through these StaticNodes. It works, but is not quite stable, since they could have very heavy workload.
These static nodes could be stopped and replaced by Boot Nodes in the future. And the StaticNodes list provided before could no longer be available. Like the list provided in v1.2.11 5:
If you are using BSC release before v1.2.12, you can also try BootNodes without upgrading to v1.2.12, you can just set up the BootstrapNodes field in your config.toml and restart. The six BootstrapNodes items listed below can be used directly, they are the current default BootstrapNodes in v1.2.12:
If you are using BSC release v1.2.12 or later, you no longer need to setup the BootstrapNodes field, but you can not just leave it empty, make sure you delete it from config.toml. It would be preferred to delete it and use the default value in case there could be any update to the boot node list in the future. The config.toml would look like as follow:
Boot nodes are super-lightweight nodes, they can be ran by a very cheap device, like: 2 cores, 2GB memory, 20GB disk. \
If you want to support the BSC ecosystem by providing new boot nodes, you can follow this guide to do it.
Since boot nodes have been introduced recently, if you get any problem in using it, please let us know. You may just create new issue in BSC GitHub repo.
ChainIDE is a chain agnostic, cloud-based IDE for creating decentralized applications. It enhances the development cycle through pre-configured plugins that save users' time and effort. This is a beginner guide on creating a simple smart contract and deploying it to the BNB Smart Chain. If you have any questions, feel free to ask them in the ChainIDE Discord.
When deploying a smart contract to a blockchain or when making a transaction to a deployed smart contract, a gas fee must be paid, and for that, we need to use a crypto wallet which can be Binance Wallet or MetaMask. If you want to use Binance Wallet, click here to get Binance Wallet and if you want to continue with MetaMask Wallet, click here to install MetaMask.
Adding BNB Smart Chain Test Network to MetaMask Wallet
Visit ChainIDE, create a project, and click on the "unconnected button" in the upper right corner, select the "Injected Web3 Provider" button, and then click the "MetaMask" to connect to the MetaMask wallet ("BNB Chain Mainnet" is the main network, and "BNB Chain Testnet" is the test network, click on the "BNB Chain Testnet" and it will be added to your MetaMask wallet.
Enabling the BNB Smart Chain Test Network to Binance Wallet
If you want to continue with Binance Wallet, install Binance Wallet, and After installing Binance Wallet, you need to enable "Show Test Networks" and switch to the "BNB Smart Chain Test Network".
Once BNB Smart Chain Test Network has been added to MetaMask, navigate to the BNB Smart Chain Faucet to receive test tokens. Tokens are needed to pay for gas fees to deploy and interact with the smart contract. On the faucet page, paste your MetaMask wallet address. Then, click submit and the faucet will send you some test BNBs.
You need to write down all the required functions that you want to implement in your storage smart contract. A general storage smart contract has the following functions:
Store(): store value in variables
retrieve(): returns the stored value
The ChainIDE team has prepared a simple storage smart contract that includes all the required functions; you may use this built-in template and add/delete functions according to your requirements.
After you have completed your smart contract, it is time to compile it. To compile, navigate to the "Compile", module, choose an appropriate compiler version according to your source code, and press the "Compile" button. An ABI and bytecode for the source code generate upon successful compilation. If there are some errors in your source code, they will be displayed under the output panel in the "Logger module". You may need to carefully read the error, resolve it accordingly and compile the contract again.
Note down the compiler version and the license for your source code as it would be needed when you verify your smart contract on the BNB Smart Chain Test Network.
After successful compilation, it's time to deploy your compiled storage smart contract to the BNB Smart Chain Test Network. For that, you need to have a MetaMask installed, the BNB Smart Chain Test Network added to your wallet, and some testnet tokens to pay for the transaction fee.
Navigate to the "Deploy & Interaction" module and choose the smart contract that you want to deploy among the compiled smart contracts and click the "deploy" button. For this tutorial, the Storage smart contract will be deployed.
To verify a smart contract that imports other smart contracts, we need to create a flattened file, a flattened file including all the source code of imported contracts in a single file. To create a flattened file, you need to add a "Flattener" plug-in.
Once the Flatterner plug-in is activated, you'll be able to access it as a separate module as shown in the figure below. Choose the compiled file, and click on the flatten button to create a flattened file, once the flattened file is created, it will be automatically copied to the clipboard, you may paste it to a file and save it for later usage.
If you want to save the flattened file, click the save button, and a flattened file will be saved in the current repository.
The saved flattened file can be accessed under the explorer module.
To verify a smart contract, you need to visit BNB Smart Chain Explorer and search for the deployed smart contract using the contract address.
Click on the "verify and publish" link shown under the contract section.
Once you click on the verify and publish link, you will be asked for the following:
Contract Address: The address of a deployed smart contract that you want to verify
Compiler Type: Either you want to verify a single file or multiple files
Compiler Version: The compiler version that you used to compile the smart contract
License: Open-source license type that you used for your source code
After that, you need to paste the flattened file that you created in step 5, and your smart contract will be verified.
If there are no issues with your smart contract, it would be verified, and you'll be able to see an image similar to the one that is shown below.
Congratulations, you have successfully deployed your smart contract to the blockchain and verified it, now it's time to interact with your deployed smart contract.
After successful deployment and verification. All the functions in the deployed smart contract can be seen in the "INTERACT" panel. In our scenario, we have two functions, Store() that is used to store the value to the blockchain, and Retrieve() to retrieve stored data from the blockchain.
-
+
diff --git a/docs/circulation-model.html b/docs/circulation-model.html
index b8e8a096b3..782178dae1 100644
--- a/docs/circulation-model.html
+++ b/docs/circulation-model.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
Peg Account is a pure-code-controlled account that no one has the right to access to the account.
For BC, the Peg Account is bnb1v8vkkymvhe2sf7gd2092ujc6hweta38xadu2pj. (tbnb1v8vkkymvhe2sf7gd2092ujc6hweta38xnc4wpr for testnet)
Token Binding can happen at any time after BEP2/BEP8 and BEP20 are ready. The token owners of either BEP2/BEP8 or BEP20 only need to complete the Binding process when a cross-chain feature is necessary.
Binding process helps to build the relationship between the two tokens on BC and BSC. It will ensure that the two tokens share the same symbol and same total supply. The most important part is that it will reallocate the circulation on both chains to ensure the total circulation equals the total supply.
Let's walk through an example:
Bob issues BTC on BC with a total supply of 10, and he sends Alice 2 BTC.
Bob issues BTC on BSC with a total supply of 10, and he sends Tom 1 BTC.
Now Bob wants BTC to flow between BC and BSC, but the total circulation on BC and BSC is 20=10+10 BTC which is not correct, so he decided to bind these two tokens. He made a decision that 8 BTC circulation on BC and 2 BTC circulation on BSC, then he started a bind transaction.
The BC execution engine will:
Transfer 2 BTC from Bob's account to Peg Account.
Emit a cross-chain event.
For now, on BC, Bob has 6 BTC, Alice has 2 BTC, 2 BTC is locked in Peg Account, circulation on BC is 8 BTC.
The Relayer watches the cross-chain event on BC, and sends a transaction to TokenManager contract on BSC.
Then Bob invokes the BTC contract on BSC to approve TokenManager to spend 8 BTC of his account.
After that Bob approves the bind request by invoking TokenManager.
The TokenManager will transfer 8 BTC from Bob's account to Peg Account.
For now, on BSC, Bob has 1 BTC, Tom has 1 BTC, 8 BTC is locked in Peg Account, circulation on BSC is 2 BTC.
The binding process ends here, and the total circulation on both chains is 10 BTC which equals to its total supply.
When a user mints a token on the native chain, but does not mint it on the parallel chain, it may cause an issue that users can not cross transfer all tokens from the native chain to the parallel chain.
Let's walk through an example:
The circulation on BC is 5 BTC, and the locked token is 5 BTC.
The circulation on BSC is 5 BTC, and the locked token is 5 BTC.
User mint 2 BTC on BC.
It will fail if the user tries to transfer 7 BTC from BC to BSC, because the balance of Peg Account on BSC is 5 BTC and can’t afford to unlock 7 BTC.
The best practice for mint is:
Mint token on the native chain.
Mint token on the parallel chain.
Transfer the mint token to Peg Account on the parallel chain.
How to Contribute to BNB Chain Documentations Project
Your contributions to the BNB Chain will help build a fast and secure decentralized digital asset exchange.
We want to make it as easy as possible to contribute changes that help the BNB Chain grow and thrive. There are a few guidelines that we ask contributors to follow so that we can merge your changes quickly.
Steps for Contributing on GitHub
Make sure you have a GitHub account.
Create a GitHub issue for your contribution, assuming one does not already exist.
Clearly describe the issue including steps to reproduce if it is a bug.
Fork the repository on GitHub.
Minor Changes
Documentation
For small changes to comments and documentation, it is not always necessary to create a new GitHub issue. In this case, it is appropriate to start the first line of a commit with 'doc' instead of an issue number.
Finding things to work on
The first place to start is always looking over the current GitHub issues for the project you are interested in contributing to. Issues marked with [help wanted][help-wanted] are usually pretty self-contained and a good place to get started.
Of course, feel free to create a new issue if you think something needs to be added or fixed.
Making Changes
Create a topic branch from where you want to base your work. This is usually the master branch. Please avoid working directly on the master branch.
Make sure you have added the necessary tests for your changes and make sure all tests pass.
Submitting Changes
Submit a pull request to the docs repository in the BNB Chain organization.
Include a descriptive [commit message][commit-msg].
Changes contributed via pull request should focus on a single issue at a time.
Rebase your local changes against the master branch. Resolve any conflicts that arise.
The total cost of transfer from BC to BSC is composed of 2 parts:
Fee for executing bridge transfer-out transaction is 0.004BNB, pay validators on BNB Beacon Chain
Fee for BSC-relayers 0.004BNB. it will cover the fees of calling TokenHub Contract on BSC.
The total cost of transfer from BSC to BC is composed of 2 parts:
Fee for Oracle-relayers 0.004BNB, pay for BSC relayers
Call TokenHub Contract: You need to pay BNB for calling smart-contract on BSC, this transaction is metered by gas, which is a global parameter. At the moment, you need to pay about 0.0005BNB ~ 0.0015BNB.
BSC relayer monitors cross chain packages on BNB Beacon Chain, builds and broadcasts transactions to BSC to deliver these packages, which is the key of cross chain communication from BNB Beacon Chain to BSC.
Oracle Relayer watches the state change of BNB Smart Chain. Once it catches Cross-Chain Communication Events, it will submit to vote for the requests. After Oracle Relayers from ⅔ of the voting power of BC validators vote for the changes, the cross-chain actions will be performed. Only validators of BNB Beacon Chain are eligible to run Oracle relayers.
In blockchain network, an oracle refers to the element that connects smart contracts with data from the outside world. In the network of BNB Smart Chain, the execution of the transaction wil emit Events, and such events can be packaged and relayed onto BC. In this way, BC will get updates about changes of BSC.
Develop Full Stack dApp on BNB Smart Chain in 5 minutes
Designed for anyone wanting to learn blockchain development, this tutorial provides a step-by-step guide on how to develop a full-stack Hello World Smart dApp that is used for storing and retrieving data from the BSC blockchain. The technology stack used in this tutorial includes Solidity, Truffle, Ganache, Web3.js, and Node js. We also cover how to deploy smart contracts on the BNB Smart Chain Testnet.
Truffle Framework: set of tools for smart contract development, testing, and asset pipelining for any blockchain that uses the Ethereum Virtual Machine (EVM).
Ganache: available as both desktop application and CLI, it is a personal blockchain that can be used for local blockchain development.
Solidity: one of the most popular object-oriented high-level smart contract programming languages. For more details on Solidity, refer here.
MetaMask Wallet Browser Extension: we recommend using the Metamask Chrome extension. It is a web wallet that allows connecting the chrome browser to any valid blockchain network.
Node JS: this is used for UI or Front end development.
Web3.js: JavaScript library that allows communication with the EVM-based blockchains. This is the magic tool that turns our web application into a blockchain-enabled application.
Compile Smart Contracts. Use the commandtrufflecompile to compile your smart contracts.
Migrate Smart Contracts. Use the following command to deploy/migrate your smart contracts onto the BSC Testnet truffle migrate --reset --network bscTestnet
Unit Test Your Smart Contracts.
Open a terminal and move into the root directory of the project. Run the ganache-cli using the command ganache-cli.
2. Make sure that the terminal is not closed, i.e., ganache-cli is running in the background. This is important because testing is done on the local network. 3. From the root directory of the project, in a new terminal, run the command ```truffle test``` to run the tests.
Create the build. Run the command npm run build to create the build files for your web application using the webpack library.
Run the application. Run the command npm run dev to start the application on the localhost. Note:before running the application make sure nothing is running on localhost:3000
Navigate to localhost:3000 on Chrome Browser to see the dApp in action
Make sure that your MetaMask wallet is correctly installed and configured to connect to BSC Testnet. Refer to this guide for details. To use the dApp successfully make sure that your MetaMask wallet is connected to the site.
Click on Greet Button to display a message, by default it's Hello, World.
Enter a name in the input field, Click Save Name button to save the name.
Confirm the transaction when MetaMask notification pops up.
Upon successful transaction confirmation you will see the Save successful message.
Click on the Greet Button to display a message along with the last name saved with the current account.
In this post, we developed both the backend and front-end for a decentralized application developed in Node.js that can be used for interacting with smart contracts deployed on the BSC Testnet. The tech stack includes Web3.js, Truffle, Ganache-cli, Node js, MetaMask, and jQuery. Check out our GitHub for more tutorials on how to develop on BSC. If you have any questions or are stuck, reach out to us on our Discord Channel.
Designed for anyone wanting to learn development on the BNB Smart Chain, this tutorial provides a step-by-step guide on how to use web3.js library along with Nodereal API to fetch transaction details from the BNB Smart Chain blockchain for the given transaction hash. The technology stack used in this tutorial includes Web3.js, Nodereal MegaNode, and http-server.
Clone the BNBChain-Tutorial repository: git clone https://github.com/bnb-chain/bnb-chain-tutorial.git
Change the current directory: cd "02-BSC-Block-Explorer"
Install all the dependencies (node modules): npm install
Before running the application, make sure that you have included the HTTP link for the Nodereal Meganode API in the index.html as shown in the figure below.
For this project, we have used the BSC Testnet public API key, as shown in the figure below. For a complete list of Nodereal Meganode Public API keys, refer here.
Run the application by using the command http-server from the project directory.
Open your web browser and navigate to any of the ports indicated by the http-server command.
Since we have used the HTTP reference of Nodereal’s Meganode API for BSC testnet, open BSCscan for Testnet, and copy the transaction hash of any transaction of your choice.
Paste this transaction hash into the input field in our block explorer.
Click on the Fetch Details button to fetch details of this transaction.
You can also display other details from the received transaction receipt by changing the code block shown in the figure below as we have displayed the minimum.
The received transaction receipt has several fields as shown in the figure below.
In this tutorial, we developed a dapp that has both backend and front-end integration that uses Web3.js library that can be used for fetching details of transactions on the BSC testnet by given a transaction hash. The tech stack includes Web3.js, Nodereal MegaNode, and http-server. Check out our GitHub for more tutorials on how to develop on BSC. If you have any questions or are stuck, reach out to us on our Discord Channel.
In order to decentralize the network further, more validators should be introduced. Besides increasing the anti-censorship, it always increases the robustness and availability of the network. BSC should survive even if more than half of the validator set were censored or taken down in a hostile way.
Meanwhile BSC has 32 active validators and many inactive validators. The inactive validators have no reward so the incentive for the runner to ensure the node quality and the delegation from the BNB holders are not enough.
BSC will introduce more validators, e.g. another 23 inactive validators, into the validator set as backups, which will be called “Candidates”.
Candidates will produce blocks and charge gas fees in BSC mainnet, but in a much less chance than the official validator set of 32 elected. The unavailable candidates will be slashed as well though in a smaller size. A decent motivation is expected to be maintained so that the candidate validators are willing to ensure the quality and help secure BSC.
In an extreme case, if a majority of the active 32 validators get attacked and offline, Candidate Validators can report to BNB Beacon Chain about the stale blocking, resume it and eventually propose a re-election of active validator set.
Due to the design of ‘Parlia’ consensus, the absence of the validator, even if it is due to scheduled maintenance, will cause instability and capacity of BSC due to the extra waiting time and chain reorganization.
Here a “Temporary maintenance” mode should be introduced, which is supposed to last a few minutes to half an hour. The validator can claim to the network about its planned maintenance. Its seat will be temporarily dropped from the block producing rotation, though it will still be slashed.
-
+
diff --git a/docs/dev-outlook/scaling.html b/docs/dev-outlook/scaling.html
index d2ed1f90d3..a1194fe3cc 100644
--- a/docs/dev-outlook/scaling.html
+++ b/docs/dev-outlook/scaling.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
The excluded accounts and contracts will only be presented as intermediate node of MPT, so that they can still be used to calculate the new MPT;
Ephemeral Client can work in a similar way as a full node, in the sense that it will execute all the transactions and verify all the data. It should load the excluded data during the execution from another full node or the Portal Network, or even pre-load the excluded data based on the transactions in the mempool.
Apparently sometimes the ephemeral clients may run slower than a full node, but it is a trade-off to make it much easier to run, and run faster.
Deriving from this concept, it is natural to consider separating the hot data from the cold data, which has been a classic technique used in the computing industry. If the EVM blockchain is considered as a “world computer”, the memory of the node should be the registers, while the storage can be the RAM (yes, with MPT used in a similar way as ECC in RAM). RAM has never been big enough, so that the data has to be swapped out onto local or/and remote disks. The EVM blockchain needs such “local or/and remote disks” too.
This is not an easy problem to solve:
1. Data location is not part of the consensus. It may be easy to mark the data as “swap-out” or “offline” and reach the consensus, but the more important issue is to reach the implicit consensus that “my proposed block has some transactions that swap in data from the offline mode”. The short blocking time may not be enough from other validators to respond. 2. Some contracts may have a very big storage, which is a great help to swap it out, but very challenging to swap it in as a whole back to “online”.
One potential solution may be:
1. Swap the data out by the unit of account and contract when they have not been changed for a long time, and put this as an transaction to get consensus; 2. Swap in data by a deterministic set size, which may not be as large as the whole contract data. 3. The swapped-in data can be passed in as extra calldata on the block, and the other validators can execute the transactions and verify the data as a “stateless client” if they cannot load the data in time. 4. The transaction senders will pay extra gas to run any transaction that requires swapping in the data.
A new data layer may emerge due to the requirement to store the cold data.
Running transactions in parallel for Ethereum has been studied for several years. Solana goes with a native design to enable this as much as possible so that it can take advantage of the powerful GPU.
Based on the analytics of BSC data, the CPU has not been the No.1 bottleneck but the storage is. Even though the EVM parallelization will take better usage of multiple cores of the modern CPUs, the primary goal is to increase the parallelism of storage operation to maximize the SSD usage (even the SATA ones).
In order to maintain backwards compatibility and not change the account structures as Solana does, the most straightforward method is heuristic based, i.e. try-and-rerun-the-failed. The full nodes can do some preprocessing to categorize the transactions in the blocks and mempool into different concurrent workers before actually running them. A lower level instrument monitor will be planted at the storage level, if the race condition is detected, and relevant transactions will be put back into the main worker to rerun in order to generate the correct state. Block producers may even place some hints for others to run the blocks in the most efficient way via the P2P network, though the hint itself is not part of the block.
Besides the parallelization within one block, BSC inherits one limit from Ethereum that the block proposer has to wait until it applies all the previous blocks before it can execute any transactions in its block to propose at its turn. If the previous block proposers send the block late, or the blocks are delayed due to slow network etc, the proposer may not have enough time to execute enough transactions into their blocks and have to propose an empty block or even miss its turn. Tendermint is a good example that solves the above issue. The block proposer on Tendermint network only needs to assemble the block without executing them. How to control the gas used within one block without executing transactions is a difficult topic on the EVM network.
How to run transactions in parallel even among different blocks will be very rewarding here, but it will be very difficult as well.
Using JIT compilation in EVM was proposed and discussed in the early days of Ethereum. When popular dApps dominate the network, such as OpenSea and Uniswap on Ethereum, and PancakeSwap on BSC, and one GameFi dApp had a few million transactions per day, the idea is fascinating that these applications can be compiled into native instructions and able to run faster. This benefits even the compilation is not done “just-in-time” but offline.
However, this is a very challenging feature because it touches the very low level of EVM and can be quite prone to error and security issues. Here is just a placeholder for the talented developers to conquer in the later stage.
Besides the limitation of the block gas limit cap, the other major factor that can impact BSC capacity is the rate of fork. Fork and re-organization of the blockchain can be very costly for both validators and fullnode.
Although BSC is designed to produce blocks every 3 seconds, it is recommended to wait until more than half of the validator set has produced new blocks on the block before the block can be confirmed in a probabilistic manner. This will cost at least 3x11 = 33 seconds after the block is visible on the network.
As the validator set is well known every 24 hours, BSC can get a faster consensus on the longest chain based on the “attestation” from more than a certain percentage of the validator set considering it is the longest chain.
Smart contracts development with BSC enables you to build your smart contracts for any use, including cryptocurrency exchanges, smart contract-based dApps, Decentralized Finance, and more.
Smart contracts are programming logic that are executed automatically on when a certain condition(s) are met. In BSC, smart contracts can be written in Solidity programming language.
Multiple IDEs and libraries can be used for developing and deploying smart contracts.
Remix IDE: powerful open source tool that helps you write Solidity contracts straight from the browser. It is written in JavaScript and supports both usage in the browser, in the browser but run locally and in a desktop version. Remix IDE has modules for testing, debugging and deploying of smart contracts and much more.
Truffle: development tool that allows users to compile, test, debug and deploy smart contracts.
Web3JS: collection of libraries that allow you to interact with a local or remote ethereum node using HTTP, IPC or WebSocket.
DApp developers who want to leverage DIA oracles can access the published data on BNB Smart Chain. DIA offers cryptocurrency and data about traditional financial assets.
All asset prices are determined in USD.
Where appliccable, the oracle also provides information on circulating supply and the timestamp of data collection.
The query in the smart contract is realized with the symbol of the asset.
Decentralized storage system enable users to store their data in a peer-to-peer distributed network which consists of operators across different locations. Comparing with centralized storage, it offers more control, privacy as well as security over the user's own data. Further more, decentralized storage is more resilient since there is no single point of failure of the storage.
Following is the list of decentralized Storage protocols or networks that you can used with BNB Chain.
IPFS: The InterPlanetary File System (IPFS) is a distributed file system allows users to store and access verifiable and content-addressable data in a peer-to-peer network.. It is a distributed protocol designed to preserve and grow humanity's knowledge by making the web upgradeable, resilient and more open.
Filecoin: Filecoin is a peer-to-peer network that stores files, with built-in economic incentives to ensure files are stored reliably over time. Filecoin combines the benefits of storage on IPFS with blockchain-powered verifiability and persistency. The network offers robust and resilient distributed storage at massively lower cost compared to current centralized alternatives.
Amino supports JSON encoding natively, which is the same as other usual json marshalers. Except that it can add one more type info for registered type, as shown below.
Binary encoding is a variant of Google's protobuf. The bytes are laid out in the below sequence:
a varint encoded integer - it contains the length of the encoded bytes for the object, which is displayed as SIZE-OF-ENCODED in the below structs. Please note that it contains the length of encoded bytes and also the type prefix (below), but not itself, e.g. if the encoded msg is 20 bytes, then the length would be 20 + 4 = 24, while 4 is used for the type prefix bytes.
an object type prefix of 4-8 bytes - For different type of objects, there will be different type prefixes, and they are displayed as in the specific objects below (data structures).
a binary encoded object - the encoding is mostly the same as protocol buffer encoding mechanism, except the embedded fields of complex type:
to encode data field of some specific types, an object type prefix for the field will be added ahead of the real encoding.
repeated (array) Encoding - it is the same as google protocol buffer, while encoding of the object/struct may contain the type prefix as shown below.
Below are the data types that can be sent to BNB Beacon Chain as requests, and their encoding layout. To simplify the presentation, we will use a variant of Google protocol buffer proto3 language to illustrate how the data fields are organized. Except the all-capitalized fields, other fields will use the default proto3 encoding logic.
Transactions are each wrapped in the below "Standard Transaction": structure:
// please note the field name is the JSON name. message StdTx { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding, please note this includes both the below type prefix (4 bytes) and the all encoding bytes 0xF0625DEE// hardcoded, object type prefix in 4 bytes repeated Msg msgs // array of size 1, containing the transaction message, which are one of the transaction types below. please check the above "Array Encoding" repeated StdSignature signatures // array of size 1, containing the standard signature structure of the transaction sender string memo // a short sentence of remark for the transaction. Please only `Transfer` transaction allows 'memo' input, and other transactions with non-empty `Memo` will be rejected. int64 source // an identifier for tools triggerring this transaction, set to zero if unwilling to disclose. bytes data // byte array, reserved for future use }
A transaction signature is not formed from the Amino-encoded transaction bytes themselves. Rather, a canonical representation of the transaction is generated in JSON format for signing.
This would allow for clients to sign a transaction off-chain, for example, with a hardware HSM device like a Ledger, or within a micro-service in an algorithmic trading system. An external system will not have to understand Amino encoding to be able to approve of the transaction's content and produce the signed JSON string.
The canonical bytes for signing are generated from the StdSignBytes method. It produces a JSON string similar to the format below (formatted for clarity):
This JSON string, with all whitespace removed and keys sorted in alphabetical order, is signed with the private key of the sender. This signature is then attached to the StdTx structure described in the above section. Please note that the transaction broadcasted to the blockchain is not JSON - the JSON is merely used as a canonical representation to generate the signature.
The next section describes how the generated signature is attached to a transaction.
The sender's signature is stored in the Standard Transaction data via a Standard Signature, as shown below. This structure is included in the StdTx (see above).
Please note that StdSignature itself doesn't have type prefix, while the PubKey does.
message StdSignature { uint64 SIZE-OF-ENCODED // varint encoded length of the structure after encoding // please note there is no type prefix for StdSignature message PubKey { 0xEB5AE987// hardcoded, object type prefix in 4 bytes uint64 SIZE-OF-ENCODED // varint encoded length of the bytes below bytes // no name or field id, just encode the bytes } PubKey pub_key // public key bytes of the signer address bytes signature // signature bytes, please check the chain access section for signature generation int64 account_number // another identifier of signer, which can be read from chain by account REST API or RPC int64 sequence // sequence number for the next transaction of the client, which can be read from the chain by account REST API or RPC. Please check the chain access section for details. }
Messages represent the individual operations possible on BNB Beacon Chain, and these can be inserted into the StdTx.msgs field. Message types are otherwise known as "transaction types", and these terms are used interchangebly in this document and in our technical documentation. So far every StdTx transaction "container" can only contain one "message".
Freeze transaction will move the amount of the tokens into a frozen state, in which they cannot be used for transfers or sending new orders.
// please note the field name is the JSON name. message TokenFreeze { 0xE774B32D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to freeze }
Unfreeze will reversely turn the amount of frozen tokens back to free state.
// please note the field name is the JSON name. message TokenUnfreeze { 0x6515FF0D// hardcoded, object type prefix in 4 bytes bytes from // owner address string symbol // token symbol, in full name with "-" suffix int64 amount // amount of tokens to unfreeze }
// please note the field name is the JSON name. message Vote { 0xA1CADD36// hardcoded, object type prefix in 4 bytes int64 proposal_id // ID of the proposal bytes voter // address of the voter uint64 option // option from OptionSet chosen by the voter }
Below are options for option:
OptionYes =0x01// yes OptionAbstain =0x02// abstain OptionNo =0x03// no OptionNoWithVeto =0x04// no with veto
message IssueTokenValue { 0x17EFAB80// hardcoded, object type prefix in 4 bytes bytes from // issuer's address string name // token name string symbol // token symbol string total_supply // total supply bool mintable // is mintable }
Mint is used to increase the total supply of a token.
message Mint { 0x467E0829// hardcoded, object type prefix in 4 bytes bytes from // sender's address string symbol string// token symbol int64 amount // increase amount }
Submit proposal is used to create a proposal for validators about adding trading pairs
message Submit{ 0xB42D614E// hardcoded, object type prefix in 4 bytes string title // Title of the proposal string description // Description of the proposal byte proposal_type // Type of proposal. Initial set {PlainTextProposal, SoftwareUpgradeProposal,ListTradingPair, FixedFeeParams} bytes proposer // Address of the proposer message Coin { string denom int64 amount } int64 VotingPeriod // Length of the voting period (s) }
Deposit is used to increase the total deposit of a proposal.
message Deposit{ 0xA18A56E5// hardcoded, object type prefix in 4 bytes int64 ProposalID // ID of the proposal bytes Depositer // Address of the depositer message Coin { string denom int64 amount } }
You can relock tokens on your own account after a certain period of time.
message Timerelock{ 0x504711DA// hardcoded, object type prefix in 4 bytes bytes from // sender's address int64 Id // lock time id string description // Description of the lock message Coin { string denom int64 amount } repeated Coin amount int64 lock_time // lock time }
Claim Hash Timer Locked Transfer is to claim the locked asset by showing the random number value that matches the hash. Each HTLT locked asset is guaranteed to be release once.
message ClaimHTLTMsg{ 0xC1665300// hardcoded, object type prefix in 4 bytes bytes from // sender's address bytes swap_id bytes random_number }
Wallets are a bit of a shift in thinking. Financial freedom and the ability to access and use funds anywhere comes with a bit of responsibility – there’s no customer support in crypto.
Centralized exchanges will link your wallet to a username and password that you can recover in a traditional way. Just remember you’re trusting that exchange with custody over your funds. If that company is attacked or folds, your funds are at risk.
If you use a web wallet, bookmark the site to protect yourself against phishing scams.
Remember transactions can’t be reversed and wallets can’t be easily recovered so take care.
Tokens not visible after withdrawing from Binance
Many users who interact with a centralized exchange like Binance eventually want to withdraw to a wallet that they fully control, like MetaMask. So once you've used their withdraw form, what could be scarier than not seeing your tokens?
First, you'll need to use the MetaMask add Custom Network feature to add the BNB Beacon Chain or BNB Smart Chain's RPC URLs endpoints to your MetaMask.
Once you've added the BNB Beacon Chain or the BNB Smart Chain to your MetaMask, you will be able to select different networks to view the assets (you may need to add Custom Tokens too) held by your selected account on that network.
if you try to send tokens without having any BNB in your account you will be told you have insufficient funds. This means you do not have enough BNB in your account to cover the cost of gas. Each transaction (including token and contract transactions) require gas and that gas is paid in BNB. You can think of this like a transaction fee.
You can remedy this by sending 0.001 BNB to that account in order to be able to make the transaction.
A standard Ether transfer TX will be 21000 gas & a gas price of 15 Gwei.
With tokens, the amount of gas is typically gas, so the total TX fee increases to 0.002 BNB - 0.003 BNB.
When dealing with cryptocurrencies or crypto assets like BNB or BUSD, it is important to always be aware of and have your private keys, seed phrases and passwords backed up in case the unexpected occurs.
When you create a new Binance Extension Wallet account, you are given your 12 word seed phrase is the most important bit of information for you to record and keep safe when managing your extension account.
You can write your seed phrase down on a piece of paper, store it on a flash drive or we also make it optional to download a file containing this information.
Backing Up After You Install Binance Extension Wallet
If for some reason you forgot to record your 12 word seed phrase or you lost the original copy, you can reveal your seed phrase so you can back it up again.
Select Dropdown Menu (on top-right corner) --> Manage Accounts
When resetting your password for your Binance Extension wallet, you will need your 12 or 24 word seed phrase. If you do not already have your seed phrase saved someplace safe, please make sure to read How to Reveal Your Seed Phrase.
Before trying these steps, confirm that you have your seed phrase with you as you will not be able to reset your password otherwise and will risk becoming locked out of your wallet.
If your wallet is currently unlocked, please lock your wallet first.
Click Import Import seed phrase
Enter your seed phrase in the "Seed Phrase" text box
Enter your new password
Retype your password to confirm it was written correctly
!!! Note : By default each wallet/network will shows the the main token they support. You will need to add additional token to your list.
For Binance Extension Wallet users
You'll need to switch to BNB Beacon Chain Mainnet (BC) mainnet or BNB Smart Chain (BSC) mainnet
Once you've added the asset to your wallet, you will be able to select different networks to view the assets held by your selected account on that network.
For Metamask wallet users
You'll need to add BNB Smart Chain (BSC) mainnet network, refer here for more details.
A standard Ether transfer TX will be 21000 gas & a gas price of 5 GWEI. With tokens, the amount of gas is typically gas, so the total TX fee increases to 0.0005 BNB - 0.0007 BNB.
if you try to send tokens without having any BNB in your account you will be told you have insufficient funds. This means you do not have enough BNB in your account to cover the cost of gas. Each transaction (including token and contract transactions) require gas and that gas is paid in BNB. You can think of this like a transaction fee.
You can remedy this by sending 0.001 BNB to that account in order to be able to make the transaction.
How to Recover Crypto Transferred to the Wrong Network on Binance?
It is crucial that you always have the latest wallet version installed. If you know that a new version of an extension is out but Chrome hasn’t updated it, here’s how to do it manually.
Start Google Chrome.
Click the vertical ellipsis icon on the browser toolbar.
Click on "Extensions" -> "Manage Extensions".
Click the Developer Mode button on the right side of the header
From there, you should see the “Update” button below the search bar. Click on it to update the extensions.
It is crucial that you have the latest version installed.
Click the menu button, click "Add-ons and Themes" and select "Extensions".
Click the gear icon in the upper-right area of the Extensions panel.
Choose one of the options below:
Check for Updates: Allows you to check for any updates to your add-ons manually. If there is an update available, you have the option to choose to update it now or later.
View Recent Updates: When you click this option, a Recent Updates panel appears on the left, showing your last updated add-ons.
Update Add-ons Automatically: If you want to keep your add-ons up to date, select this option to let them update automatically.
Reset All Add-ons to Update Automatically: If any add-ons have been set to update manually, clicking this option will reset all add-ons to update automatically.
Why are Tokens not visible after withdrawing from Binance?
Many users who interact with a centralized exchange like Binance eventually want to withdraw to a wallet that they fully control, like Binance Extension wallet or MetaMask. So once you've used their withdrawal form, what could be scarier than not seeing your tokens?
First, you'll need to use BNB Beacon Chain Mainnet (BC) mainnet or BNB Smart Chain (BSC) mainnet
Once you've added the asset to your wallet, you will be able to select different networks to view the assets held by your selected account on that network.
Seamless Token Transfer: Transfer tokens (which support BNB Beacon Chain, BNB Smart Chain and Ethereum) between paired Binance.com account and Binance Extension Wallet. Without the trouble of copy/paste address and memo every time
BNB Holding: The BNB positions of your Binance.com account will not change.
This error is caused by the handshake failing between two peers.
Solution
To solve this problem, you need to make sure node_key.json is under $BNCHOME/config and nodes will try to re-connect automatically, so this issue should not persist.
The BNB Beacon Chain has a hardfork upgrade and if you failed to upgrade your fullnode to the latest version, bnbchaind process will stop and even if you restart with the latest version, the following error will appear:
panic: Tendermint state.AppHash does not match AppHash after replay. Got , expected 393887B67F69B19CAB5C48FB87B4966018ABA893FB3FFD241C0A94D2C8668DD2 goroutine 1 [running]: github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.checkAppHash(0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, 0x20, ...) /Users/huangsuyu/go/src/github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus/replay.go:464 +0x213 github.com/bnb-chain/node/vendor/github.com/tendermint/tendermint/consensus.(*Handshaker).ReplayBlocks(0xc000b37980, 0xa, 0x0, 0xc000bd8c56, 0x6, 0xc000b247c0, 0x12, 0x14e7bf9, 0x8592eb, 0xc000b247e0, ...)
To recover from the state conflict error, you need to:
Backup your home directory, (default is ~/.bnbchaind)
Get the height of upgrade, this height will be announced in the upgrade announcement on the forum. For example, if it's announced as 5000 in the forum and run the following command will make your full node recover to the last block before the upgrade, and that is 4999 :
If you do not download the binaries completely, you will see the following message:
./bnbchaind: line 1: version: command not found ./bnbchaind: line 2: oid: command not found /Library/Developer/CommandLineTools/usr/bin/size: 45160816 No such file or directory
Since all the binaries are stored in git lfs, you will see this error is the binary is not complete. Please download the latest binaries from https://github.com/bnb-chain/node/releases.
Once you have your own node running, you can start querying from it. But sometimes you may not be ablt to get the information you want. For example:
curl 'localhost:27147/block?height=10'
The reason is because your node is using statesync to catch up. In this way, it will not store all the history blocks before the snapshot height it got. You can only query blocks after that snapshot height.
To enable query history blocks, you need to use fast-sync
-
+
diff --git a/docs/get-extra-data-from-fullnode.html b/docs/get-extra-data-from-fullnode.html
index 8705ccd7b9..a891cea5e5 100644
--- a/docs/get-extra-data-from-fullnode.html
+++ b/docs/get-extra-data-from-fullnode.html
@@ -9,7 +9,7 @@
-
+
@@ -30,7 +30,7 @@
Then, the full node will save messages that you are interested into Kafka, and you can consume them in your own apps.
The message is encoded based on Avro serialization system.
Their schemas are shown below:
This document serve as a starting point for new users to the BNB Chain ecosystem. General knowledge of cryptocurrency is assumed, and in particular familiarity with the Ethereum ecosystem. If you don't understand something right away, that's OK. Search for an answer online, and if you don't find it, ask on our Discord.
BNB Smart Chain (BSC) is the blockchain component of the BNB Chain ecosystem that is equipped with the smart contract functionality and compatibility with the Ethereum Virtual Machine (EVM) and is used for developing various kinds of decentralized applications. The design goal of BSC was to leave the high throughput of BNB Beacon Chain intact while introducing smart contracts into the BNB Chain ecosystem. Being EVM-compatible, other than easy portability, BSC enjoys support of the rich universe of Ethereum tools and dApps
BNB is the cryptocurrency coin that powers the BNB Chain ecosystem. As one of the world's most popular utility tokens, not only can you trade BNB like any other cryptocurrency, you can also use BNB in a wide range of applications and use cases.
Although initially based on the Ethereum network, the ERC-20 BNB tokens were later swapped with BEP-2 BNB at a 1:1 ratio. The BEP-2 BNB is the native coin of the BNB Beacon Chain, and the mainnet.
In 2020, the BNB Smart Chain (BSC) was launched. BSC is a blockchain network that runs in parallel with the BNB Beacon Chain. This means that BNB can be found in three different forms:
Explore the transaction history, blocks on the chain check different asset types, the distribution of their ownerships, and owners' transactions, etc. via the use of explorers. Refer here for a complete list.
There are data seed nodes in the network which allow users to perform low-level operations like executing ABCI queries, viewing network/consensus state or broadcasting a transaction.
If you run a full node by yourself, you can also use RPC functions. For a list of all the Node RPC services for BNB Beacon Chain refer here and for BNB Smart Chain refer here.
-
+
diff --git a/docs/greenfield/design/architecture.html b/docs/greenfield/design/architecture.html
index 47c7cf71e6..c624c00ac1 100644
--- a/docs/greenfield/design/architecture.html
+++ b/docs/greenfield/design/architecture.html
@@ -9,7 +9,7 @@
-
+
@@ -26,7 +26,7 @@
BSC and integrated with smart contract systems there, such as DeFi, to create new business models.
From the viewpoint of BNB Greenfield dApps, these applications can help users to create, read, and execute data on the BNB Greenfield,
Greenfield SPs, and BSC, and serve a purpose to users' needs.
From the viewpoint of BNB Greenfield Core Infrastructure, they accept requests and observations from the Greenfield dApps on behalf of the users, and also instructions from BSC to operate together for different business scenarios.
From the viewpoint of BSC, they can accept transferred data assets from BNB Greenfield, and provide more business scenarios via smart contracts to new types of Greenfield dApps.
The users can interact with all parts of the trinity for different
purposes directly or/and indirectly.
-
+
diff --git a/docs/greenfield/design/assumptions.html b/docs/greenfield/design/assumptions.html
index 4166e2e4ab..fc71b06ae0 100644
--- a/docs/greenfield/design/assumptions.html
+++ b/docs/greenfield/design/assumptions.html
@@ -9,7 +9,7 @@
-
+
@@ -43,7 +43,7 @@
transparency. This results in the considerable design for cross-chain
between BNB Greenfield and BNB Smart Chain (BSC). This should be the
most important assumption and hopefully close to the truth.
-
+
diff --git a/docs/greenfield/design/data-storage.html b/docs/greenfield/design/data-storage.html
index 45cf0bc581..19cb40295f 100644
--- a/docs/greenfield/design/data-storage.html
+++ b/docs/greenfield/design/data-storage.html
@@ -9,7 +9,7 @@
-
+
@@ -31,7 +31,7 @@
After that, Primary SP computes a data redundancy solution for these segments based on Erasure Coding (EC). Then Primary SP or the users will select a few secondary SPs to store these segment replicas and their EC parity pieces. This data distribution communication will be done via the p2p network and REST
APIs among SPs.
The data redundancy setup is to ensure that even if the primary SP and a few secondary SPs become unavailable at a later time, Greenfield can still recover the full data.
This section of BNB Greenfield documentation describes the general principles and considerations for the design of BNB Greenfield. It covers the architecture and functionality analysis. Although the true model innovation is at the cross-chain with BSC, the unique storage fundamentals are also important to highlight.
1.Simplicity - The design prefers this first principle over the other considerations. Simple solutions are not only easy to implement, run, maintain, and extend, but also friendly to software performance, which is a main goal of the design. For example, high computing-intensive proof, like what Filecoin adopts, is ruled out according to this principle.
2.Upgradable and continuously evolving - Perfect system at one go is not the goal of the design. We expect the whole architecture, different components, and even this whitepaper to evolve and get improved based on the community and market feedbacks and future technology development. The infrastructure should have "just enough" establishment to develop and upgrade as time goes on.
3.Open platform - The biggest lesson learned from the crypto industry and BNB ecosystem is that the community have the most talent and power to build more applications and infrastructure in different self-driven ways. The design should focus on the core platform and technical foundation that provide enough interface, tools, and other facilitation to the developer community to build upon them.
4.Massive adoption - The economy targets beyond the existing BNB Chain clients, but also traditional Web2 users and developers. The system design should try to be as compatible as possible with popular Web2 and Web3 standards.
5.Decentralization is a journey - Take the storage system as an example, there are two ends to the decentralization spectrum. On one extreme end, users have to create and store all their data on a single service supplier; on the other end, users can create and store their data on any household's computing terminal (it does not even have to be a desktop). The design will not force itself to be on the latter end right from day one. It picks up the simplest solution that moves the needle toward higher decentralization and will improve as time goes on. From this sense, the first step Greenfield goes ahead with is to provide the freedom to choose among plenty of service suppliers at any time with trivial costs because they own the data.
-
+
diff --git a/docs/greenfield/design/economy-of-data-assets.html b/docs/greenfield/design/economy-of-data-assets.html
index ff8c8c870f..b979ff0ede 100644
--- a/docs/greenfield/design/economy-of-data-assets.html
+++ b/docs/greenfield/design/economy-of-data-assets.html
@@ -9,7 +9,7 @@
-
+
@@ -30,7 +30,7 @@
revised from the ERC-721 standard. These NFTs have corresponding
metadata information for the resources. The ownerships of the NFTs on BSC stand for the ownerships of these resources on Greenfield. As these ownerships are not transferable on Greenfield, these NFTs are not transferable on BSC.
A few series of cross-chain primitives are defined for dApps to call to operate on these resource entities.
It is worth highlighting that smart contracts can call these primitives in a similar way as EOAs.
Accounts:
Create payment accounts on BSC
BNB:
transfer bidirectionally between BSC and Greenfield among accounts (including even payment accounts)
Bucket:
Create a bucket on BSC
Mirror bucket from Greenfield to BSC
Object:
Mirror object from Greenfield to BSC
Create an object on BSC
Grant/revoke permissions of objects on BSC to accounts/groups
Copy objects on BSC
Kick off the execution of an object on BSC
Associate buckets to payment accounts on BSC
Group:
Mirror group from Greenfield to BSC
Create a group on BSC
Change group members on BSC
Leave a group on BSC
Once these primitives are called by EOA or smart contracts, the
predefined events will be emitted. Greenfield Relayers should pick up these events and relay them over to Greenfield and BSC. As the change will happen asynchronously, there will be specific cross-chain packages for acknowledgments or errors, which can trigger a callback. The caller of the primitives should pay the fees upfront for cross-chain operations and also for the potential callback. More details are discussed in the Technical Specifications.
More SPs are welcome to ensure decentralization and data redundancy. But too many SPs may make SPs unable to make enough to sustain the business. Greenfield has an incentive design to make a proper number of SPs available. While SPs can choose to stay with the network or leave.
When the SPs join and leave the network, they have to follow a series of actions to ensure data redundancy for the users; otherwise, their "Service Stake" will be fined. This is achieved through the data availability challenge (described in detail in the Technical Specifications Section) and validator governance votes.
Greenfield validators and SPs form a pair synergy to provide the whole storage service. Validators store the metadata and financial ledger with consensus, while SPs provide real data storage and downloading.
Validators have the motivation to ensure enough good SPs to provide
decent service, while users and SPs rely on a stable and decentralized Greenfield blockchain as a single source of truth on metadata.
Many details are not covered in this Design Section. While some topics will be added and expanded in the technical specifications, some are very strategic items that shoot too far for the team to consider now.
For example, the "execute" trait of a data object. That concept points out that some data are runnable programs. Greenfield may create a more transparent computing environment. Users are comfortable using or devoting their data to particular programs stored on Greenfield because they can verify the program, they do not have to worry about the program may change after their confirmation, and they know the program can only run with their data in a trustful environment provided by Greenfield.
This particular function, together with other new features will be
researched and studied with the future development of BNB Greenfield.
We'd like to especially thank the efforts and ideas from the below teams and communities (in no particular order and definitely not an
exhaustive, full list). BNB Greenfield stands on these giants' shoulders to build.
1. Ethereum
2. Cosmos SDK
3. Superfluid
4. Amazon Web Services
5. MinIO, and other open-source storage systems
6. Filecoin, Arweave, StorJ, and other decentralized storage networks
7. Bitcoin, and
8. all the other folks and projects that strive for the new Web3 economy
This section of BNB Greenfield documentation describes the general principles and considerations for the design of BNB Greenfield. It covers the architecture and functionality analysis. Although the true model innovation is at the cross-chain with BSC, the unique storage fundamentals are also important to highlight.
-
+
diff --git a/docs/greenfield/design/storage-economics.html b/docs/greenfield/design/storage-economics.html
index 3a356b0a98..0be8760949 100644
--- a/docs/greenfield/design/storage-economics.html
+++ b/docs/greenfield/design/storage-economics.html
@@ -9,7 +9,7 @@
-
+
@@ -42,7 +42,7 @@
submit challenge transactions to other SPs; and lastly, Greenfield
blockchain will issue internal challenge events randomly as well.
The challenge can be triggered by Greenfield transactions or internal events at the end of blocking. Once Greenfield validators observe such a challenge, they should run a standard off-chain check against the data from the SPs being challenged. These validators will vote for the challenge results via an aggregated multisig via an off-chain P2P network and submit them to the Greenfield blockchain. The failed result for a challenge will slash the corresponding SPs. The submitter and validators will get rewards for such challenges.
The data that failed the challenge will not be challenged within a
certain amount of time to give the SPs some time to recover.
Another section in Technical Specifications will cover the data availability challenges in greater detail.
Users can request to delete their data objects. Greenfield will remove the metadata from the blockchain state, while the primary SP should respond to this request and drop all the replicas and redundant segments. The payment stream will be closed with a reward rebate to encourage the deletion in the future.
Greenfield is a protocol that provides core primitives, enabling a programmable, trustless decentralised storage network, parallel and interchangeable to traditional cloud storage services.
What is the connection between Validators and Storage Providers?
Greenfield Validators and Storage Providers (SP) form a pair synergy to provide the whole storage service, but are separated from each other. The Greenfield validators are responsible for generating Greenfield blocks, maintaining the Greenfield blockchain security, challenging the data availability, and maintaining cross-chain communication; while the Storage Providers are responsible for storing the data objects and responding to downloading requests. There is no strong binding relationship between them, although the same organization can play two roles at the same time.
What are the differences between Primary and Secondary Storage Providers?
Among the multiple SPs that one object is stored on, one SP will be the “Primary SP”, while the others are “Secondary SP”. Primary SP serves as a gateway for the users to access and manage their data - that is it should be used as the only SP to download the data. Users can change the primary SP for their objects later if they are not satisfied with their service.
Secondary SPs are used for replication. One provider can serve multiple roles, both as Primary and as Secondary provider on different objects. Primary SP or the users will select a few secondary SPs to store these segment replicas using Erasure Coding.
A single provider can serve multiple roles on different data objects. Once the primary provider exhausted their networking resources, they can use the remaining storage capacity to serve as secondary storage provider for other data objects - thus, increasing the hardware utilization and therefore overall return on the operation.
What are hardware requirements of running a storage provider?
As Primary and Secondary SPs serve a different role in the Greenfield ecosystem, the requirement towards the used hardware is different.
Primary SP is mostly network bound, as it serves the main gateway for the user to download and upload data. As such, we recommend running network optimised servers. Directly facing internet (public IP, no NAT) 8 cores CPU 16GB of RAM 500 SSD storage.
On the contrary, Secondary SPs serve for the replication purposes and are mostly CPU bound. We recommend running CPU optimised servers. Directly facing internet (public IP, no NAT) 8 cores CPU 16GB of RAM 500 SSD storage.
Should the storage provider serve both as Primary and Secondary SP for different data objects, we recommend running CPU and network optimised servers.
How do Storage Providers earn money with BNB Greenfield?
Staking Reward: Storage Providers will receive transaction fees as the staking reward. The rewards will be distributed passively. This is different from BNB Beacon Chain, where the system will distribute the rewards automatically. SPs can submit withdrawal requests to get all the up-to-date transaction rewards, and when SPs change commission rates or quit, all the transaction rewards that are not withdrawn will also be distributed.
Data Storage Fees: Storage Providers will receive fees as per amount of actual data stored by them. The storage fees are distributed among Primary and Secondary storage providers, participating in the object replication. As Primary SP serves as a gateway for the download, it will receive much higher usage of the I/O operations. As such, the storage rewards are calculated with Primary SP receiving the majority of the storage fees.
Data Traffic Fees: Storage Providers will receive fees as per amount of actual data served by them. The traffic fees are awarded only to the Primary storage provider, as it solely serves as the gateway for the users to access their data.
Force Settlement Rewards: If the user's payment account is depleted and no more funds are supplied, once balance is under the forced settlement threshold, the account will be forcibly settled. All payment streams of the account will be closed and the account will be marked as out of balance. The download speed for all objects associated with the account or payment account will be downgraded. The objects will be deleted by the SPs if no fund is provided within the predefined threshold.
The forced settlement will charge some fees, which is another incentive for users to replenish funds proactively. The fees will be distributed among the Primary and Secondary storage providers, in the ratio similar to the data storage fees.
What happens if the user refuses or is unable to pay?
To store data in Greenfield, users must reserve the minimum BNB amount equal to fund storage for a configurable amount of time. There are two configurations in the system, ReserveTime and LiquidateTime - both can be updated by the community vote. Let's say 7 days and 1 day, and the user wants to store the data costing 1$ per day. In such a scenario, the user must reserve fees for 7 days in buffer balance - 7$.
If the user's payment account is depleted and no more funds are supplied, the objects will be deleted by the SPs if no fund is provided within the predefined threshold LiquidateTime - 1 day.
BNB Greenfield uses BNB token as the utility token. There is a native cross-chain bridge between the Greenfield blockchain and BNB Smart Chain (BSC). The initial BNB will be locked on BSC and re-minted on Greenfield. BNB and data operation primitives can flow between Greenfield and BSC. Thus, total circulation of BNB will stay unchanged as it is now but flow among BNB Beacon Chain, BSC, and Greenfield.
One of the unique benefits of the BNB token is that it has limited supply, which means no one can create more BNB tokens, just to prop their balance sheet. Moreover, BNB token is also deflationary and is being periodically burned, or moved out of circulation, during the block creation of the BNB Smart Chain. Lastly, BNB token is used for all the projects within the BNB Chain ecosystem, including all the rollup and scaling solutions.
All these make BNB token extremely versatile, having no correlation with any specific domain, and ideal for financial project planning and COGS predictability.
We're working on expanding this FAQ with more content, including questions from the community and partners, so please watch this space! However, if you don't see your question, please ask in the BNB forum, so you can get the answers you need and make us aware of new FAQ items.
-
+
diff --git a/docs/greenfield/faqs/users.html b/docs/greenfield/faqs/users.html
index 52e378ae27..84c26a1b2e 100644
--- a/docs/greenfield/faqs/users.html
+++ b/docs/greenfield/faqs/users.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
This is very different, both conceptually and architecturally, to the Arweave billing system, where users pay a high one-time fee for future unlimited usage.
Also, similarly to IPFS, Arweave doesn’t provide any guarantees of SLA, so in order to use it in the production environment, users should integrate 3rd party scaling solutions into the application, such as Bundlr.
Overall, given Arweave’s long-term payment and lack of programmability capabilities, makes it a very good fit for storing archive data - an important, but different target from the Greenfield’s vision perspective.
One thing users need to be aware of is tokenomics of the projects. Each of the previously described projects use their own token, which solely serves as a unity token of the particular project.
This is very different from Greenfield, which uses BNB token as the utility token. One of the unique benefits of the BNB token is that it has limited supply, which means no one can create more BNB tokens, just to prop their balance sheet. Moreover, BNB token is also deflationary and is being periodically burned, or moved out of circulation, during the block creation of the BNB Smart Chain. Lastly, BNB token is used for all the projects within the BNB Chain ecosystem, including all the rollup and scaling solutions.
All these make BNB token extremely versatile, having no correlation with any specific domain, and ideal for financial project planning and COGS predictability.
Will it be cheaper to store data on BNB Greenfield than other centralized cloud services?
As Greenfield is a free market, the price will be determined by a number of variables related to the supply and demand for storage. It’s difficult to predict before launch. However, a few design elements of the network help support inexpensive storage.
The design prefers simplicity first principle over other considerations. Simple solutions are not only easy to implement, run, maintain, and extend, but also friendly to software performance, which is a main goal of the design. For example, any computing-intensive proof, like what Filecoin adopts, is ruled out according to this principle.
The biggest lesson learned from the crypto industry and BNB ecosystem is that the community has the most talent and power to build more applications and infrastructure in different self-driven ways. The design should focus on the core platform and technical foundation that provide enough interface, tools, and other facilitation to the developer community to build upon them.
The economy targets beyond the existing BNB Chain clients, but also traditional Web2 users and developers. The system design should try to be as compatible as possible with popular Web2 and Web3 standards.
Further, Greenfield introduces a concept called Service Providers. There will be many Service Providers offering different prices, based on region and need SLA. We expect Greenfield’s permissionless and programmable model to result in very efficient operations with inherently added value provided by the built-in programmability.
Servicer Providers will provide publicly accessible APIs for users to upload and manage data. These APIs are very similar to AWS S3 APIs, so that existing developers may feel familiar enough to write code for it - and result with little cost to update the application with Greenfield programmable capabilities and build superior products for the users.
Data resources on Greenfield, such as the data objects and the buckets, all have access control, such as which address can create, read, list, or even execute the resources, and which address can grant/revoke these permissions.
Only the user who initially uploaded the data is considered as sole owner of the data. Data objects can be only read and downloaded by the other users with proper read permissions.
Unlike IPFS and other storage systems, only authorized users can access the data - even if they have the url link to the data. Owners can later revoke the permissions to anyone, effectively removing the access rights.
Also, proof of existence challenges, which validators perform on the data, is done on the sector level - that is small pieces of data of a particular file. As such, no entity besides the specifically authorized parties can access the full file.
Will users be able to privately store and delete items from Greenfield?
By design, the bytes that are stored and downloaded later for the object are exactly the same bytes that were originally uploaded and cannot be altered. Users may choose their own encryption scheme if they want the data to be unrecognizable by Service Providers or any others, even though Service Providers have the obligation to not circulate these data out of users’ instruction.
Only the metadata is stored as the state data on the blockchain, the actual data is stored by Service Providers. Once a user wishes to delete their items, the metadata is deleted, which can be verified on blockchain, as such state removal will change the hashroot of the state.
Unlike other decentralised solutions, where there cannot be a guarantee that all copies of the file are gone from the network, Greenfield provides a cryptographic proof of the deletion process by the Service Provider, ensuring that the data is no longer stored on the network.
This design ensures that users have full control over their data, making the system fully compliant with various privacy policies, including GDPR .
Unlike other decentralized solutions, where there cannot be a guarantee that all copies of the file are gone from the network, Greenfield provides an explicit acknowledgement of the deletion process by the Service Provider, ensuring that the data is no longer stored on the network. This design ensures that users have full control over their data, making the system fully compliant with various privacy policies.
We at BNB Chain believe that a decentralized, know-nothing approach to data storage offers far better security than traditional, centralized approaches. However, many older data security and privacy standards (e.g., HIPAA, GDPR), require making specific representations about the physical location of data (e.g, requiring that data only be stored in certain countries or in data centers that meet certain standards). Therefore, if your application is subject to those standards, you should make sure that BNB Greenfield is right for you.
BNB Greenfield roadmap includes a project around geotagging and making sure that data only goes to nodes in certain countries. As the list of Storage Providers operators includes both individuals and data centers, once there is a critical mass of Storage Providers operators who are operating compliant data centers, we also intend to add an option for customers to only store data on nodes in compliant data centers should they need to meet storage compliance requirements. However, neither of these two important capabilities for compliant storage is live as of the last publication date.
BNB Greenfield has implemented a very secure and highly flexible mechanism for sharing files, portions of folders, etc., relying on the blockchain mechanism. An Access Grant is a security envelope that contains a Service Provider address, a restricted authorization token, and a restricted path-based encryption key—everything an application needs to locate an object on the network, access that object, and decrypt it. Access Grants coordinate two parallel constructs—encryption and authorization-- in a way that makes it easy to share data without having to manage access control lists or use complex encryption tools. Both of these constructs work together to provide a client-side access management framework that’s secure and private, as well as extremely flexible for application developers.
Since the underlying technology is based on blockchain signatures, there are no security implications in the choice of creating access grants in the command line interface vs. the browser interface.
How is the overall system security of BNB Greenfield is ensured?
The data integrity should be first guarded by the checksum of the objects as well as by the cryptographic signatures of the user. So when the user uploads the file, the user signs the file metadata, including the file checksum. As a result, no actor, including the Storage Providers, cannot change both the files and the checksum. The checksum is part of the data object metadata, and is verified constantly by the Greenfield validators.
The overall security of the system is ensured by the underlying security of the blockchain, on which all the interaction is managed. The off-chain communication between the Storage Providers is also based on the battle proven Tendermint SDK p2p protocol ensuring the battle proven security according to the most strict industry standards.
In general, data stored on Greenfield can be considered more secure, compared to existing traditional data storage providers, as access is secured by cryptographic elements - which are much more resistant to security attacks than cloud Single-sign-on (SSO) membership management. Overall, blockchain-backed security adds an additional layer of security, versus both traditional cloud-based and decentralized storage, that can help to prevent unauthorized access and protect against threats such as malware and other attacks.
By providing a secure and reliable way to store and process sensitive data and code, Greenfield can help to prevent unauthorized access and tampering, which can be a major concern in decentralized storage networks.
BNB Greenfield is designed to be extraordinarily resilient to data loss. The decentralized nature of our Storage Providers provides exceptional resilience against a lot of things that cause data loss in conventional storage systems (IT failure, fire, floods, power outages, etc.). The infrastructure automatically provides replication among the primary and secondary Storage Providers to store data segments replicas and their EC parity pieces.
In addition, data metadata is held on-chain using the BNB Greenfield blockchain, where the integrity is ensured by the consensus protocol - similarly to BNB Smart Chain. Thus, the integrity of the data is fully ensured by the decentralization of both the storage as well as the metadata layer.
Is BNB Greenfield compatible with popular CLI tools?
An important aspect of BNB Greenfield is compatibility with the existing, de facto standard for cloud object storage, AWS S3. As S3 is a vast, 15-year-old API, while we have aimed to support the most important capabilities---which cover the overwhelming majority of cloud storage-based applications--there is a long tail list of lesser-used functions that are not yet supported.
The end goal is to provide 100% compatibility and our next major effort involves supporting a range of server-side S3 functions. We listen to the community and users when prioritizing additional S3 functionality.
How can I contribute to the design and implementation of the BNB Greenfield?
BNB Chain always pursues the best system for the community and the overall blockchain ecosystem. Of course, BNB Greenfield design is not 100% final and the community still has work to do based on the feedback from the validators, storage providers, and of course the users.
This document is intended to address the known limitations of the technology with regard to security, performance, availability, usability, tokenomics, and more. The main purpose of this document is for the users and community members to understand the design choices and make well-informed decisions.
Important to note, that while as with every software product, some compromises have been made, everything is open for discussion and if you strongly disagree with the made architectural choices, please do raise your concerns in the github development page and discord channel. As with other BNB Chain systems, BNB Greenfield is open-source. We also publish detailed whitepapers, and frequent technical updates, so you can see what it is we are doing. This includes public access to github issues, including bugs, the internal roadmap, and everything although the internal discussion process. and we strongly encourage wider participation both in the discussion and the implementation process.
We're working on expanding this FAQ with more content, including questions from the community and partners, so please watch this space! However, if you don't see your question, please ask in the BNB forum, so you can get the answers you need and make us aware of new FAQ items.
Greenfield is a protocol that provides core primitives, enabling a programmable, trustless decentralised storage network, parallel and interchangeable to traditional cloud storage services.
What is the connection between validators and Storage Providers?
Greenfield validators and Storage Providers (SP) form a pair synergy to provide the whole storage service, but are separated from each other. The Greenfield validators are responsible for generating Greenfield blocks, maintaining the Greenfield blockchain security, challenging the data availability, and maintaining cross-chain communication; while the Storage Providers are responsible for storing the data objects and responding to downloading requests. There is no strong binding relationship between them, although the same organization can play two roles at the same time.
Although validators can potentially maintain a meaningful and healthy number of storage providers, there is enough incentive for the validators to manage a reasonable number of non-affiliated SPs.
What consensus mechanism does BNB Greenfield have?
As Proof-of-Stake is adopted in Greenfield, there will be a founding validator set in the genesis state. Validators can self-bond, meaning they can delegate BNB to themselves, and they can also receive delegations from any other BNB holders. These bonded BNB acts as collateral and cause each delegate, including validators, to have “skin in the game” so to speak. If any equivocation or byzantine behavior by a validator were to be committed, the validator would be slashed a predefined amount of bonded stake. The minimum self-delegated amount is 2,000 BNB. These validators deposit their BNBs on a BSC smart contract, which would be locked as their stakes. The new validator can be voted by the majority of the current validators to join in and gets elected as the active validator based on its delegation size.
What are hardware requirements of running a validator node?
Processing transactions is mostly CPU bound. However BNB Greenfield validators also have the responsibility to perform data availability challenges across the SPs.
Therefore we recommend running CPU optimized servers. Directly facing internet (public IP, no NAT) 8 cores CPU 16GB of RAM 500 SSD storage"
How do validators earn money with BNB Greenfield?
Staking Reward: Validators will receive transaction fees as the staking reward. The rewards will be distributed passively. This is different from BNB Beacon Chain, where the system will distribute the rewards automatically. Validators can submit withdrawal requests to get all the up-to-date transaction rewards, and when validators change commission rates or quit, all the transaction rewards that are not withdrawn will also be distributed.
Relayer Reward: Greenfield validators also have the obligation to run the relayer system for cross-chain communication with BSC. The package deliverer will get a fixed ratio of the relay fee as a reward. There are multiple Greenfield relayers and they may compete to submit the aggregated multi-signed packages onto the Greenfield blockchain and BSC. To avoid racing transactions caused by the competition, which wastes gas, the relayers are rotated to relay transactions, e.g. taking shifts every 10 minutes.
Block Building Reward: Every transaction in BNB Greenfield requires gas fees to be paid by the user and distributed among the Greenfield validators to write the metadata on-chain.
Data Challenge Reward: The Greenfield validators have the responsibility to verify the data availability from the SPs. They form a voting committee to execute this task by the incentive of fees and potential fines (slashes) on SPs.
BNB Greenfield uses BNB token as the utility token. There is a native cross-chain bridge between the Greenfield blockchain and BNB Smart Chain (BSC). The initial BNB will be locked on BSC and re-minted on Greenfield. BNB and data operation primitives can flow between Greenfield and BSC. Thus, total circulation of BNB will stay unchanged as it is now but flow among BNB Beacon Chain, BSC, and Greenfield.
One of the unique benefits of the BNB token is that it has limited supply, which means no one can create more BNB tokens, just to prop their balance sheet. Moreover, BNB token is also deflationary and is being periodically burned, or moved out of circulation, during the block creation of the BNB Smart Chain. Lastly, BNB token is used for all the projects within the BNB Chain ecosystem, including all the rollup and scaling solutions.
All these make BNB token extremely versatile, having no correlation with any specific domain, and ideal for financial project planning and COGS predictability.
We're working on expanding this FAQ with more content, including questions from the community and partners, so please watch this space! However, if you don't see your question, please ask in the BNB forum, so you can get the answers you need and make us aware of new FAQ items.
-
+
diff --git a/docs/greenfield/overview.html b/docs/greenfield/overview.html
index 9b9da75ed9..a41ff8b4ee 100644
--- a/docs/greenfield/overview.html
+++ b/docs/greenfield/overview.html
@@ -9,7 +9,7 @@
-
+
@@ -48,7 +48,7 @@
introduce new business models, which should be more open and fair.
This whitepaper is about the design and implementation of such a series
of systems, named BNB Greenfield, and calls for more buidlers to
build their own data infrastructure and business with it.
The paper contains 3 Parts.
Part 1 talks about the design, including the main technical logic and economic considerations;
Part 2 provides showcases that can be imagined in laboratories to inspire how new applications may use the new infrastructure;
Part 3 is a more detailed technical specification for the design in Part 1, although they are still simplified to a certain degree.
We suggest you read through Part 1 and Part 2 sequentially, but only refer to Part 3 when you need to dig into the details for particular components.
-
+
diff --git a/docs/greenfield/tech-specs/billing-and-payment.html b/docs/greenfield/tech-specs/billing-and-payment.html
index df6e299d82..9dfedbf7a4 100644
--- a/docs/greenfield/tech-specs/billing-and-payment.html
+++ b/docs/greenfield/tech-specs/billing-and-payment.html
@@ -9,7 +9,7 @@
-
+
@@ -91,7 +91,7 @@
formula might be flexible enough so it can be hard-coded on-chain.
There may be a chance the SPs want to change the formula(e.g. for
business model update). That will be achieved by SPs and validators'
coordinated governance.
-
+
diff --git a/docs/greenfield/tech-specs/cross-chain-models.html b/docs/greenfield/tech-specs/cross-chain-models.html
index b68193c556..fc48886c3f 100644
--- a/docs/greenfield/tech-specs/cross-chain-models.html
+++ b/docs/greenfield/tech-specs/cross-chain-models.html
@@ -9,7 +9,7 @@
-
+
@@ -80,7 +80,7 @@
cross-chain packages if there are any pending failed packages in their
queue. It asks the BSC dApps must handle the failed packages in
sequence.
The communication layer can catch any exception thrown by the resource mirror layer or application layer, so that package delivery won't be blocked by any customized applications.
3. Compute the checksum hash of the challenged piece, and compare it with the related checksum that is recorded in the local
manifest. If they are different, the piece should be regarded
as unavailable.
Any of the above "unavailable" cases will mark the challenge success that the data is unavailable, and the validator will vote "unavailable".
4. The validator uses its BLS private key to sign a data challenge vote according to the result. The data to vote should be the same for all validators to sign: it should include the block header of the block that contains the challenge, data challenge information, and the challenge result.
5. The data availability challenge votes are propagated through the P2P network.
6. Once a validator collects an agreement from more than 2/3 validators, an "attestment" is concluded. The validator can aggregate the signatures, assemble data challenge attestation, and submit an attestation transaction. In order to solve the concern that validators may just follow the others' results and not perform the check themselves, a "commit-and-reveal" logic will be introduced.
7. The data challenge attestation transaction will be executed on-chain. The first validator who submits the attestation can get a submission reward, while the later submission will be rejected. The more votes the submitter aggregates, the more reward it can get. Besides the submission rewards, there are attestment rewards too. Only the validators whose votes wrapped into the attestation will be rewarded, so it may be that some validators voted, but their votes were not assembled by the validator. They won't get rewarded for these data availability challenges. Also, for different results, the rewards will be different: the "unavailable" result that slashes the SPs will get validators more rewards.
8. After a number of blocks, for example, 100 blocks, the data availability challenge will expire even if the submissions of attestments haven't arrived. In such a case, the challenge will just expire with no further actions.
9. Once a case of data availability is successfully challenged, i.e. the data is confirmed not available with quality service, there will be a cooling-off period for the SPs to regain, recover, or shift this piece of data.
10. Once the cooling-off period time expires, this data availability can be challenged again if this piece of data is still unavailable, the SP would be slashed again.
-
+
diff --git a/docs/greenfield/tech-specs/ecosystem-players.html b/docs/greenfield/tech-specs/ecosystem-players.html
index 6ef2c8fe0d..a5bd30a0bb 100644
--- a/docs/greenfield/tech-specs/ecosystem-players.html
+++ b/docs/greenfield/tech-specs/ecosystem-players.html
@@ -9,7 +9,7 @@
-
+
@@ -44,7 +44,7 @@
the different kinds of use case scenarios.
In Greenfield, similar to other decentralized environments, dApps don't
need to ask for registration but communicate with users' wallets to get
users' instructions and other information.
-
+
diff --git a/docs/greenfield/tech-specs/greenfield-blockchain.html b/docs/greenfield/tech-specs/greenfield-blockchain.html
index 94caae198b..17991df4f1 100644
--- a/docs/greenfield/tech-specs/greenfield-blockchain.html
+++ b/docs/greenfield/tech-specs/greenfield-blockchain.html
@@ -9,7 +9,7 @@
-
+
@@ -52,7 +52,7 @@
storage provider doesn't provide a good service or prefers to stop
service. The current active validators can vote on this proposal. Once this proposal is passed, the SP will be restricted from accepting new object-storing requests, but still has the obligation to serve query requests. Other SPs or the data owners should start requesting to move the data off this "to-be-removed" SP. The "to-be-removed" SP has to facilitate the data moving so that it can get the full deposit back and avoid further slash.
Actually, even if it chooses to not cooperate, the data can be recovered from the other SPs. After all the data has been migrated, this "to-be-removed" SP can withdraw all its deposit, and this SP would be removed.
This part of the documentation on BNB Greenfield is the most detailed so it is subject to frequent changes. It should be highlighted here and widely understood that the content in this part will be continuously updated, much more frequently than the other parts, with either new sections added or existing sections revised.
-
+
diff --git a/docs/greenfield/tech-specs/payload-storage-mngt.html b/docs/greenfield/tech-specs/payload-storage-mngt.html
index 38cb46961a..a6ab165eee 100644
--- a/docs/greenfield/tech-specs/payload-storage-mngt.html
+++ b/docs/greenfield/tech-specs/payload-storage-mngt.html
@@ -9,7 +9,7 @@
-
+
@@ -79,7 +79,7 @@
data via the EC chunks. As designed, the ECIndex with values 0-3 are
data blocks while 4-5 are parity blocks. There are two processing cases
to reconstruct the object payload:
1. All data blocks are fully stored in secondary SPs. The recovery initiator can just read the pieces which are data blocks sequentially and stitch them together;
2. Some data blocks have been lost by secondary SPs. The recovery initiator needs to read all the data blocks and parity blocks and use the Decode function of the EC module to recover the content of all the segments.
-
+
diff --git a/docs/greenfield/tech-specs/sp-apis.html b/docs/greenfield/tech-specs/sp-apis.html
index 2c6968e67a..2d97fbd0c1 100644
--- a/docs/greenfield/tech-specs/sp-apis.html
+++ b/docs/greenfield/tech-specs/sp-apis.html
@@ -9,7 +9,7 @@
-
+
@@ -44,7 +44,7 @@
via a Greenfield blockchain full node RPCs. Here SPs should provide
these functions via corresponding APIs so that the users have a better
experience to store, check, download, and manage the objects.
-
+
diff --git a/docs/greenfield/tech-specs/storage-metadata-models.html b/docs/greenfield/tech-specs/storage-metadata-models.html
index 0d1a21fc25..87c5908437 100644
--- a/docs/greenfield/tech-specs/storage-metadata-models.html
+++ b/docs/greenfield/tech-specs/storage-metadata-models.html
@@ -9,7 +9,7 @@
-
+
@@ -51,7 +51,7 @@
associates and check whether Alice is a member of one of these
groups by checking, e.g. if the key 0x21 | ResourceID(group, e.g.
Games) existed, then iterate the permissionInfo map, and determine if Alice is in a group which has the permission to do CopyObject operation via the key 0x12| ResourceID(Games) | Address(Alice)
-
+
diff --git a/docs/greenfield/tech-specs/storage-transactions.html b/docs/greenfield/tech-specs/storage-transactions.html
index 941d5c7fc9..49e09abb14 100644
--- a/docs/greenfield/tech-specs/storage-transactions.html
+++ b/docs/greenfield/tech-specs/storage-transactions.html
@@ -9,7 +9,7 @@
-
+
@@ -25,7 +25,7 @@
buckets. It will be asynchronous as the action may take some time based
on the number and size of the objects in the bucket. The bucket needs to
be "Sealed" again by the new Primary SP.
-
+
diff --git a/docs/greenfield/tech-specs/user-identifier.html b/docs/greenfield/tech-specs/user-identifier.html
index 64252f86bd..92ecacfcd2 100644
--- a/docs/greenfield/tech-specs/user-identifier.html
+++ b/docs/greenfield/tech-specs/user-identifier.html
@@ -9,7 +9,7 @@
-
+
@@ -44,7 +44,7 @@
participate in staking, pay for gas fees of Greenfield transactions, and
pay for Greenfield services.
This balance can be added via native BNB transfer on Greenfield, or
cross-chain transfer between Greenfield and BSC.
-
+
diff --git a/docs/greenfield/use-cases/decentralized-storage.html b/docs/greenfield/use-cases/decentralized-storage.html
index 036635de4f..f463473549 100644
--- a/docs/greenfield/use-cases/decentralized-storage.html
+++ b/docs/greenfield/use-cases/decentralized-storage.html
@@ -9,7 +9,7 @@
-
+
@@ -22,7 +22,7 @@
the data from Greenfield back to BSC. These ideas are being considered by BSC Core Dev already.
Similar to Ethereum, BSC also welcomes Layer 2 Rollups as the solution to scale the total computing power and ledger size. Storing data on BSC is cheaper than Ethereum, but it can be much more effective if there is
a common storage infrastructure that is reliable and verifiable. Such infrastructure and corresponding data availability layer management can significantly reduce the cost of the rollups.
Data storage for the long term was not a topic that was seriously considered when blockchain was invented. However, it has become a problem today. Most developers prefer to run a blockchain node from a snapshot, instead of running for months from the genesis. Many networks, including Ethereum, have been researching that the block and historic data that has existed for more than a certain time should be allowed to drop. The community needs a publicly accessible and credible data source to read these very old data and recent snapshots. BNB Greenfield can be a good option. Its sponsorship feature is natural for this data of
social good.
Authors, publishers, and dApps should be aware of these limitations and
choose to use them at their own risk for now. More copyright-related
features may be introduced to Greenfield with the help of the community.
The goal of the BNB Greenfield platform is to unleash the power of decentralized blockchain and storage technology on data ownership and data economy.
This part of the documentation on BNB Greenfield is neither accurate as industrial designs nor serious as academic research. It just lists a few potential showcases that can be modeled upon BNB Greenfield in a "laboratory environment". The showcases are used to inspire further experimentation and solid design to create the next generation of decentralized applications.
Different big and small showcases are in this section. Some of them may be worth to be implemented into a real application, but more are expected to inspire new models to be invented to unleash the power of BNB Greenfield. This part of the documentation is
expected to be soon substituted by real applications in production.
-
+
diff --git a/docs/greenfield/use-cases/personal-data-market.html b/docs/greenfield/use-cases/personal-data-market.html
index 6b53006edb..1ee1278385 100644
--- a/docs/greenfield/use-cases/personal-data-market.html
+++ b/docs/greenfield/use-cases/personal-data-market.html
@@ -9,7 +9,7 @@
-
+
@@ -49,7 +49,7 @@
data market owner) can, and only those two can decrypt the data.
Many more infrastructures related to the scenario above are not
considered in this paper yet but can be gradually designed and
implemented on BNB Greenfield.
-
+
diff --git a/docs/greenfield/use-cases/user-generated-content.html b/docs/greenfield/use-cases/user-generated-content.html
index b64671fb23..5345dc6371 100644
--- a/docs/greenfield/use-cases/user-generated-content.html
+++ b/docs/greenfield/use-cases/user-generated-content.html
@@ -9,7 +9,7 @@
-
+
@@ -44,7 +44,7 @@
each list under the designated bucket for the business. The list of
objects and fully tracked change history are priceless functions for
such decentralized voting and governance ideas.
To create your Hardhat project run npx hardhat in your project folder to intialize your project.
Select Create an empty hardhat.config.js with your keyboard and hit enter.
$ npx hardhat 888 888 888 888 888 888 888 888 888 888 888 888 888 888 888 8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 888 888 "88b 888P" d88" 888 888 "88b "88b 888 888 888 .d888888 888 888 888 888 888 .d888888 888 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 Welcome to Hardhat v2.10.1 √ What do you want to do? · Create a JavaScript project √ Hardhat project root: · Project-Directory √ Do you want to add a .gitignore? (Y/n) · y You need to install these dependencies to run the sample project: npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead. npm install --save-dev "hardhat@^2.10.1" "@nomicfoundation/hardhat-toolbox@^1.0.1" Project created See the README.md file for some example tasks you can run Give Hardhat a star on Github if you're enjoying it! https://github.com/NomicFoundation/hardhat
When Hardhat is run, it searches for the closest hardhat.config.js file starting from the current working directory. This file normally lives in the root of your project and an empty hardhat.config.js is enough for Hardhat to work. The entirety of your setup is contained in this file.
You can write your own smart contract or download the BEP20 token smart contract template, place it in the contracts directory of your project and remane it as BEP20Token.sol.
require("@nomicfoundation/hardhat-toolbox"); const{ mnemonic }=require('./secrets.json'); // This is a sample Hardhat task. To learn how to create your own go to // https://hardhat.org/guides/create-task.html task("accounts","Prints the list of accounts",async()=>{ const accounts =await ethers.getSigners(); for(const account of accounts){ console.log(account.address); } }); // You need to export an object to set up your config // Go to https://hardhat.org/config/ to learn more /** * @type import('hardhat/config').HardhatUserConfig */ module.exports={ defaultNetwork:"mainnet", networks:{ localhost:{ url:"http://127.0.0.1:8545" }, hardhat:{ }, testnet:{ url:"https://data-seed-prebsc-1-s1.bnbchain.org:8545", chainId:97, gasPrice:20000000000, accounts:{mnemonic: mnemonic} }, mainnet:{ url:"https://bsc-dataseed.bnbchain.org/", chainId:56, gasPrice:20000000000, accounts:{mnemonic: mnemonic} } }, solidity:{ version:"0.8.9", settings:{ optimizer:{ enabled:true } } }, paths:{ sources:"./contracts", tests:"./test", cache:"./cache", artifacts:"./artifacts" }, mocha:{ timeout:20000 } };
note
It requires mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new `secrets.json` file in root directory and enter your 12 word mnemonic seed phrase to get started. To get the seedwords from metamask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words.
$ npx hardhat verify --network testnet 0xbF39886B4F91F5170934191b0d96Dd277147FBB2 Nothing to compile Compiling 1file with 0.5.16 Successfully submitted source code for contract contracts/BEP20Token.sol:BEP20Token at 0xbF39886B4F91F5170934191b0d96Dd277147FBB2 for verification on Etherscan. Waiting for verification result... Successfully verified contract BEP20Token on Etherscan. https://testnet.bscscan.com/address/0xbF39886B4F91F5170934191b0d96Dd277147FBB2#code
This tutorial guided you through the basics of creating and deploying a simple smart contract using the Hardhat IDE. It also provides step-by-step guide on how to verify your deployed smart contract. This tutorial uses testnet, however, the exact same instructions and sequence will work on the mainnet as well.
require("@nomiclabs/hardhat-waffle"); require('@nomiclabs/hardhat-ethers'); const{ mnemonic }=require('./secrets.json'); // This is a sample Hardhat task. To learn how to create your own go to // https://hardhat.org/guides/create-task.html task("accounts","Prints the list of accounts",async()=>{ const accounts =await ethers.getSigners(); for(const account of accounts){ console.log(account.address); } }); // You need to export an object to set up your config // Go to https://hardhat.org/config/ to learn more /** * @type import('hardhat/config').HardhatUserConfig */ module.exports={ defaultNetwork:"mainnet", networks:{ localhost:{ url:"http://127.0.0.1:8545" }, hardhat:{ }, testnet:{ url:"https://data-seed-prebsc-1-s1.bnbchain.org:8545", chainId:97, gasPrice:20000000000, accounts:{mnemonic: mnemonic} }, mainnet:{ url:"https://bsc-dataseed.bnbchain.org/", chainId:56, gasPrice:20000000000, accounts:{mnemonic: mnemonic} } }, solidity:{ version:"0.5.16", settings:{ optimizer:{ enabled:true } } }, paths:{ sources:"./contracts", tests:"./test", cache:"./cache", artifacts:"./artifacts" }, mocha:{ timeout:20000 } };
!!! Note
It requires mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new .secret file in root directory and enter your 12 word mnemonic seed phrase to get started. To get the seedwords from MetaMask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words.
This document provides a brief walk through on how to issue BEP20 tokens on the BNB Smart Chain. For this tutorial we have used Remix IDE and Metamask Wallet. Further, in this guide, we provide steps for issuing BEP20 tokens on the BSC Testnet, however, the steps for mainnet are also the same.
$ ./bnbcli keys Keys allows you to manage your local keystore for tendermint. These keys may be in any format supported by go-crypto and can be used by light-clients, full nodes, or any other application that needs to sign with a private key. Usage: bnbcli keys [command] Available Commands: mnemonic Compute the bip39 mnemonic for some input entropy add Create a new key, or import from seed list List all keys show Show key info for the given name delete Delete the given key update Change the password used to protect private key Flags: -h, --help helpfor keys Global Flags: -e, --encoding string Binary encoding (hex|b64|btc)(default "hex") --home string directory for config and data (default "/Users/yourname/.bnbcli") -o, --output string Output format(text|json)(default "text") --trace print out full stack trace on errors Use "bnbcli keys [command] --help"formore information about a command.
$ ./bnbcli keys add testkey Enter a passphrase for your key: Repeat the passphrase: NAME: TYPE: ADDRESS: PUBKEY: testkey local bnc1e8zhj9wmgq4pwzrv264gfru2fk8x2hdvpclx3n bncp1addwnpepqffepxlkrka9n33vyzmjwkpy05gpm46cn5de3x9v0vqswk7st5lkc7alhjv **Important** write this seed phrase in a safe place. It is the only way to recover your account if you ever forget your password. poverty joke nominee enough harsh elder flush noodle gift one limit tree sponsor sun radio above acid air winter inflict profit there brand water
$ ./bnbcli keys add testkey --recover Enter a passphrase for your key: Repeat the passphrase: > Enter your recovery seed phrase: poverty joke nominee enough harsh elder flush noodle gift one limit tree sponsor sun radio above acid air winter inflict profit there brand water NAME: TYPE: ADDRESS: PUBKEY: testkey local bnc1e8zhj9wmgq4pwzrv264gfru2fk8x2hdvpclx3n bncp1addwnpepqffepxlkrka9n33vyzmjwkpy05gpm46cn5de3x9v0vqswk7st5lkc7alhjv
-
+
diff --git a/docs/learn/beaconIntro.html b/docs/learn/beaconIntro.html
index 3476cb4ca3..b2937c3678 100644
--- a/docs/learn/beaconIntro.html
+++ b/docs/learn/beaconIntro.html
@@ -9,7 +9,7 @@
-
+
@@ -24,7 +24,7 @@
Users can submit different kinds of proposals for signaling, changing consensus parameters on chains, for example, text proposals, fee parameter change proposals, staking parameter change proposals, and so on.
For each on-chain proposal, there are deposit period for depositing BNB and voting period for voters to make votes.
Once the proposal passes, it will make effect on BNB Beacon Chain and side chains via cross chain communications.
There are different ways to participate in the network, from light nodes to full validators. BNB Beacon Chain follows a philosophy of progressive decentralization. We envision a future where organizations and individuals can run validator nodes, and BNB can be staked to join governance.
-
+
diff --git a/docs/learn/bsc-gov.html b/docs/learn/bsc-gov.html
index 9d80dd9570..a802309cf5 100644
--- a/docs/learn/bsc-gov.html
+++ b/docs/learn/bsc-gov.html
@@ -9,7 +9,7 @@
-
+
@@ -23,7 +23,7 @@
validator operators in this governance stage are actually voting Yes, No, or Abstain.
If a proposal reaches quorum or the minimum threshold defined by the protocol it will pass to the next stage for tallying.
After voting stage, the following condition will be taken into consideration to determine if it passes or not:
Quorum: more than 50% of the total staked tokens at the end of the voting period need to have voted
Threshold: More than 50% or a majority of the tokens that participated in the vote, excluding "Abstain" votes must have voted "Yes"
Veto: Less than 33.4% of the tokens that participated in the vote, not counting "Abstain" votes, have vetoed the decision "No (With Veto)".
If any of these conditions are not met, the deposit associated with the denied proposal will not be refunded. These funds will be sent to the validator set.
Once a parameter change is voted on and passes all conditions, the upgrade will take effect automatically in the whole network. And this is how you would have seen the BSC evolve to the current version today!
Every contract that wants to subscribe param change event, should implement the following interface: function updateParam(string key, bytes calldata value) external
Some following check must be done inside the interface:
The msg sender must be the gov contract.
Basic check of value. (length, value range)
An example implementation:
modifier onlyGov() { require(msg.sender == GOV_CONTRACT_ADDR, "the msg sender must be the gov contract"); _; } function updateParam(string key, bytes calldata value) external onlyGov{ if (key == "relayerReward"){ require(value.length == 32, "the length of value is not 32 when update relayer_reward param"); uint256 memory paramValue = TypesToBytes.ToUint256(0, value); require(paramValue >= MIN_RELAYER_REWARD, "the relayerReward is smaller than the minimum value"); require(paramValue <= MAX_RELAYER_REWARD, "the relayerReward is bigger than the maximal value"); relayerReward = paramValue； }else{ require(false, "receive unknown param"); } }
There are many system parameters to control the behavior of the BSC:
All these parameters of BSC system contracts is governable: slashing threshold, cross-chain transfer fees, relayer reward amount and so on.
params of Staking/Slash/Oracle/IBC modules on BC
All these parameters will be determined by BSC Validator Set together through a proposal-vote process based on their staking.
Such processes will be carried on BC, and the new parameter values will be picked up by corresponding system contracts via cross-chain communication when needed.
Relayers are responsible for submitting Cross-Chain Communication Packages between the two blockchains, BNB Smart Chain (BSC) and BNB Beacon Chain (BC). Due to the heterogeneous parallel chain structure, two different types of Relayers are created.
Relayers for BC-to-BSC communication referred to as BSC Relayers are a standalone process that can be run by anyone, and anywhere, except that Relayers must register themselves onto BSC and deposit a certain amount of BNB. Only relaying requests from the registered Relayers will be accepted by BSC.
Although Proof-of-Work (PoW) has been recognized as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security.
Ethereum and some other blockchain networks, such as MATIC Bor, TOMOChain, GoChain, xDAI, do use Proof-of-Authority(PoA) or its variants in different scenarios, including both testnet and mainnet. PoA provides some defense to 51% attack, with improved efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It serves as an easy choice to pick as the fundamentals.
Meanwhile, the PoA protocol is most criticized for being not as decentralized as PoW, as the validators, i.e. the nodes that take turns to produce blocks, have all the authorities and are prone to corruption and security attacks. Other blockchains, such as EOS and Lisk both, introduce different types of Delegated Proof of Stake (DPoS) to allow the token holders to vote and elect the validator set. It increases the decentralization and favors community governance.
BSC here proposes to combine DPoS and PoA for consensus, so that:
Blocks are produced by a limited set of validators
Validators take turns to produce blocks in a PoA manner, similar to Ethereum's Clique consensus design
Validator set are elected in and out based on a staking based governance
Fast finalization can greatly improve user experience. The Fast Finality feature will be enabled upon the coming Plato upgrade. This will be a major advantage of BSC, and many dapps will benefit from it.
The consensus protocol of BSC fulfills the following goals:
Short Blocking time, 3 seconds on mainnet.
It requires quite short time to confirm the finality of transactions, around 6s for mainnet after the coming Plato upgrade.
There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB.
It is 100% compatible with Ethereum system .
It allows modern proof-of-stake blockchain network governance.
In the genesis stage, a few trusted nodes will run as the initial Validator Set. After the blocking starts, anyone can compete to join as candidates to elect as a validator. The staking status decides the top 32 most staked nodes to be the next validator set, and such an election will repeat every 24 hours.
BNB is the token used to stake for BSC.
In order to remain as compatible as Ethereum and upgradeable to future consensus protocols to be developed, BSC chooses to rely on the BC for staking management. There is a dedicated staking module for BSC on BC. It will accept BSC staking from BNB holders and calculate the highest staked node set. Upon every UTC midnight, BC will issue a verifiable ValidatorSetUpdate cross-chain message to notify BSC to update its validator set.
While producing further blocks, the existing BSC validators check whether there is a ValidatorSetUpdate message relayed onto BSC periodically. If there is, they will update the validator set after an epoch period, i.e. a predefined number of blocking time. For example, if BSC produces a block every 5 seconds, and the epoch period is 240 blocks, then the current validator set will check and update the validator set for the next epoch in 1200 seconds (20 minutes).
The implement of the consensus engine is named as Parlia which is similar to clique. This doc will focus more on the difference and ignore the common details.
Validators set changes take place at the (epoch+N/2) blocks. (N is the size of validatorset before epoch block). Considering the security of light client, we delay N/2 block to let validatorSet change take place.
Every epoch block, validator will query the validatorset from contract and fill it in the extra_data field of block header. Full node will verify it against the validatorset in contract. A light client will use it as the validatorSet for next epoch blocks, however, it can not verify it against contract, it have to believe the signer of the epoch block. If the signer of the epoch block write a wrong extra_data, the light client may just go to a wrong chain. If we delay N/2 block to let validatorSet change take place, the wrong
epoch block won’t get another N/2 subsequent blocks that signed by other validators, so that the light client are free of such attack.
The consensus engine may invoke system contracts, such transactions are called system transactions. System transactions is signed by the the validator who is producing the block. For the witness node, will generate the system transactions(without signature) according to its intrinsic logic and compare them with the system transactions in the block before applying them.
In Clique consensus protocol, out-of-turn validators have to wait a randomized amount of time before sealing the block. It is implemented in the client-side node software and works with the assumption that validators would run the canonical version.
However, given that validators would be economically incentivized to seal blocks as soon as possible, it would be possible that the validators would run a modified version of the node software to ignore such a delay. To prevent validator rushing to seal a block, every out-turn validator will get a specified time slot to seal the block. Any block with a earlier blocking time produced by an out-turn validator will be discarded by other witness node.
Extending the ruling of the current validator set via temporary censorship
If the transaction that updates the validator is sent to the BSC right on the epoch period, then it is possible for the in-turn validator to censor the transaction and not change the set of validators for that epoch. While a transaction cannot be forever censored without the help of other n/2 validators, by this it can extend the time of the current validator set and gain some rewards. In general, the probability of this scheme can increase by colluding with other validators. It is relatively benign issue that a block may be approximately 3 secs and one epoch being 200 blocks, i.e. 20 mins so the validators could only be extended for another 10 mins.
Given there are more than ½*N+1 validators are honest, PoA based networks usually work securely and properly. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the Clone Attack. BSC does introduce Slashing logic to penalize Byzantine validators for double signing or inavailability. This Slashing logic will expose the malicious validators in a very short time and make the "Clone Attack" very hard or extremely non-beneficial to execute.
Finality is critical for blockchain security, once the block is finalized, it wouldn’t be reverted anymore. The fast finality feature is very useful, the users can make sure they get the accurate information from the latest finalized block, then they can decide what to do next instantly. More details of design, please to refer BEP-126
Before the coming Plato upgrade,to secure as much as BC, BSC users are encouraged to wait until receiving blocks sealed by more than ⅔*N+1 different validators. In that way, the BSC can be trusted at a similar security level to BC and can tolerate less than ⅓*N Byzantine validators.With 21 validators, if the block time is 3 seconds, the ⅔*N+1 different validator seals will need a time period of (⅔*21+1)*3 = 45 seconds. Any critical applications for BSC may have to wait for ⅔*N+1 to ensure a relatively secure finality. With above enhancement by slashing mechanism, ½*N+1 or even fewer blocks are enough as confirmation for most transactions.
After the coming Plato upgrade, the feature Fast Finality will be enabled. The chain will be finalized within two blocks if ⅔*N or more validators vote normally, otherwise the chain has a fixed number of blocks to reach probabilistic finality as before.
The ability to transfer tokens cross-chain is an essential need. This allows users to transfer their funds from one blockchain network to another. Keeping the importance of cross-chain support in mind, multiple networks now have their respective "bridges" to help in easy fund transfers. Following is a list of bridges and exchanges that support cross-chain transfer of BSC with other tokens.
BC is a Tendermint-based, instant finality blockchain. Validators with at least ⅔*N+1 of the total voting power will co-sign each block on the chain. So that it is practical to verify the block transactions and even the state value via Block Header and Merkle Proof verification. This has been researched and implemented as "Light-Client Protocol", which are intensively discussed in the Ethereum community, studied and implemented for Cosmos inter-chain communication.
BC-to-BSC communication will be verified in an "on-chain light client" implemented via BSC Smart Contracts (some of them may be "pre-compiled"). After some transactions and state change happen on BC, if a transaction is defined to trigger cross-chain communication,the Cross-chain "package" message will be created and BSC Relayers will pass and submit them onto BSC as data into the "build-in system contracts". The build-in system contracts will verify the package and execute the transactions if it passes the verification. The verification will be guaranteed with the below design:
BC blocking status will be synced to the light client contracts on BSC from time to time, via block header and pre-commits, for the below information:
block and app hash of BC that are signed by validators
current validatorset, and validator set update
the key-value from the blockchain state will be verified based on the Merkle Proof and information from above #1.
After confirming the key-value is accurate and trustful, the build-in system contracts will execute the actions corresponding to the cross-chain packages. Some examples of such packages that can be created for BC-to-BSC are:
Bind: bind the BEP2 tokens and BEP2E
Transfer: transfer tokens after binding, this means the circulation will decrease (be locked) from BC and appear in the target address balance on BSC
Error Handling: to handle any timeout/failure event for BSC-to-BC communication
Validatorset update of BSC
To ensure no duplication, proper message sequence and timely timeout, there is a "Channel" concept introduced on BC to manage any types of the communication.
For relayers, please also refer to the below "Relayers" section.
BSC uses Proof of Staked Authority consensus protocol, which has a chance to fork and requires confirmation of more blocks. One block only has the signature of one validator, so that it is not easy to rely on one block to verify data from BSC.
To take full advantage of validator quorum of BC, an idea similar to many Bridge or Oracle blockchains is adopted:
The cross-chain communication requests from BSC will be submitted and executed onto BSC as transactions. The execution of the transaction wil emit Events, and such events can be observed and packaged in certain "Oracle" onto BC. Instead of Block Headers, Hash and Merkle Proof, this type of "Oracle" package directly contains the cross-chain information for actions, such as sender, receiver and amount for transfer.
To ensure the security of the Oracle, the validators of BC will form another quorum of "Oracle Relayers". Each validator of the BC should run a dedicated process as the Oracle Relayer. These Oracle Relayers will submit and vote for the cross-chain communication package, like Oracle, onto BC, using the same validator keys. Any package signed by more than ⅔*N+1 Oracle Relayers’ voting power is as secure as any block signed by ⅔*N+1 of the same quorum of validators’ voting power.
By using the same validator quorum, it saves the light client code on BC and continuous block updates onto BC. Such Oracles also have Oracle IDs and types, to ensure sequencing and proper error handling.
There are scenarios that the cross-chain communication fails. For example, the relayed package cannot be executed on BSC due to some coding bug in the contracts. Timeout and error handling logics are used in such scenarios.
For the recognizable user and system errors or any expected exceptions, the two networks should heal themselves. For example, when BC to BSC transfer fails, BSC will issue a failure event and Oracle Relayers will execute a refund on BC; when BSC to BC transfer fails, BC will issue a refund package for Relayer to relay in order to unlock the fund.
However, unexpected error or exception may still happen on any step of the cross-chain communication. In such a case, the Relayers and Oracle Relayers will discover that the corresponding cross-chain channel is stuck in a particular sequence. After a Timeout period, the Relayers and Oracle Relayers can request a "SkipSequence" transaction, the stuck sequence will be marked as "Unexecutable". A corresponding alerts will be raised, and the community has to discuss how to handle this scenario, e.g. payback via the sponsor of the validators, or event clear the fund during next network upgrade.
In order to check the latest updates on the ecosystem of BNB Chain, visit our official GitHub Page.
The goal of this page is to provide the current status of the open-source BNB Smart Chain Tech Stack and highlight the potential interesting projects that are most demanded by the BSC community and ecosystem.
BNB Smart Chain is a 100% EVM compatible blockchain, and is one of the prime choices for decentralized application (dApp) development within many possible verticals including DeFi, NFT, Gaming, and many others.
To get a better understanding of the current BSC landscope, we divide each of the layers into the various components which we feel are most important. We then highlight some of the existing projects as well as some potentially interesting projects that we would like to fund by Binance Accelerator Funds. If you see a component with 0 or 1 existing projects then it's likely that we would consider grant support in this area. By describing our areas of priority in detail we do not wish to preclude grant applications that address different areas that we may not have thought of. We would like to fund all projects that bring value to the ecosystem.
📝 This is a living document and we are relying on our community to contribute to this and help maintain it. Please feel free to make edits and additions via pull requests.
66 for main-net and 96 for test-net. To compatible with third part service that already supports Ethereum, we’d better not use network id that Ethereum ecology that already used. The network id of test-net should be distinct from main-net.
period
Minimum difference between two consecutive block’s timestamps. Suggested 3s for the testnet .
epoch
Number of blocks after which to checkpoint and reset the pending votes. Suggested 100 for testnet
nonce
The nonce is the cryptographically secure mining proof-of-work that proves beyond reasonable doubt that a particular amount of computation has been expended in the determination of this token value.
In BNB Smart Chain, this value is always set to 0x0.
timestamp
Must be at least the parent timestamp + BLOCK_PERIOD.
extraData
EXTRA_VANITY: Fixed number of extra-data prefix bytes reserved for signer vanity. Suggested 32 bytes
Signer Info: validator address
EXTRA_SEAL bytes (fixed) is the signer’s signature sealing the header.
gasLimit
A scalar value equal to the current chain-wide limit of Gas expenditure per block. High in our case to avoid being limited by this threshold during tests. Note: this does not indicate that we should not pay attention to the Gas consumption of our Contracts.
GasCeil is 40000000 for testnet
difficulty
A scalar value corresponding to the difficulty level applied during the nonce discovering of this block.
Suggested 0x1 for testnet
mixHash
Reserved for fork protection logic, similar to the extra-data during the DAO.
Must be filled with zeroes during normal operation.
coinbase
System controled address for collecting block rewards
Block height in the chain, where the height of the genesis is block 0.
parentHash
The Keccak 256-bit hash of the entire parent block’s header (including its nonce and mixhash). Pointer to the parent block, thus effectively building the chain of blocks. In the case of the Genesis block, and only in this case, it's 0.
There are already some BNBs in the BC network when it starts up.
All the initial validators of BNB Smart Chain should be recorded in the BC.
The first one is a must, because if we want to transfer some BNB to BSC, we will consume some gas in BSC. So we must ensure there are already some BNBs in BSC. That means the first interchain transfer should be done in the genesis block of side chain.
For the second one, we should have that to ensure all the validators info and changes are tracked in the main chain.
So the solution is we enable the staking functionality of BSC first on BC. So people can apply to be a validator or delegate to these candidates. We can have a time limit. After that, we collect all the elected validators and write them to the genesis of BSC.
This default wallet would use a similar way to generate keys as Ethereum, i.e. use 256 bits entropy to generate a 24-word mnemonic based on BIP39, and then use the mnemonic and an empty passphrase to generate a seed; finally use the seed to generate a master key, and derive the private key using BIP32/BIP44 with HD prefix as "44'/60'/", which is the same as Ethereum's derivation path.
First deployed in early 2017, Gnosis multi-signature wallet became the foundational infrastructure for storing funds on Ethereum. The Gnosis Safe is the most secure way to manage your crypto funds.
Today, you can set up the Gnosis Safe Multisig on BNB Smart Chain in less than 60 seconds, and you can use wallets including Ledger, Trezor, Wallet Connect, Torus, and browser wallets like Metamask as signing keys so that you can manage your crypto collectively and inter-operably.
The BSC relayers play an important role in relaying interchain packages from BC to BSC.
All BSC relayers build their stable infrastructure, watch any event happened on the BNB Beacon Chain, and act timely to get paid accordingly. The following discussion is about how to distribute the rewards to let the relayers are willing to make a long-term contribution.
Fairness, competitiveness, and redundancy: Everyone has a chance to run a relayer even on cheap hardware. It should be hard for someone to get all the rewards.
Simplicity.
Robustness: The relayer may have a strategy to make its largest profit accordingly, under any condition, the interchain communication should not be blocked.
Low Risk: The relayer should take a little risk to play in this game. For the top N relayers, they should gain enough rewards to cover the cost.
It is tough hard to achieve all these goals; we make some trade-off on robustness and low risk in the following design.
To prevent the relayer who has the best network always winning the game, we gather the reward into two reward pools (header relayer reward pool and package relayer reward pool) and reallocate to the relayers to achieve redundancy:
S is a constant number of transactions that in around. Each round, there are S transactions, and the last transaction of the round will trigger reward distribution.
N is the maximum weight that a relayer can gain in a round. R is the total reward in this round. Ki is the number of successful transactions from Relayer i. Wi is the reward weight of Relayer i. Ri is the rewards of Relayer i.
R is the total reward in this round.
Ki is the number of successful transactions from Relayer i.
Rh represents the total balance of header reward pool.
We consider setting these parameters a reasonable value:
S to be 100. Some rewards come from gas fee, we can not guarantee enough rewards during a small round, a large round may dismiss deviation and let relayer give up relaying when it has made its max profit.
N to be 40. We think the redundancy of relayer around 3-5 is best. If N is too large, the redundancy will decrease. If N is too small, then there will not be enough relayers. Set N as 40 may be a reasonable value, at least 3 relayers can compete.
The relayFee of a single package and the ratio of reward for header relayer can be modified by governance on BNB Beacon Chain.
In each round, the last package delivery transaction will trigger the reward distribution. Both the header reward pool and package reward pool will be distributed. However, the reward won't be paid directly to relayer accounts. The distribution algorithm just calculates rewards for all relayers and writes down the amounts. Relayers are required to actively send transactions to claim their own accumulated rewards.
The system reward pool can hold at most 100BNB for example, to prevent the pool get unnecessary income.
The client needs to query the balance of the contract to decide whether to distribute 1/16 of the transaction fee to the contract or not. It seems not that fair that some validators pay more to the reward pool than others, but this is random and will eventually become fair in the long run.
If there are not enough rewards in the pool, all the tokens in the pool will be distributed.
Block header sync transaction with validatorSet change will claim reward to relayers from system reward pool directly.
For example, a relayer may deliver packages using a different address in round robin, we can’t recognize this. We try to introduce registration and BNB deposit for relayer to raise the cost of cheat. How it works:
A BSC account needs to call the register of RelayerHub contract to deposit 100BNB(more or less than 100 BNB will be rejected) to become a BSC relayer.
Only a valid relayer can sync BNB Beacon Chain Headers and deliver cross-chain packages.
Relayer can withdraw its deposit, but we will charge 0.1 BNB as the transaction fee so that it will receive 99.9 BNB back.
The charged fee will directly go to the system reward pool.
BNB Smart Chain is an innovative solution to bring programmability and interoperability to BNB Beacon Chain. BNB Smart Chain relies on a system of 55 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection, malicious vote detection and other slashing logic guarantee security, stability, and chain finality.
Other than the 32 active validators, BSC will introduce more validators, e.g. another 23 inactive validators, into the validator set as backups, which will be called "Candidates".
Candidates will produce blocks and charge gas fees in BSC mainnet, but in a much less chance than the official validator set of 32 elected. The unavailable candidates will be slashed as well though in a smaller size. A decent motivation is expected to be maintained so that the candidate validators are willing to ensure the quality and help secure BSC.
In an extreme case, if a majority of the active 32 validators get attacked and offline, Candidate Validators can report to BNB Beacon Chain about the stale blocking, resume it and eventually propose a re-election of the active validator set.
The BNB Smart Chain also supports EVM-compatible smart contracts and protocols. Cross-chain transfer and other communication are possible due to native support of interoperability. The BNB Smart Chain will be:
A self-sovereign blockchain: Provides security and safety with elected validators.
EVM-compatible: Supports all the existing Ethereum tooling along with faster finality and cheaper transaction fees.
Fast Finality: Finalizes the chain within two blocks in most cases.
Interoperable: Comes with efficient native dual chain communication; Optimized for scaling high-performance dApps that require a fast and smooth user experience.
Distributed with on-chain governance: Proof of Staked Authority (PoSA) brings in decentralization and community participants. As the native token, BNB will serve as both the gas of smart contract execution and tokens for staking.
Although Proof-of-Work (PoW) has been recognized as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security.
Ethereum and some other blockchain networks, such as MATIC Bor, TOMOChain, GoChain, xDAI, do use Proof-of-Authority(PoA) or its variants in different scenarios, including both testnet and mainnet. PoA provides some defense to 51% attack, with improved efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It serves as an easy choice to pick as the fundamentals.
Meanwhile, the PoA protocol is most criticized for being not as decentralized as PoW, as the validators, i.e. the nodes that take turns to produce blocks, have all the authorities and are prone to corruption and security attacks. Other blockchains, such as EOS and Lisk both, introduce different types of Delegated Proof of Stake (DPoS) to allow the token holders to vote and elect the validator set. It increases the decentralization and favors community governance.
BSC here proposes to combine DPoS and PoA for consensus, so that:
Blocks are produced by a limited set of validators
Validators take turns to produce blocks in a PoA manner, similar to Ethereum's Clique consensus design
Validator set are elected in and out based on a staking based governance
Fast finalization can greatly improve user experience. The Fast Finality feature will be enabled upon the coming Plato upgrade. This will be a major advantage of BSC, and many dapps will benefit from it.
The consensus protocol of BSC fulfills the following goals:
Short Blocking time, 3 seconds on mainnet.
It requires quite short time to confirm the finality of transactions, around 6s for mainnet after the coming Plato upgrade.
There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB.
It is 100% compatible with Ethereum system .
It allows modern proof-of-stake blockchain network governance.
Given there are more than ½*N+1 validators are honest, PoA based networks usually work securely and properly. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the Clone Attack. BSC does introduce Slashing logic to penalize Byzantine validators for double signing or inavailability. This Slashing logic will expose the malicious validators in a very short time and make the "Clone Attack" very hard or extremely non-beneficial to execute.
Finality is critical for blockchain security, once the block is finalized, it wouldn’t be reverted anymore. The fast finality feature is very useful, the users can make sure they get the accurate information from the latest finalized block, then they can decide what to do next instantly. More details of design, please to refer BEP-126
Before the coming Plato upgrade,to secure as much as BC, BSC users are encouraged to wait until receiving blocks sealed by more than ⅔*N+1 different validators. In that way, the BSC can be trusted at a similar security level to BC and can tolerate less than ⅓*N Byzantine validators.With 21 validators, if the block time is 3 seconds, the ⅔*N+1 different validator seals will need a time period of (⅔*21+1)*3 = 45 seconds. Any critical applications for BSC may have to wait for ⅔*N+1 to ensure a relatively secure finality. With above enhancement by slashing mechanism, ½*N+1 or even fewer blocks are enough as confirmation for most transactions.
After the coming Plato upgrade, the feature Fast Finality will be enabled. The chain will be finalized within two blocks if ⅔*N or more validators vote normally, otherwise the chain has a fixed number of blocks to reach probabilistic finality as before.
All the BSC validators in the current validator set will be rewarded with transaction fees in BNB. As BNB is not an inflationary token, there will be no mining rewards as what Bitcoin and Ethereum network generate, and the gas fee is the major reward for validators. After the coming Plato upgrade, part of the fees collected will be used as reward for finality voting. As BNB is also utility tokens with other use cases, delegators and validators will still enjoy other benefits of holding BNB.
The reward for validators is the fees collected from transactions in each block. Validators can decide how much to give back to the delegators who stake their BNB to them, in order to attract more staking. Every validator will take turns to produce the blocks in the same probability (if they stick to 100% liveness), thus, in the long run, all the stable validators may get a similar size of the reward. Meanwhile, the stakes on each validator may be different, so this brings a counter-intuitive situation that more users trust and delegate to one validator, they potentially get less reward. So rational delegators will tend to delegate to the one with fewer stakes as long as the validator is still trustful (insecure validator may bring slashable risk). In the end, the stakes on all the validators will have less variation. This will actually prevent the stake concentration and "winner wins forever" problem seen on some other networks.
BC and BSC share the same token universe for BNB and BEP2 tokens. This defines:
The same token can circulate on both networks, and flow between them bi-directionally via a cross-chain communication mechanism.
The total circulation of the same token should be managed across the two networks, i.e. the total effective supply of a token should be the sum of the token’s total effective supply on both BSC and BC.
The tokens can be initially created on BSC in a similar format as ERC20 token standard, or on BC as a BEP2, then created on the other. There are native ways on both networks to link the two and secure the total supply of the token.
Proof of Staked Authority brings in decentralization and community involvement. Its core logic can be summarized as the below. You may see similar ideas from other networks, especially Cosmos and EOS.
Token holders, including the validators, can put their tokens "bonded" into the stake. Token holders can delegate their tokens onto any validator or validator candidate, to expect it can become an actual validator, and later they can choose a different validator or candidate to re-delegate their tokens1.
All validator candidates will be ranked by the number of bonded tokens on them, and the top ones will become the real validators.
Validators can share (part of) their blocking reward with their delegators.
Validators can suffer from "Slashing", a punishment for their bad behaviors, such as double sign and/or instability.
There is an "unbonding period" for validators and delegators so that the system makes sure the tokens remain bonded when bad behaviors are caught, the responsible will get slashed during this period.
The Oracle module is a common module like the Governance module which is used to handle prophecy and claim. Prophecy means the validators want to reach a consensus on something, like cross chain transfer. Claim is raised by a validator and the content of claim is the cross chain transfer. When most of the validators (like 70%) claim the same thing on the prophecy, the winning claim will be executed.For oracle module is a common module, other module which depends on oracle module will register claim type and related hooks checking and handling claim. Each claim type has a sequence, oracle module should process prophecy and claim by sequence. When one prophecy is executed successfully, the sequence of the claim type will be increased by one.
Oracle module receives a claim message from validator, if the sequence is not current sequence, the claim message will be rejected.
If sequence is valid, the hooks of the claim type will check the claim message, if the claim message is invalid, then return
If the claim message is valid and it’s the first claim, the related prophecy will be created. If claim message is not the first claim, then it will be added to the existed prophecy.
If the power of validators which claim the same content reaches a threshold like 70%, the prophecy will be marked success and the hooks will execute the winning claim and the sequence of claim type will be increased.
If there is no chance that the validators will reach a consensus, the prophecy will be marked failed and the prophecy will be deleted and the validators should start over again.
Bridge module will process cross chain transactions. It contains two parts: transactions from BC to BSC and transactions from BSC to BC.
For transactions from BSC to BC, it will depend on the oracle module. When the validators reach a consensus on a certain claim, the bridge module will process the transaction according to the claim, like transfer from BSC to BC.
For transactions from BC to BSC, it will process the BC part of the transaction and write the related cross chain package for BSC.
The relayer is a service which monitors events on BSC, builds and broadcasts transactions to BC. Each validator operator should maintain its own relayer service. The relayer service requires to have access to the validator operator private key. All relayer service independently witness the peggy contract events, then build transactions to claim events to BC oracle module.
The relay process:
Continually listen for cross chain event
Parse the cross-chain transfer parameters from event data
Use this information to build an unsigned BC oracle transaction
The purpose of cross-chain interoperability is to enable one blockchain to function as a light-client of another. Since BNB Beacon Chain is using a classical Byzantine Fault Tolerant consensus algorithm, light-client verification is cheap and easy: all we have to do is check validator signatures on the latest block, and verify a Merkle proof of the state.
In Tendermint, validators agree on a block before processing it. This means that the signatures and state root for that block aren't included until the next block. Thus, each block contains a field called LastCommit, which contains the votes responsible for committing the previous block, and a field in the block header called AppHash, which refers to the Merkle root hash of the application after processing the transactions from the previous block. So, if we want to verify the AppHash from height H, we need the signatures from LastCommit at height H+1. (And remember that this AppHash only contains the results from all transactions up to and including block H-1)
Unlike Proof-of-Work, the light-client protocol does not need to download and check all the headers in the blockchain - the client can always jump straight to the latest header available, so long as the validator set has not changed much. If the validator set is changing, the client needs to track these changes, which requires downloading headers for each block in which there is a significant change. Here, we will assume the validator set is constant, and postpone handling validator set changes for another time.
Ethereum platform supports stateless precompiled contract implemented with golang and normal contract implemented with solidity. As compared to normal contracts, precompiled contracts are more efficient and costs less gas, but they are stateless. However, on-chain light client must be stateful. So here we will try to a mixed approach: precompiled implemented contract(stateless calculation, such as signature verification) and normal contract (store validator set and trusted appHash).
This contract implements tendermint header verification algorithm. The input parameters contain the trusted consensus state and a new tendermint header. The validation algorithm will verify the new tendermint header against the trusted consensus state. If the new header is valid, a new consensus state will be created and returned to caller. Otherwise, an error will be returned.
It is a watcher of validators change of BSC on BNB Beacon Chain. It will interact with light client contracts to verify the interchain transaction, and apply the validator set change for BSC. It also stores rewarded gas fee of blocking for validators, and distribute it to validators when receiving cross chain package of validatorSet change.
The liveness of BSC relies on validator set can produce blocks timely when it is their turn. Validators can miss their turns due to any reason. This instability of the operation will hurt the performance of the network and introduce more non-deterministic into the system. This contract responsible for recording the missed blocking metrics of each validator. Once the metrics are above the predefined threshold, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators.
This contract manages the authority of bsc-relayer. Someone who wants to run a bsc-relayer must call the contract to deposit some BNB to get the authorization.
This contract handles the governance package from BC. The governance package contains the target contract address, parameter name and new parameter value. Once the package is verified, this contract will call the parameter update method of the target contract to update the parameter to new value.
This contract focuses on cross chain packages pretreatment and sending cross chain packages to BC by emit event. The packages pretreatment includes sequence validation and the merkle proof verification. Once they are passed, the package will be routed to application build-in system contract, such as tokenhub or bscvalidator. Besides, if tokenhub or bscvalidator wants to send packages to BC, they need to encode their packages with rlp and call this contract to send them.
Chainlink Price Feeds provide a way to connect your smart contracts to the real-world market prices of assets. They enable smart contracts to retrieve the latest price of an asset in a single call.
Often, smart contracts need to act upon prices of assets in real-time. This is especially true in DeFi. For example, Synthetix use Price Feeds to determine prices on their derivatives platform. Lending and Borrowing platforms like AAVE use Price Feeds to ensure the total value of the collateral.
The most common use case for Price Feeds is to get the latest price. However, AggregatorV3Interface also exposes functions which can be used to retrieve price data of a previous round ID.
Solidity Contract
pragma solidity ^0.6.7; import "https://github.com/smartcontractkit/chainlink/blob/master/evm-contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; contract HistoricalPriceConsumerV3 { AggregatorV3Interface internal priceFeed; /** * Network: BNB Smart Chain * Aggregator: BNB/USD * Address: 0x0567F2323251f0Aab15c8dFb1967E4e8A7D42aeE */ constructor() public { priceFeed = AggregatorV3Interface(0x0567F2323251f0Aab15c8dFb1967E4e8A7D42aeE); } /** * Returns historical price for a round id. * roundId is NOT incremental. Not all roundIds are valid. * You must know a valid roundId before consuming historical data. * @dev A timestamp with zero value means the round is not complete and should not be used. */ function getHistoricalPrice(uint80 roundId) public view returns (int256) { ( uint80 id, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = priceFeed.getRoundData(roundId); require(timeStamp > 0, "Round not complete"); return price; } }
Javascript Web3
constWeb3=require("web3"); const web3 =newWeb3("https://data-seed-prebsc-1-s1.bnbchain.org:8545"); const aggregatorV3InterfaceABI =[{"inputs":[],"name":"decimals","outputs":[{"internalType":"uint8","name":"","type":"uint8"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"description","outputs":[{"internalType":"string","name":"","type":"string"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint80","name":"_roundId","type":"uint80"}],"name":"getRoundData","outputs":[{"internalType":"uint80","name":"roundId","type":"uint80"},{"internalType":"int256","name":"answer","type":"int256"},{"internalType":"uint256","name":"startedAt","type":"uint256"},{"internalType":"uint256","name":"updatedAt","type":"uint256"},{"internalType":"uint80","name":"answeredInRound","type":"uint80"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"latestRoundData","outputs":[{"internalType":"uint80","name":"roundId","type":"uint80"},{"internalType":"int256","name":"answer","type":"int256"},{"internalType":"uint256","name":"startedAt","type":"uint256"},{"internalType":"uint256","name":"updatedAt","type":"uint256"},{"internalType":"uint80","name":"answeredInRound","type":"uint80"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"version","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"}]; const addr ="0x0567F2323251f0Aab15c8dFb1967E4e8A7D42aeE"; const priceFeed =newweb3.eth.Contract(aggregatorV3InterfaceABI, addr); // Valid roundId must be known. They are NOT incremental. let validId =BigInt("18446744073709554130"); priceFeed.methods.getRoundData(validId).call() .then((historicalRoundData)=>{ // Do something with price console.log("Historical round data", historicalRoundData); })
Python Web3
from web3 import Web3 web3 = Web3(Web3.HTTPProvider('https://data-seed-prebsc-1-s1.bnbchain.org:8545')) abi ='[{"inputs":[],"name":"decimals","outputs":[{"internalType":"uint8","name":"","type":"uint8"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"description","outputs":[{"internalType":"string","name":"","type":"string"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint80","name":"_roundId","type":"uint80"}],"name":"getRoundData","outputs":[{"internalType":"uint80","name":"roundId","type":"uint80"},{"internalType":"int256","name":"answer","type":"int256"},{"internalType":"uint256","name":"startedAt","type":"uint256"},{"internalType":"uint256","name":"updatedAt","type":"uint256"},{"internalType":"uint80","name":"answeredInRound","type":"uint80"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"latestRoundData","outputs":[{"internalType":"uint80","name":"roundId","type":"uint80"},{"internalType":"int256","name":"answer","type":"int256"},{"internalType":"uint256","name":"startedAt","type":"uint256"},{"internalType":"uint256","name":"updatedAt","type":"uint256"},{"internalType":"uint80","name":"answeredInRound","type":"uint80"}],"stateMutability":"view","type":"function"},{"inputs":[],"name":"version","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"}]' addr ='0x0567F2323251f0Aab15c8dFb1967E4e8A7D42aeE' contract = web3.eth.contract(address=addr, abi=abi) # Valid roundId must be known. They are NOT incremental. validRoundId =18446744073709554130 historicalData = contract.functions.getRoundData(validRoundId).call() print(historicalData)
Chainlink price feed contracts are updated on a regular basis by multiple Chainlink nodes. This section lists the contract addresses for Price Feeds on the BNB Smart Chain.
-
+
diff --git a/docs/migration/evm-chains/chain-comparison.html b/docs/migration/evm-chains/chain-comparison.html
index 095aa08504..afe7f7a6ab 100644
--- a/docs/migration/evm-chains/chain-comparison.html
+++ b/docs/migration/evm-chains/chain-comparison.html
@@ -9,7 +9,7 @@
-
+
@@ -24,7 +24,7 @@
As Polygon is a Layer-2 scaling solution that utilizes sidechains for performing computation, it can also be regarded as a Commit Chain of Ethereum. This means Polygon can't exist without Ethereum as all the final transactions are done on Ethereum. Currently, Polygon uses the POS (Proof of Stake) algorithm which is less decentralized, but they plan to move to ZK rollups to address the criticism it receives for itd.
On the other hand, BSC is a hard fork of Ethereum. As BSC is a separate Layer-1 blockchain of its own, it does not need Ethereum to survive and thus has achieved 100% availability since its inception - even during the time Ethereum experienced downtimes.
Support for the EVM allows interoperability between BSC, Polygon Network, and the Ethereum Network. So, developers can conveniently migrate their dApps from the Ethereum network to either Polygon or BSC and vice versa.
BNB Chain is an ecosystem comprising of two major blockchains that serve different purposes, namely, BNB Beacon Chain (BC) and BNB Smart Chain (BSC). To deal with the increased volumes of transactions and daily active users (DAU), BNB Chain ecosystem has evolved to add more scaling solutions and now includes the following components with different responsibilities and purposes.
BNB Smart Chain (BSC) - EVM compatible, consensus layers, and with hubs to multi-chains
ZkBNB- ZkRollup solution to scale BSC as a super high-performance blockchain.
The design principles of BSC:
Standalone Blockchain: even though BSC can be termed as a Layer-2 solution to BNB Beacon Chain, technically, it is a standalone blockchain. Most of the fundamental technical and business functions of BSC are self-contained and it can run well even if the BC is stopped.
Ethereum Compatibility: To take advantage of the mature applications and community of Ethereum, BSC chooses to be compatible with the existing Ethereum mainnet. This means all of the dApps, ecosystem components, and toolings work with BSC and require zero or minimum changes. Furthermore, BSC nodes require similar (or a bit higher) hardware specification and skills to run and operate.
Staking Involved Consensus and Governance: Staking-based consensus is more environmentally friendly and leaves more flexible options to community governance. Expectedly, this consensus enables better network performance over proof-of-work blockchain systems, i.e., faster blocking time and higher transaction capacity.
Native Cross-Chain Communication: both BC and BSC are implemented with native support for cross-chain communication among the two blockchains. The communication protocol is designed to be bi-directional, decentralized, and trustless. It concentrates on moving digital assets between BC and BSC, i.e., BEP2 tokens, and eventually, any other BEP tokens introduced later.
Polygon’s architecture can be divided into three layers.
*Ethereum layer: comprises a set of contracts for different functionalities, like staking, checkpointing, and rewards, that exist on the Ethereum mainnet.
*Heimdall layer: comprises a set of proof-of-stake Heimdall nodes that run parallel to the Ethereum mainnet and are responsible for monitoring the set of staking contracts deployed on the Ethereum mainnet and committing the Polygon Network checkpoints to the Ethereum mainnet. Heimdall is based on the Tendermint protocol.
*Bor layer: a set of block-producing Bor nodes shuffled by Heimdall nodes. Bor is based on Go Ethereum.
A set of staking management contracts are employed on the Ethereum mainnet which enable the Proof of Stake (PoS) mechanism on Polygon. The staking contracts implement the following features:
Anyone can stake the MATIC tokens on the staking contracts existing on the Ethereum mainnet to join the Polygon system as a validator.
Earn staking rewards for validating state transitions on the Polygon Network.
The Heimdall can rightfully be called the heart of the Polygon system. It is responsible for the management of validators, block producer selection, spans, the state-sync mechanism between Ethereum and Polygon and other essential aspects of the system. It uses the Cosmos-SDK and a forked version of Tendermint, called Peppermint. Even though Heimdall uses a customized version of the Cosmos-SDK, it follows the same pattern - for better for worse.
The Heimdall layer can also be called the validation layer. It is responsible for the collection of blocks produced by Bor into a Merkle tree and publishing the Merkle root periodically to the root chain. Checkpoints are referred to as the periodic publishing of snapshots of the Bor sidechain. For every few blocks produced on the Bor layer, a validator on the Heimdall layer is responsible for the following
Validating all the blocks produced since the last checkpoint.
Creation of a Merkle tree of the block hashes.
Publishing the Merkle root hash to the Ethereum mainnet.
A subset of active validators from the pool is selected to act as block producers for a span and are responsible for the creation and broadcasting of new blocks on the network.
A checkpoint includes the Merkle root hash of all blocks created during any given interval. All nodes validate the Merkle root hash and attach their signature to it.
A proposer selected from the validator set is responsible for collecting all the signatures for a particular checkpoint and then committing the checkpoint on the Ethereum mainnet.
The responsibility of creating blocks and proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.
Bor can also be termed as Polygon's sidechain block producer. It is the entity which is responsible for the collection of transactions into blocks. Bor block producers are essentially a subset of the validators and to maintain decentralization these are periodically shuffled using historical Ethereum block hashes by the Heimdall validators. The Bor node implementation is basically the sidechain operator. The sidechain VM is EVM-compatible and is a basic Geth implementation with custom changes to the consensus algorithm.
Polygon utilizes the Proof-of-Stake (PoS) consensus algorithm, whereas BSC employs the Proof-of-Stake-Authority (PoSA). Both consensus mechanisms' major concern is to overcome Ethereum’s high gas fees and slower transactions.
In the PoS consensus algorithm, validators are chosen based on a user's commitment to the network in terms of its stake, meaning that the higher the stake, higher the chances of getting selected as a validator. On the other hand, PoSA is a combination of the PoS and the PoA (Proof of Authority) consensus mechanisms.
Utilizing the PoSA consensus mechanism, BSC was initially launched with 21 validators. However, now BSC supports a set of 55 validators, with 32 of them being active. In future, BSC plans to increase the active validators to 41, and about 80-100 validators in total. The top validator candidates with the most bonded stakes are chosen to be part of the subset of active validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality. Other than the 41 active validators, BSC also has a set of inactive validators known as the Candidates. Even though the chances of getting elected are less, the Candidates upon selection can produce blocks and charge gas fees in the BSC mainnet. Similar to Active Validators, unavailable candidates are slashed but for a smaller amount. In an extreme case, if a majority of the active 41 validators get attacked and offline, Candidate Validators can report to BNB Beacon Chain about the stale blocking, resume it and eventually propose re-election of the active validator set.
In contrast, Polygon uses the Proof-of-Stake (PoS) consensus mechanism on its Plasma/POS commit chains. For any user willing to participate in the consensus process, users are required to stake MATIC tokens on the staking smart contracts on Ethereum mainnet. This staking indicates a user's commitment to the process. A slashing mechanism (removal of staked funds) is also implemented to discourage stakers from submitting invalid blocks, illegally verifying blocks, or executing invalid transactions. Requiring validators to put funds at risk before they can participate in consensus helps maintain the integrity of the network.
There are a variety of EVM-compatible blockchain on the market, and while from the first sight, it may look as if all of them are the same, the reality is every blockchain is aimed for specific use cases and both security and availability requirements. This is why BSC has undergone several iterations of improvements to ensure superb performance and the most advanced security.
-
+
diff --git a/docs/migration/evm-chains/token-comparison.html b/docs/migration/evm-chains/token-comparison.html
index 5129c14368..a820c2d19a 100644
--- a/docs/migration/evm-chains/token-comparison.html
+++ b/docs/migration/evm-chains/token-comparison.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
In this article, we provide an overview of what tokens are and supported tokens by BSC
Technically speaking, “token” is just another term used for referencing cryptocurrencies or crypto-assets. Nevertheless, with the evolution in the standards for crypto tokens, tokens can be described in the context of their use. One description of tokens is that of cryptocurrencies, where tokens are used in the form of digital money and are native to a particular blockchain. In another way, tokens can also be described as digital assets running on top of other cryptocurrencies’ blockchain, e.g., most of the decentralized finance (DeFi) tokens. There is a wide spectrum of use cases where tokens can be functional. e.g., decentralized exchanges, tradable assets, digitization of assets, etc. Generally, all tokens can be traded or held like any other cryptocurrency.
Tokens hold a very important role in the blockchain-based decentralized ecosystem and can be used for various purposes within a dapp’s universe. Other than fungible tokens, which are a representation of interchangeable assets on a blockchain and are usually used as cryptocurrencies, some of the most important categories based on usage are as follows:
DeFi Tokens: DeFi protocols and dApps are aimed at reproducing traditional financial system functions (lending, borrowing, saving, insurance, trading, etc.). DeFi tokens represent a diverse set of cryptocurrencies native to automated, decentralized DeFi platforms run through smart contracts. These tokens perform a wide range of functions within the DeFi platform and are also tradable or can be held like any other cryptocurrency.
Utility Tokens: These types of tokens are designed to serve particular purposes within a specific application/protocol's ecosystem and allow users to be part of the decision-making on a specific network. Furthermore, utility tokens are unique to their ecosystem and are non-mineable cryptocurrencies. They are usually pre-mined, being created all at once, and distributed in a manner chosen by the team behind the project.
Governance Tokens: These specialized tokens give holders the right to vote on issues that govern the development and operations of a blockchain project. It’s a method for projects to distribute decision-making power to their communities. This decentralized governance model helps align the interests of the token holders with that of the project.
Non-Fungible Tokens (NFTs): NFTs are used to represent ownership rights to a unique digital or real-world asset. These allow the tokenization of real-world things like art, collectibles, real estate, etc. Ownership of an asset is secured by the blockchain network, as no one can modify the record of ownership or copy/paste a new NFT into existence.
Security Tokens: are a new class of assets that aim to be the crypto equivalent of traditional securities like stocks and bonds. Their main use case is to sell shares in a company (very much like the shares or fractional shares sold via conventional markets) or other enterprises (for instance, real estate) without the need for a broker. Major companies and startups have been reported to be investigating security tokens as a potential alternative to other methods of fundraising.
Ethereum is the pioneer of blockchain platforms to provide smart contract functionalities and standards for developing crypto tokens. However, with time, several blockchain platforms have emerged, some being EVM-compatible and others non-EVM. With a multitude of blockchain projects issuing their own tokens on different blockchains, it is important to make sure that these tokens are compatible with the underlying blockchains and adhere to the platform’s token standards.
To ensure compatibility, interoperability, and security, token standards are issued. These are a set of rules for the issuance and implementation of new tokens. The most commonly included requirements in these token standards are the token’s total supply limit, minting, burning, and the process for performing transactions using the token.
Furthermore, token standards are designed to help avoid fraud, technical incompatibilities between tokens, and issuance of tokens not aligned with the blockchain’s principles. For example, the rules for total supply and new token minting help contain potential token value depreciation.
One of the most popular token standards is the ERC standard. ERC (Ethereum Request for Comments) is a set of rules defining the issuance and implementation of tokens on the Ethereum Blockchain. ERC20 is a technical standard that describes a common set of rules that should be followed for a token to function properly within the Ethereum ecosystem. It is one of the most commonly used standards and is usually used for fungible tokens in the form of cryptocurrencies. Other popular ERC standards are ERC-721 (NFTs) and ERC-1155 Multi-Token Standard.
Similar to ERC, BNB Chain defines its own set of standards for token issuance, management, and implementation known as BEP (BNB Evolution Proposals). BEPs are token management rules and pre-defined criteria for launching on-chain assets on BNB Chain. The most popular BEP standards are BEP2 and BEP20. BEP2 is the native coin of the BNB Beacon Chain. Whereas BEP20 is popular for use on BSC. It is to note here that BEP20 is very similar to ERC20 and extends its functionality. Note that BNB, which is the native token of the BNB Chain ecosystem, is a BEP2 token.
Both ERC20 and BEP20 standards are very similar in mechanism. However, ERC-20 is dedicated to Ethereum, whereas BEP-20 is dedicated to BNB Smart Chain. In simpler terms, each of these is a token standard that belongs to a different blockchain.
BNB Chain is an ecosystem that runs on two blockchain giants, namely, BNB Beacon Chain (BC) and BNB Smart Chain (BSC). The native token standard for BNB Beacon Chain is BEP2, while the native token standard for BNB Smart Chain is BEP20. BNB ecosystem’s native currency, BNB, initially launched as an ERC20 token, is in fact a BEP2 token.
BNB Beacon Chain is essentially a digital asset creation and exchange platform. BNB Beacon Chain is responsible for the governance of the BNB Chain ecosystem, which includes staking and voting. BEP2 is the token standard for BNB Chain's native currency, BNB, on Binance's crypto exchanges. It is a unique token standard. BEP2 is not compatible with blockchains other than BNB Chain. Additionally, BNB in the BEP2 format can only be used as a transaction fee on both Binance cryptocurrency exchanges. One limitation of BEP2 is its lack of support for smart contract development. For more information, you can read the full BEP2 proposal here.
BSC is the blockchain component of the BNB Chain that provides its users with a smart contract facility and is a platform for dApp development. BEP20 is a token interface standard for creating token contracts on BSC. The BEP20 tokens are designed to be compatible with BEP2 and ERC20. It extends ERC20 for compatibility with EVM chain and Ethereum smart contracts. Other than the ERC20 functionalities, the BEP20 standard contains additional interfaces, such as getOwner and decimals. For more information on BEP20, read the full proposal here.
-
+
diff --git a/docs/migration/evm-chains/token-migration.html b/docs/migration/evm-chains/token-migration.html
index 93bb057b5d..94ba70428e 100644
--- a/docs/migration/evm-chains/token-migration.html
+++ b/docs/migration/evm-chains/token-migration.html
@@ -9,7 +9,7 @@
-
+
@@ -23,7 +23,7 @@
One thing critical to understand is how cross-chain bridges actually work. Cross-chain bridges work by "wrapping" tokens in a smart contract and issuing native assets you can use on another chain. For example, wrapped Bitcoin (wBTC) is an ERC-20 token that uses Bitcoin (BTC) as a collateral. Users must deposit BTC on the Bitcoin blockchain, before receiving wBTC tokens on the BSC network.
In this section of the article, we describe how to use Celer's cBridge for bridging tokens from Polygon to BSC. For custom tokens, you will have to get your token whitelisted by the Celer team. For this tutorial, we will be bridging a more commonly supported USDC token from the Polygon blockchain to BSC using the Celer cBridge.
Using Celer cBridge to bridge tokens from Polygon to BSC
Head over to the official Website of cBridge and connect your wallet. After clicking on the connect wallet button, choose your desired wallet. If metamask is chosen, confirm the connection on the popup notification.
Select your source and destination chains. To make sure your Metamask wallet is connected to the source chain, approve and switch to the network by confirming the metamask notification.
Make sure your source chain is set to Polygon and the destination chain is BSC. Also, confirm that you have selected USDC for transfer.
Adjust the slippage tolerance if required. Your transfer may fail if you choose a very low slippage tolerance.
Review your transaction details and confirm the transaction.
Confirm Transfer, then sign the transaction on your wallet.
Wait for the transaction to confirm and for your funds to arrive on your destination
In case of transfer failure, due to insufficient liquidity on the destination chain or an unfavorable slippage tolerance, you will receive a popup explaining the reason for the failure. You can cancel the transfer either through the popup, or by clicking Request Refund in the transfer history.
In crypto space, Vesting is known as the process of locking and distributing purchased tokens within a particular timeframe known as the Vesting Period. Vested tokens can be described as a certain amount of tokens that are held aside for a particular time period, usually for the team members, partners, advisors, and others who are contributing to the development of the project.
Vested tokens are essentially locked in a smart contract and are released automatically until certain conditions are met. Vesting basically gives the impression that the team is highly interested in the project and aims to continue working on the project development. Additionally, vesting lowers market price manipulations.
There are two options available for migrating vested tokens from EMV-based blockchain to BSC.
Migrate the vesting contract and move the whole vesting schedule to BSC.
Migrate the tokens that are being released as per the schedule
Vesting is essentially a smart contract that has all of the vested tokens locked up which are released over a time period automatically when certain conditions are met. One of the possible ways to migrate vested tokens from BSC is to migrate the vesting contract that is to deploy your vesting smart contract to BSC.
Another method is to ask the holders of vested tokens to exchange the already bought vested tokens with a newly created equivalent token on BSC and continue the release of vested tokens as per schedule. Another way is to take a snapshot of the vested token holders and update their wallets with an equivalent amount of new tokens and continue with the vesting schedule and release of tokens.
With several advantages and an ecosystem that supports web3 development, BNB Chain has gained a lot of attention from developers and blockchain projects. Several blockchain projects are now choosing to migrate their tokens from other EVM chains to BSC. In this article, we provided a brief overview of how to migrate tokens from one EVM to another, in particular from Polygon to BSC.
-
+
diff --git a/docs/migration/non-evm-chains/solana/architecture-comparison.html b/docs/migration/non-evm-chains/solana/architecture-comparison.html
index d38debf678..5920befba5 100644
--- a/docs/migration/non-evm-chains/solana/architecture-comparison.html
+++ b/docs/migration/non-evm-chains/solana/architecture-comparison.html
@@ -9,7 +9,7 @@
-
+
@@ -22,7 +22,7 @@
EVM-based blockchains have two types of accounts - Externally Owned Accounts (EOA) and Contract Accounts. EOAs can store asset balances and are capable of sending and receiving transactions. Contract accounts form the basis for on-chain smart contracts. Along with storing the EVM code, every contract account also has an associated storage map that is used for reading and writing arbitrary data. The EVM provides instructions for each contract to read and write to its own storage, but it is impossible to read from other contracts’ storage.
Solana’s Sealevel (runtime component for smart-contract) also has two types of accounts: executable and non-executable accounts. Unlike the EVM, both of these accounts have the capability of storing data. Executable accounts are immutable in Sealevel and can either store their own executable byte code or a proxy address of an account that stores mutable executable byte code. Due to the immutable nature of the executable accounts, non-executable accounts are used for storing their application state.
In the EVM, contracts can only read and write their own storage. On the other hand, in Sealevel, any account’s data can be read or written to by a contract. However, the runtime enforces that only an account’s “owner” is allowed to modify it. Changes by any other programs will be reverted and cause the transaction to fail.
b. Contract Storage
On the BSC blockchain, EVM is responsible for the execution of smart contracts. The contract state or memory is stored at the contract address. This storage resembles the array data structure of infinite length located at the contract’s address. The storage mechanism ensures no conflicts in storage locations and follows a set of rules. Using these rules, we can decode the state of any contract.
As compared to BSC, data storage and management are much more complex on Solana. There are different account categories used for data storage on Solana:
Program Accounts: are accounts that store executable code, the equivalent to BSC’s smart contracts.
Storage Accounts: are used for storing the data connected to programs (smart contracts).
Token Accounts: are used for keeping track of an account balance of tokens and allow for transferring or receiving tokens between accounts.
In the Solana blockchain, smart contracts are referred to as programs. Unlike BSC, there is a separation between the program and the data/state of the program. Both are assigned separate accounts but are connected. In BSC, a smart contract and its data are both located in one location on the blockchain. If you were to make a program that counted the number of token transfers that a program made, you would need to create the program to make the transfers as well as another account to store the count of transfers.
EVM Contracts vs Solana PDA
On BSC, smart contracts are EVM compatible. On EVM, smart contracts are stored on the contract accounts. A contract account is controlled by code executed by the EVM. Contract accounts have associated code and data storage, controlled by the code itself. The controlling behavior is defined in the smart contract stored in them. Creating a contract account has a cost due to network storage. A contract account can only send transactions in response to receiving a transaction. Transactions from an external account (user account) to a contract account can trigger code, which can execute many different actions.
On the Solana blockchain, Program Derived Accounts (PDA) are referred to as the account whose owner is a program and are designed to be controlled by a specific program. With PDAs, programs can programmatically sign for certain addresses without needing a private key. These serve as the foundation for Cross-Program Invocation through which Solana-based apps are composable with one another.
Smart Contract Life cycle
On an EVM-based blockchain, like BSC, there are four phases involved in the life cycle of smart contracts.
Creation of the smart contract
Freezing of the smart contract
Execution of the smart contract
Finalization of the smart contract
On BSC, Smart contracts are usually written in a high-level language, like Solidity. However, in order to run, they are compiled to the low-level bytecode compatible to run on the EVM. Once compiled, the bytecode is deployed on the BSC platform using a special contract creation transaction. Each contract is identified by a BSC contract address, which is derived from the contract creation transaction as a function of the originating account and nonce. The address of a contract can be used in a transaction as the recipient, sending funds to the contract, or calling one of the contract’s functions.
In the case of Solana, on-chain programs are compiled via the LLVM compiler infrastructure to an Executable and Linkable Format (ELF) containing a variation of the Berkeley Packet Filter (BPF) bytecode. Because Solana uses the LLVM compiler infrastructure, a program may be written in any programming language that can target the LLVM's BPF backend. Solana currently supports writing programs in Rust and C/C++. BPF provides an efficient instruction set that can be executed in an interpreted virtual machine or as efficient just-in-time compiled native instructions.
Interaction with Smart contracts
a. Solana execution model vs EVM model: EVM follows a stack-based model for the execution of transactions and smart contracts. On the other hand, Solana offers a parallel execution model. Its Sealevel runtime is a concurrent transaction processor. Transactions specify their data dependencies upfront and dynamic memory allocation is explicit. By separating program code from the state it operates on, the runtime is able to perform concurrent access. Transactions accessing only read-only accounts are executed in parallel whereas transactions accessing writable accounts are serialized. The runtime interacts with the program through an entry point with a well-defined interface. The data stored in an account is an opaque type, an array of bytes. The program has full control over its contents.
With a multitude of blockchain platforms available for development in the Web3 domain, BNB Chain has emerged amongst the top ranks. BNB Chain offers developers speed, security, efficiency, and low cost with ensured scalability. In this article, we have provided a detailed comparison of the architecture of the BNB Smart Chain and the Solana network. This article is aimed at giving readers understand the differences in the underlying architecture.
Blockchain technology has gained superlative popularity over time, proving that it is here to stay. This popularity has resulted in a multitude of blockchain platforms that offer unique features for dapp development. As every blockchain platform has its pros and cons and differs from each other in terms of the underlying architecture, working mechanisms, etc., it is possible for blockchain-based projects and crypto tokens to migrate from one blockchain platform to another. For instance, from Solana to BNB Smart Chain (BSC), for better user experience by leveraging the innovative features of BSC.
Even though it has been only two years since its launch, BNB Chain has quickly gained a lot of popularity because of its compelling features of low cost and faster transaction rate. BSC is the largest network with an all-time high daily active users (DAU) of 2.2M on Dec 2021. At the time of writing, the current value of DAU of BNB Smart Chain is 1.2M with daily network usage of approximately 13% and more than 3.6B transactions, along with a TVL of 6.14B. Being the largest smart contracts-powered blockchain ecosystem, several projects that are based on other blockchain platforms are now migrating to the BNB Chain platform.
In this article, we dive into token migration from a non-EVM chain, Solana, to BSC. We provide an overview of what tokens are, supported tokens by BSC, migrating tokens from Solana to BSC, and migration of vested tokens.
Technically, "token" can be described as a term that is used for referencing cryptocurrencies or crypto-assets. However, with advancements in standards for cryptocurrencies and assets, the term token can be used in different contexts, since now tokens are functional in a wide spectrum of use cases. For example,, tokens can take up the form of cryptocurrencies, as well as, they can also be digital assets that run on top of other cryptocurrencies' blockchains. Nevertheless, all tokens in all forms can generally be traded or held like any other cryptocurrency.
In a blockchain-based decentralized ecosystem, tokens play a very important role in accomplishing various different purposes within a decentralized application's (dApp) ecosystem. Broadly, tokens can be divided into two categories, fungible and non-fungible. Fungible tokens are essentially representations of interchangeable assets on a blockchain and are usually used as cryptocurrencies. Other important classifications of tokens based on usage are as follows:
DeFi tokens: DeFi protocols and dapps are aimed at rendering traditional financial-system functions (lending, borrowing, saving, insurance, trading, etc.). DeFi tokens essentially power DeFi apps and protocols and are programmable to perform payments as well as transaction flows. These are also tradable or can be held like any other cryptocurrency.
Utility Tokens: are designed to serve particular purposes within a specific application/protocol's ecosystem. These further allow users to be part of the decision-making process of a specific network. Additionally, utility tokens are unique to their ecosystem and are non-mineable cryptocurrencies. These are usually pre-mined, created all at once, and distributed in a manner chosen by the team behind the project.
Governance tokens: these are specialized tokens that authorize holders the right to vote on issues related to the governance of the development and operations of a blockchain project. It's a method for projects to distribute decision-making power to their communities. This decentralized governance model helps align the interests of the token holders with that of the project.
Non-Fungible Tokens (NFTs): NFTs are used for representing ownership rights to a unique digital or real-world asset. These allow the tokenization of real-world things like art, collectibles, real estate, etc. Ownership of an asset is secured by the blockchain network as no one can modify the record of ownership or copy/paste a new NFT into existence.
Security tokens: are a new class of assets that aim to be the crypto equivalent of traditional securities like stocks and bonds. Their main use case is to sell shares in a company (very much like the shares or fractional shares sold via conventional markets) or other enterprises (for instance, real estate) without the need for a broker. Major companies and startups have been reported to be investigating security tokens as a potential alternative to other methods of fundraising.
With blockchain technology gaining unprecedented popularity there is a multitude of blockchain projects issuing their own tokens on different blockchains. It is important to make sure that these tokens are compatible with the underlying blockchains and adhere to the platform's token standards.
To ensure compatibility, interoperability, and security, token standards are issued. token standards are designed to help avoid fraud, technical incompatibilities between tokens, and issuance of tokens not aligned with the blockchain's principles. These are essentially a set of rules defining the issuance and implementation of new tokens. Some of the most commonly included rules in these token standards include the token's total supply limit, minting process, burning process, and process for performing transactions using the token.
One of the most widely used token standards is the ERC standard. Ethereum Request for Comments (ERC) is a set of rules defining the issuance and implementation of tokens on the Ethereum Blockchain. ERC20 is a technical standard that describes a common set of rules that should be followed for a token to function properly within the Ethereum ecosystem. It is one of the most commonly used standards and is usually used for fungible tokens in the form of cryptocurrencies. Other popular ERC standards are ERC-721 (NFTs) and ERC-1155 Multi-Token standard.
Similarly to ERC, BNB Chain defines its own set of standards for token issuance, management, and implementation known as BEP (BNB Chain Evolution Proposals). BEPs are token management rules and pre-defined criteria for launching on-chain assets on BNB Chain. The most popular BEP standards are BEP2 and BEP20. BEP2 is the native coin of the BNB Beacon Chain. Whereas, BEP20 is popular for use on BSC. It is to note here that BEP20 is very similar to ERC20 and extends its functionality. Note that, BNB which is the native token of the BNB Chain ecosystem, is also a BEP20 token.
Famous for its parallel execution engine, the Solana blockchain was launched in 2017 and is currently amongst the popular blockchain ecosystems. SOL is the native token of the Solana ecosystem and is essentially a Utility token. SOL uses the SPL protocol. Similar to the ERC standard on Ethereum and BEP on BSC, Solana Program Library (SPL) is the token standard of the Solana blockchain. SPL is a collection of on-chain programs that target Solana's "Sealevel" parallel runtime. The Token Program on Solana defines a common implementation for Fungible and Non-Fungible tokens. The SOL token has two main use cases:
Paying for transaction fees incurred when using the network or smart contracts.
Staking tokens as part of the Proof of Stake consensus mechanism.
BNB Chain is an ecosystem that runs on two blockchain giants, namely, BNB Beacon Chain (BC) and BNB Smart Chain (BSC). The native token standard for BNB Beacon Chain is BEP2, while the native token standard for BNB Smart Chain is BEP-20. BNB Ecosystem's native currency, BNB, initially launched as an ERC20 token, is a BEP2 token.
The BNB Beacon Chain is responsible for the governance of the BNB Chain ecosystem which includes staking and voting. BEP2 is the token standard for BNB Chain's native currency, BNB, on Binance's crypto exchanges. It is a unique token standard, BEP2 is not compatible with blockchains other than BNB Chain. Additionally, BNB in the BEP2 format can only be used as a transaction fee on both Binance cryptocurrency exchanges. One limitation of BEP2 is its lack of support for smart contract development. For more information, you can read the full BEP2 proposal here.
BSC is the blockchain component of the BNB Chain that provides its users with a smart contract facility and is a platform for dApp development. BEP20 is a token interface standard for creating token contracts on BSC. The BEP20 tokens are designed to be compatible with BEP2 andERC20. It extends ERC20 for compatibility with EVM chain and Ethereum smart contracts. Other than the ERC20 functionalities, the BEP20 standard contains additional interfaces, such as getOwner and decimals. For more information on BEP20, read the full proposal here.
Often blockchain projects begin as whitepapers promising innovative technologies to follow in the future. However, there can be multiple twists and turns in the process of transforming from a design paper to a real product. One such can be choosing to move to an entirely different blockchain than that proposed initially. In such scenarios, it is possible for projects to require a token migration, also known as a token swap. Token migration is a process that involves transmitting a token holder's balance on one blockchain to another blockchain. In this section, we cover token migration from Solana to BSC.
The process of bridging between Solana and BNB Smart Chain (BSC) is a little difficult because they are not compatible chains. There are two options to migrate your tokens from Solana to BSC. First, you can use cross-chain bridges to migrate the tokens to BSC from Solana. The second is to create new tokens on the BSC network, deposit equivalent amounts to the holders and discontinue the previously deployed token on Solana. In this section, we provide readers with a guide on how to create custom BEP20 tokens on BSC and later how to bridge tokens from Solana to BSC.
BEP20 is BSC's equivalent version of the ERC20 token standard for Ethereum. The difference between the two is that BEP20 Tokens are only compatible with the BSC network. Nevertheless, as BSC is Ethereum Virtual Machine (EVM) based both ERC20 and BEP20 are practically identical in both specification and implementation. In this section, we provide you with a walkthrough on how to create custom BEP20 tokens.
For this tutorial, we will be using Remix IDE for compiling and deploying BEP20 token smart contracts onto the BSC test network.
There is no need for any local environment settings for compiling and deploying Solidity smart contracts on BSC using the Remix IDE.
All you require is a browser-based Web3 wallet (e.g. MetaMask) to interact with the BSC Testnet and deployed contracts. If you are already using MetaMask, it is recommended to create a new account for testing with Remix IDE. You can do this from the account menu, which appears when you click on the account avatar in the top right corner of the MetaMask interface, for more details refer here.
You must set up all of the following prerequisites to be able to deploy your solidity smart contract on BSC:
Choose OpenZeppelin's ERC20 template; give a meaningful name to your workspace and press ok.
Remix will create a smart contract "MyToken.sol" for you as well as will import any dependencies. We can edit this "MyToken.sol" to create our own ERC20 tokens.
Rename the MyToken.sol file to the name of your token, BEP20.sol in our case.
Compile the smart contract
Deploy the smart contract. Make sure that your MetaMask wallet is configured for use with the BNB Smart Chain Testnet. Select inject provider in the environment variable and make sure you see your connect account address in the Account field. Click on the Deploy button to deploy the BEP20 token smart contract. Our smart contract takes initialSupply as a parameter to the constructor that would create that many tokens at the time of deployment.
The input field next to the Deploy button is the place to specify the initialSupply parameter. For e.g. if you want to create 100 tokens, then pass 100000000000000000000 and then click on "Deploy".
You will need to accept a MetaMask transaction as it will cost BNB to deploy something to the network. Confirm the transaction by pressing the confirm button on the metamask notification
To view your tokens in your metamask wallet follow this tutorial.
With several different blockchain platforms available for development, of the varied underlying architecture, consensus mechanism, etc., interoperability and cross-communication between these platforms with respect to token and data transfers can be nearly impossible. Blockchain bridges are designed to overcome this hindrance of interoperability and provide a secure mechanism for decentralized token transfers.
A cross-chain bridge connects independent blockchains and enables the transfer of assets and information between them, allowing users to access other protocols easily. One thing critical to understand is how cross-chain bridges actually work. Cross-chain bridges work by "wrapping" tokens in a smart contract and issuing native assets you can use on another chain. For e.g., wrapped BTC (wBTC) is an ERC-20 token that uses BTC as collateral. Users must deposit BTC on the Bitcoin blockchain before receiving wBTC tokens on the Ethereum network.
In this section of the article, we describe how to use the Portal Bridge for bridging tokens from Solana to BSC. One thing to remember is to be able to see your deployed custom token on the Portal bridge, you will have to get your token whitelisted by the Portal bridge's team. For this tutorial, we will be bridging a more commonly supported USDC token from the Solana blockchain to BSC using the Portal Bridge.
Wormhole's Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain. This tutorial can be used to bridge your assets between Solana and other chains, including BSC, using Wormhole.
Using Portal Bridge to Bridge Tokens from Solana to BSC
One thing to remember is to be able to see your deployed custom token on the Portal bridge, you will have to get your token whitelisted by the bridge's official team. For this tutorial, we will be bridging a more commonly supported USDC token from the Solana blockchain to BSC using the Portal Bridge.
The bridging process involves four primary steps, as indicated on the landing page:
Source selection
Target selection
Sending tokens
Redeeming tokens
In this guide, we will be bridging from Solana to BSC.
Step 1: Select Source Chain, Target Chain, and Source Token
On "Source," select the chain from which you want to bridge. In this case, the tokens are on the Solana blockchain, so Solana is selected as our "Source."
"Target" is the chain to which the tokens will be bridged. Select BNB Smart Chain as your "Target."
After selecting Source and Target, click "Connect." This will prompt a pop-up from the Source wallet, which is Phantom in this guide.
When the wallet is connected, the "Select a Token" button will appear.
Select the Source Token. These are the tokens that you want to bridge or swap from Solana. In this guide, we'll be bridging USDCso from Solana to BSC.
Note: The "Featured" tokens at the top of the drop-down menu are those with liquidity on Solana, and there are links to the exchanges where you can swap these tokens. Do not select tokens besides those in the Featured category. You may accidentally bridge a token with little or no liquidity on Solana, and you won't be able to swap them.
After selecting the token you want to bridge, the interface will display the current balance of the selected Source Token.
Select the amount of tokens you want to bridge. Then, click "Next."
Step 2: Select Target Chain and Connect Target Wallet
Select your Target Chain. This is the chain to which you want to bridge your tokens.
Click "Select Wallet." This will prompt a pop-up from the native wallet of your Target Chain. In this guide, we'll be using Metamask.
On the pop-up, click "Connect."
The "Create Associated Account" button will now appear. Click this button to create a token account in your Metamask wallet where your tokens will appear.
When you click "Create an Associated Account," a pop-up from the Target Wallet will appear. Click "Approve."
Step 3: Send Tokens
Your Source Wallet will now be connected, and your token's associated account will be ready. Click "Transfer" to initiate the transaction.
Click "Confirm" in the site pop-up.
Click "Confirm" in your wallet pop-up. This will approve paying gas to transfer tokens from the chain you want to bridge from. Note: You will be paying transaction fees on the sending as well as receiving side.
Step 4: Redeem Tokens
Click "Redeem" to initiate the transfer to your Target Wallet.
A series of pop-ups (typically four) will appear from your Target Wallet.
Approve each of these transactions to continue.
Remember: Transaction fees on the receiving side need to be paid in the Target chain's native token.
In crypto-space, Vesting is known as the process of locking and distributing purchased tokens within a particular timeframe called the Vesting Period. Vested tokens can be described as a certain amount of tokens that are held aside for a particular time period usually for the team members, partners, advisors, and others who are contributing to the development of the project.
Vested tokens are locked in a smart contract and released automatically until certain conditions are met. Vesting basically gives the impression that the team is highly interested in the project, and aims to continue working on the project development. Additionally, vesting lowers market price manipulations.
There are two options available for migrating vested tokens from Solana to BSC.
Migrate the vesting contract and move the vesting schedule from Solana to BSC.
Migrate the tokens and release them as per schedule.
Vesting is essentially a smart contract that has all of the vested tokens locked up which are released over a time period automatically when certain conditions are met. One of the possible ways to migrate vested tokens from the Solana blockchain to BSC is to migrate the vesting contract from the Solana blockchain to BSC. One thing to remember here is that Solana uses the RUST programming language for writing smart contracts. Whereas, smart contracts in BSC are usually written in the Solidity programming language. This language incompatibility means that either you would have to re-write your smart contract in Solidity from scratch or use rust-compatible EVM solutions on BSC for running rust-based smart contracts.
As both Solana and BSC have completely different token standards, even though the tokens can be bridged, a better approach is to mint new tokens on the BSC. The migrating project's team can ask the holders of its vested tokens to exchange the already bought vested tokens with a newly created equivalent token on BSC within a given time frame and continue the release of vested tokens as per schedule. Another way is to take a snapshot of the vested token holders and update their wallets with an equivalent amount of new tokens and continue with the vesting schedule and release of tokens.
With several advantages and an ecosystem that supports Web3 development, BNB Chain has gained much attention from developers and blockchain projects. Several blockchain projects are now choosing to migrate their blockchain projects and crypto tokens from non-EVM-based chains like Solana to BSC which is an EVM-based chain. In this article, we provided a brief overview of token migration from Solana to BSC, covering an overview of crypto tokens, how to create custom tokens on BSC, how to bridge assets from Solana to BSC, and how to migrate vested tokens.
Select mirror function and fill-in with your BEP20 address
The value here should be no less than mirrorFee+ relayFee.
Time stamp should be greater than unix_timestamp(now()). The difference should be between 120 and 86400. It's recommended to use unix_timestamp(now())+1000
Binance Dex Support: Go to page https://www.bnbchain.org/en, click on the help button then click contact us. It will generate a ticket to Customer Service team.
Validator chat channels
#validator-support General support channel for any Validator related queries
#node-support General support channel for any node related queries
#Dev-announcements Can be accessed for any information related to development announcements.
-
+
diff --git a/docs/nft-metadata-standard.html b/docs/nft-metadata-standard.html
index 6340e8e3f8..22faf02847 100644
--- a/docs/nft-metadata-standard.html
+++ b/docs/nft-metadata-standard.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
The below metadata structure, allows the BSC Marketplace to read and display the details about the assets which your NFTs represent.
A human-readable description of the item. Markdown is supported. Max 500 characters.
image
This is the URL to the image of the item. It can be just about any type of image. A 350 x 350 image is recommended.
animation_url
This is the URL to a multi-media attachment for the item. The file extensions GLTF, GLB, WEBM, MP4, M4V, OGV, and OGG are supported, along with the audio-only extensions MP3, WAV, and OGA.
animation_type
This is the file format of the multi-media attachment provided from animation_url.
external_url
This is the URL that will appear below the asset's image on the marketplace and will allow users to leave the marketplace and view the item on your site.
attributes
These are the attributes for the item to describe the detail of the NFT. (see array below)
Here trait_type is the name of the trait, value is the value of the trait, and display_type is a field indicating how you would like a numeric value should be displayed. For string traits, you don't have to worry about display_type.
All traits included in the attributes will be displayed in Attribute.
If you don't want to have a trait_type for a particular trait, you can include just a value in the trait and it will be set as a generic attribute.
There are 3 supported options for display_type: number will show the value in pure number, boost_number allows you to show the number with Plus or Minus symbol, and boost_percentage is similar to boost_number but will show a percent sign behind the number.
After the preview two tutorials, you must have learned how to write NFT smart contract and deploy it on BSC testNet. The most important part for any NFT project is that where your NFT assets are stored. If you want to avoid the risk of losing your NFT assets or not able to access them, storing your NFTs on decentralized network is the better option for you.
So in this tutorial, we will walk you through the process of storing your NFT assets on decentralied storage network, like IPFS & Filecoin. We will use NFT.Storage in this tutorial since it provides easy to use API/SDK for developers to upload their NFT assets on both IPFS and Filecoin.
NFT.Storage is a storage service that lets you store off-chain NFT assets decentralized for free. Your NFT assets will be stored on both IPFS and Filecoin for the guaranty of fast content-addressing and retrieval on IPFS, as well as verifiable long-term storage on Filecoin.
NFT.Storage provides multiple ways to upload your NFTs, from user-friendly web UI and NFTUp application to easy to use API to support developers. So it is especially useful for individual creators who are minting NFTs, or NFT tooling developers looking to support creators and collectors!
In this tutorial, we will more focus on developers who is integrating NFT.Storage into their application to Mint NFTs. If you want to learn more about different ways to upload and manager your NFTs, you can check this Quick Start docs.
If this is the first time you use NFT.Storage, you need to create a NFT.Storage account to get a API token which you can use in your applications when you upload NFTs.
You can sign up an account for free using either your email or GitHub.
The NFT.Storage JavaScript client makes it simple to upload files and create ERC-1155 compatible NFT metadata in your NFT applications. Both NFT and its metadata will be stored on IPFS and Filecoin, you will receive a IPFS URL for you metadata which you can use to mint your NFT.
We will use a simple node JS script to demonstrate the code to upload NFT and receive the corresponding IPFS URL for its metadata. You can easily integrate this function in your JavaScript or TypeScript applications.
You'll need Node.js version 16 or later for this example.
Make a new JavaScript project.
mkdir nft-storage-quickstart cd nft-storage-quickstart npm init
NPM will ask a few questions about your project and create a package.json file.
Install nft.storage client in your project.
Run the following command to install the latest version of nft.storage package, and also install mime package for the file types.
npminstall nft.storage npminstall mime
Create a file called upload.mjs and open it with your VS Code.
Below is the code you need to upload an image with ERC-1155 compatible NFT metadata.This code here will be used only as example, you can add similar upload logic in your application.
import{NFTStorage,File}from"nft.storage" importfsfrom'fs' importdotenvfrom'dotenv' dotenv.config() //This the the API token you have created earlier which is added as one env variable. constAPI_KEY= process.env.NFT_STORAGE_API_KEY asyncfunctionstoreAsset(){ const client =newNFTStorage({token:API_KEY}) const metadata =await client.store({ name:'ExampleNFT', description:'My ExampleNFT is an NFT example!', image:newFile( [await fs.promises.readFile('MyExampleNFT.png')], 'MyExampleNFT.png', {type:'image/png'} ), }) console.log("Metadata stored on Filecoin and IPFS with URL:", metadata.url) } storeAsset() .then(()=> process.exit(0)) .catch((error)=>{ console.error(error); process.exit(1); });
The main part of the script is the storeAsset function. It creates a new client connecting to NFT.Storage using the API key you created earlier. Next we introduce the metadata consisting of the name, description, and image. Note that we are reading the NFT asset directly from the file system from the assets directory. At the end of the function, we will print the metadata URL as we will use it later when creating the NFT on BNB Chain.
Run your script with nodeJS
Let's execute the upload logic by running the script and see the output.
node upload.mjs
The output should look like down blow. You can directly use the IPFS URL to mint NFT token, or use the URL of NFT.Strorage gateway. For instance, https://nftstorage.link/ipfs/<CID of your NFT>/metadata.json
Metadata stored on Filecoin and IPFS with URL: ipfs://bafyreihegljuej4y4ai5ftzb2rdztseb5mmjzba5f5xcdktgd43rkoxhw4/metadata.json
Now you have your NFT assets stored on IPFS and Filecoin, you can access it via NFT.Strorage gateway and you are ready to mint your NFT. Please record the metadata url which we will use to mint NFT later.
This tutorial will more focus on how to store NFT assets on IPFS and Filecoin other them teaching how to develop NFT smart contract. If you wish to learn how to deploy NFTs on BSC, you should learn it from Deploy NFTS on BSC using Truffle.
In this section, I will simply use Remix to write NFT contract, deploy and invoke it via MetaMask. Before we move forward, let's make sure you have the following items ready.
Before deploying your NFT smart contract, make sure you switch the network to BSC TestNet on MetaMask and also have some test tokens to pay for transaction fees.
On the Remix IDE, go to Deployment page and make sure you choose Injected Provider - MetaMask for the environment. Now, you can click the Deply button and confirm the transaction on MetaMask.
Once the deployment transaction is confirmed on-chain, you will be able to verify the transaction and contract on BSC TestNet blockchain explorer.
You can also directly interact with the deployed NFT contract on Remix IDE. Try to invoke the name and symbol methods to verify if this is the NFT contract you deployed.
Now, we are all set to mint the NFT. Instead of using metadata storing on centralized server, we will use the metadata which we stored on IPFS & Filecoin using NFT.Storage in previous steps.
We will copy the NFT metedata URL, something like ipfs://bafyreihegljuej4y4ai5ftzb2rdztseb5mmjzba5f5xcdktgd43rkoxhw4/metadata.json and mint NFT on Remix IDE.
On Remix IDE, go to the Deployed Contracts section and find mintItem method.
Paste the NFT metadata URL in the tokenURI params field, and click transact.
You will need to confirm and sign the transaction when MetaMask popup for confirmation.
Verify your newly minted NFT
Once the transaction is confirmed on BSC TestNet, you will be able to verify whether your NFT is minted successfully or not by invoking either balanceOf or ownerOf. I will take balanceOf as the example here.
You can also verify your NFT on Opensea Testnets once you connect to MetaMask account. Then you will be see the freshly minted NFT under your account.
BSC supports different NFT standards like ERC-721 and ERC-1155. Both of these are two different token standards used for creating and managing non-fungible tokens (NFTs).
ERC-721: ERC-721 is a well-established Ethereum token standard for NFTs. Each ERC-721 token is unique and distinct, making it ideal for representing one-of-a-kind assets, such as digital art or collectibles. These tokens cannot be subdivided and are typically used for single, indivisible assets.
ERC-1155: ERC-1155 is a more versatile token standard, designed to support both fungible and non-fungible tokens within a single contract. It allows developers to create a range of token types, making it more efficient for managing a variety of assets, from unique NFTs to fungible tokens like in-game currency. This standard reduces the gas costs associated with deploying multiple contracts for different token types.
The major differences between them are:
Uniqueness: ERC-721 tokens are unique and represent one distinct asset, while ERC-1155 tokens can represent both unique and fungible assets within the same contract.
Gas Efficiency: ERC-1155 is more gas-efficient because it allows multiple types of tokens to be managed in a single contract, reducing the overhead of deploying multiple contracts for different token types.
Use Cases: ERC-721 is typically used for one-of-a-kind NFTs, whereas ERC-1155 is suitable for projects requiring a combination of unique and fungible tokens, like blockchain-based games with various in-game items and currencies.
Interoperability: ERC-721 is widely used on Ethereum, while ERC-1155 is more commonly associated with the Binance Smart Chain, but it can also be deployed on Ethereum and other blockchains, making it a more flexible option for developers.
Flexibility: ERC-1155 offers more flexibility in designing token ecosystems because it can support a broader range of token types, allowing developers to adapt to various project requirements.
In this tutorial, we provide a step-by-step guide to the readers on how to issue Non-fungible tokens (NFTs) (ERC721/1155) on the BNB Smart Chain (BSC) Testnet using the Black IDE. This is a detailed guide to learning how to issue, mint and transfer NFTs on the BSC Testnet. The technology stack used in this tutorial includes Solidity, Truffle, MetaMask, and BlackIDE.
Solidity: one of the most popular object-oriented high-level smart contract programming languages. For more details on Solidity, refer here.
MetaMask Wallet Browser Extension: we recommend using the Metamask Chrome extension. It is a web wallet that allows connecting the chrome browser to any valid blockchain network.
Black IDE: Black IDE is an integrated development environment (IDE), making developing EVM-compatible smart contracts faster and easier. Black IDE offers both desktop and web (Black IDE Web) applications.
We aim to keep this tutorial as simple as possible and hence tend to use as minimal resources as possible and have used the following tools in this tutorial.
Metamask Wallet
Ensure that you have the Metamask Wallet extension installed and running on our browser.
Configure the Metamask wallet for use with the BSC Testnet. Use the following details to add the BSC Testnet. For further details, refer here.
Black IDE: both desktop app and web app are available and it is up to your convenience to choose from. For this tutorial, we used the desktop app as the web app lacks support for importing OpenZeppelin Contracts.
Download/Install any dependencies required by BlackIDE
Click on the New button next to the projects to create a new project.
Specify the location where you want to save your project on your device, the project name, e.g. “BSC-NFT”, and select the project type from the dropdown list as “Basics- ERC20, ERC721, & ERC1155 (v31+)”. Then click the Create button to create the project.
Remember the smart contract in this tutorial is just a sample, you can always modify and be innovative.
Copy the following code into your smart contract file. We have used the contract code from this repo.
Remember to change the MINT_PRICE, MAX_SUPPLY, name, and symbol of the token as per your need. Also, remember to change the _baseURI as per your token.
Click on the config.json file to change the default setting. Change the main file name to the name of your contract, BSC-NFT.sol in our case. Similarly, change the name of the smart contract to deploy, BSCNFT.json in our case.
In order to connect the Black IDE to the BSC Testnet, click on the dropdown icon on the network menu in the top right corner and then select Testnet under the BNB Chain label.
Click on the icon in the bottom left corner of the IDE to generate new keypair to perform transactions. You can skip this step if you already have generated a keypair. On the Keypair Manager, click on the CREATE button to generate new keypair.
Specify your desired name for the keypair, in our case BSC-Testnet-Key. Then click on the CREATE button. Remember to keep your private keys securely and not share them with anyone.
Select the appropriate Solidity compiler version from the bottom right corner of the IDE, Solc (0.8.4), in our case.
Click on the Build icon to build your smart contract. Upon successful build, the project navigation pane reflects a new folder named build. This folder contains contracts folder that has json files of the contracts built. All of the contracts imported in our BSCNFT contract are also built and imported as json files.
After successfully building your contract, it’s time to deploy the contract. Click on the Deploy icon for deploying your smart contract. Specify the details for your contract, as shown below, then click on the Estimate & Deploy button. The wizard will auto-estimate and fill the gas limit for your contract. Then click the Deploy button.
Deployment details will pop-up, as shown in the figure below.
The status of the transaction will be updated to confirmed after the transaction is confirmed as shown in the figure below
You can also view this transaction by clicking on the transaction icon in the bottom left on the IDE.
Interact with deployed smart contract and Mint NFTs
You can also interact with the contract using the different functions. Click on the Transactions Icon on the bottom-left corner of the IDE and then transaction of deployment of your smart contract. On the transaction details, click on the contract address to access the functions to interact with the smart contract. The left most column has all the Write Functions. The middle column has the View Functions and the right most column has the Events details.
As per our smart contract, when the contract is deployed, unless the NFTs are minted they won’t be visible in the wallet.
Create another keypair as defined previously. We will be issuing i.e. minting NFTs to the public address of this new keypair.
To mint i.e. issue an NFT to a specific user we use the “safeMint” function of the deployed smart contract. As shown in Steps 1 and 2 in the figure below, navigate to the deployed contracts, then in the left-most column click the drop-down menu to view the list of write functions available for use with the deployed contract. Select the “safeMint” function.
Use the safeMint function to mint new NFTs to a specific user address. As shown in figure above, steps 3 to 6, enter the “ETH to send” as the minting price of NFT, as per our smart contract the minting price is 50000000000000000 Wei, i.e., 0.05 ETH. We entered 0.06 ETH to cover the transaction charges as well. Then select the address to whom you want to issue (mint) an NFT to. Here, for the To address use the newly generated keypair in the section above. After this, click the transact button to execute the safeMint function. For the Signer, ensure that you are using the account that was used to deploy the smart contract.
To confirm what transfers have occurred, execute the Transfer event from the right most column. This will display the list of NFT transfers along with NFT token id, as shown in the figure below.
To confirm owner of an NFT, use the ownerOf function. Pass the token id as input to the function, as illustrated in the figure below.
On the receiving end, the user can import the NFT token details into their Metamask wallet to view the assets. Please note that currently, Metamask Web Extension does not support the use of NFTs however, the mobile app version does support it. For the next steps to view the owned NFTs in your Metamask wallet, we will be using the Metamask Mobile Application.
Open Keypair manager on the Black IDE and copy the private key of the keypair that you minted i.e., transfer NFT.
On the Metamask wallet mobile app, import an account using this key pair. Enter the private key copied in the previous step and click import.
After importing account, the next step is to add the BSC Testnet configuration to the wallet. Ensure that you are using the same account whose pubic address was issued the NFT.
Ensure that your account is connected to the BSC Testnet. Also, ensure that you have enough BNB test tokens in your account. If not, you can use the BSC Testnet Faucet to acquire some, as mentioned earlier.
To view the owned NFT assets your Metamask Mobile Wallet, click on the NFTs tab and then on the Import Tokens. Fill in the NFT details. In the address field, pass the address of the deployed contract and in the Id field pass the tokenID. Then click the Import button.
In this tutorial, we provided a step-to-step guide on how to issue, mint and transfer NFTs on the BSC Testnet using the BlackIDE from Obsidian Labs.. The technology stack used in this tutorial includes Solidity, Truffle, MetaMask, and BlackIDE. Check out our GitHub for more tutorials on how to develop on BSC. If you have any questions or are stuck, reach out to us on our Discord Channel.
Blockchain oracles are entities that connect blockchains to external systems, thereby enabling smart contracts to execute based upon inputs and outputs from the real world. Simply put, oracles provide a mechanism for the decentralized Web3 ecosystem to access existing data sources, legacy systems, and advanced computations.
Following is the list of Data Oracles supported by BNB Chain.
Binance Oracle: Binance Oracle, a decentralized Web3 Oracle, a data feed network that connects real-world data to blockchain smart contracts. Binance Oracle will enable smart contracts to run on real-world inputs and outputs, starting with the BNB Chain ecosystem. Refer here for API Reference.
Band Protocol: Band Protocol is a cross-chain data oracle platform that aggregates and connects real-world data and APIs to smart contracts. Refer here for API Reference.
Chainlink: Securely connect smart contracts with off-chain data and services Chainlink decentralized oracle networks provide tamper-proof inputs, outputs, and computations to support advanced smart contracts on any blockchain. Refer here for API Reference.
Pyth: Pyth delivers real-time on-chain market data. Refer here for API Reference.
DIA: DIA provides customizable oracles tailored to individual dApp requirements, with flexibility in data sources, filters, pricing, and update methods. Drawing trade data from 80+ sources like CEXs, DEXs, and NFT marketplaces, DIA ensures transparency and control. Their product suite includes price feeds for 20,000+ cryptocurrencies, NFTs, LSTs, and more. Refer here for API Reference.
Build N Build Chain aka BNB Chain, one of the most popular blockchains in the world, dedicates to delivering its core infrastructure necessary for future public adoption, and always remains as a community-first and open-source ecosystem built on a permissionless and decentralized environment.
BNB Chain is composed of two blockchains - BNB Beacon Chain (BC) and BNB Smart Chain (BSC). The BNB Beacon Chain is the blockchain component that is responsible for the governance of the BNB Chain and manages staking and voting on the BNB Chain. Whereas, the BNB Smart Chain is the blokchain component that is EVM compatible, consensus layers, and with hubs to multi-chains.
BNB Chain, one of the most popular blockchains in the world, dedicates to delivering its core infrastructure necessary for future public adoption, and always remains as a community-first and open-source ecosystem built on a permissionless and decentralized environment.
BNB Beacon Chain - BNB Beacon Chain is the staking and governance layer of the BNB ecosystem.
BNB Smart Chain (BSC) - An EVM-compatible blockchain that brings programmability and interoperability to the BNB ecosystem.
zkBNB - zkBNB is an infrastructure that is built on zk-Rollup architecture for developers that helps them to build large-scale BSC-based apps with higher throughput and much lower or even zero transaction fees.
opBNB - opBNB network is the Layer 2 scaling solution for the BNB Smart Chain powered by the bedrock version of Optimism opStack.
BNB Greenfield - BNB Greenfield introduces an entirely new structural and economic paradigm for data in the Web3 era. The ownership, usage, and monetization of data are now possible first and foremost for users, as well as all participants in the BNB Chain ecosystem.
BNB stands for "Build and Build". Along with fueling transactions on BNB Chain (similar to gas on Ethereum), BNB also acts as a governance token. Holding BNB gives you the right to make your voice heard and is necessary for participation in BNB Chain's decentralized on-chain governance. With this name change also comes more advancements to benefit users, projects, and developers connected to the BNB Chain community.
Currently, BSC offers a considerable block size of 140M gas ceiling. We plan to introduce a more advanced logic for blockchain storage and BSC client to cover it and allow further expansion. Currently, to fully sync the BSC blockchain, validators need extensive storage and time. Scaling down the validator and node operator requirements is necessary to enable a seamless BSC experience.
New technologies, like Erigon, are being verified to decrease both time and storage demands for validator nodes while performing full sync.
Working with validators and infrastructure providers to deploy new solutions to address this issue, such as
Parallel EVM
Better block process pipeline
Improved state caching
Fast sync mode
Distributed nodes
Introduce more validators to join the block production of BSC
Innovation never sleeps, and it's clear that the future of BNB Chain goes into a world of over 1 billion users. BNB Chain's mission is to build the infrastructure that powers the world's parallel virtual ecosystem, and BNB Chain's commitment to the community is that it will be:
Details: Anyone can submit a slashing request on BC with the evidence of Double Sign of BSC, which should contain the 2 block headers with the same height and parent block, sealed by the offending validator.
Offline Slash: 50BNB
Details: If a validator misses more than 50 blocks every 24h, the blocking reward for the validator will not be relayed to BC for distribution but shared with other better validators. If it misses more than 150 blocks every 24h, then this will be propagated back to BC where another Slashing will happen
Rewards for submitting double-sign evidence: 1000BNB
Details: Anyone can submit a slashing request on BC with the evidence of Double Sign of BSC, which should contain the 2 block headers with the same height and parent block, sealed by the offending validator.
Offline Slash: 30BNB
Details: If a validator misses more than 50 blocks every 24h, the blocking reward for the validator will not be relayed to BC for distribution but shared with other better validators. If it misses more than 150 blocks every 24h, then this will be propagated back to BC where another Slashing will happen
Rewards for submitting double-sign evidence: 1000BNB
Double-Sign Jail time: 2^63-1 seconds
Downtime Jail time: 4h
Too Low self-delegation Jail time: 4h
-
+
diff --git a/docs/proxy.html b/docs/proxy.html
index e86a74a4d2..46ba322cdf 100644
--- a/docs/proxy.html
+++ b/docs/proxy.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
Here’s what you’d need to do to fix a bug in a contract you cannot upgrade:
Deploy a new version of the contract
Manually migrate all the states from the old one contract to the new one (which can be very expensive in terms of gas fees!)
Update all contracts that interacted with the old contract to use the address of the new one
Reach out to all your users and convince them to start using the new deployment (and handle both contracts being used simultaneously, as users are slow to migrate)
There are several approaches that allow us to make some changes to smart contracts.
Separate logic and data
By using this approach, data will be read from a designated data contract directly. This is a relatively common approach that is also used outside of Solidity. One of the main disadvantages of this approach is that you cannot change the interface of contracts external to the entire system, and you cannot add or remove functions.
Delegatecall Proxy
delegatecall opcode was implemented in EIP-7. It is possible to delegate execution to other contract, but execution context stays the same. As with delegatecall, the msg.sender will remain that of the caller of the proxy contract. One of the main disadvantages of this approach is that contract code of the proxy will not reflect the state that it stores.
It’s worth mentioning that these restrictions have their roots in how the Ethereum VM works, and apply to all projects that work with upgradeable contracts, not just OpenZeppelin Upgrades.
You can use your Solidity contracts in the OpenZeppelin Upgrades without any modifications, except for their constructors. Due to a requirement of the proxy-based upgradeability system, no constructors can be used in upgradeable contracts. To learn about the reasons behind this restriction, head to Proxies.
This means that, when using a contract with the OpenZeppelin Upgrades, you need to change its constructor into a regular function, typically named initialize, where you run all the setup logic:
To test upgradeable contracts we should create unit tests for the implementation contract, along with creating higher level tests for testing interaction via the proxy.
You can first deploy our contract to a local test (such as ganache-cli) and manually interact with it, then deploy your contract to a public test network.
$ npx truffle console --network ganache
We can interact with our contract using the Truffle console.
Note: any secrets such as mnemonics or bscscan keys should not be committed to version control.
Run truffle migrate with the BSC testnet to deploy. We can see our implementation contract 'BEP20TokenImplementation' and the 'BEP20TokenFactory' being deployed.
Deploying 'BEP20TokenImplementation' ------------------------------------ > transaction hash: 0xdcd37a388bf9b2f822eff5b816bd4c9db80bc4f6046e3f922cedca12162d46d9 > Blocks: 3 Seconds: 8 > contract address: 0xB3fbaf029580145885e915B3CAeEd259Edb9DfE1 > block number: 5174292 > block timestamp: 1609990661 > account: 0x133D144F52705cEb3f5801B63b9EBcCF4102f5Ed > balance: 10.648947766 > gas used: 1147250 (0x118172) > gas price: 20 gwei > value sent: 0 ETH > total cost: 0.022945 ETH Pausing for 5 confirmations... ------------------------------ > confirmation number: 2 (block: 5174294) > confirmation number: 3 (block: 5174295) > confirmation number: 5 (block: 5174297) Deploying 'BEP20TokenFactory' ----------------------------- > transaction hash: 0x821c8355aaecc36a9f7fe50d2b3722c840047883a6bf500343393554d8ce3696 > Blocks: 3 Seconds: 8 > contract address: 0xDC1015512AbBC71e57a607A121a4aC9CF05D89BC > block number: 5174300 > block timestamp: 1609990685 > account: 0x133D144F52705cEb3f5801B63b9EBcCF4102f5Ed > balance: 10.629661146 > gas used: 964331 (0xeb6eb) > gas price: 20 gwei > value sent: 0 ETH > total cost: 0.01928662 ETH
To test our upgrade we should create unit tests for the new implementation contract, along with creating higher level tests for testing interaction via the proxy, checking that state is maintained across upgrades.
We will create unit tests for the new implementation contract. We can add to the unit tests we already created to ensure high coverage.
Create uograde.test.js in your test directory with the following JavaScript.
let tx =await bep20proxy.methods.upgradeTo(newInstance.address).send({from: proxyAdmin}); bep20proxy.getPastEvents("Upgraded",{fromBlock:0,toBlock:"latest"}).then(console.log)
There is no need for any local environment settings for deploying solidity smart contracts on BSC using the Remix IDE.
All you require is a browser-based Web3 wallet (e.g. MetaMask) to interact with the BSC Testnet and deployed contracts. If you are already using MetaMask, it is recommended to create a new account for testing with Replit. You can do this from the account menu, which appears when you click on the account avatar in the top right corner of MetaMask interface.
You must set up all of the following Pre-requisites to be able to deploy your solidity smart contract on BSC:
Create a new file, name it HelloWorld.sol, and copy the contract code given below
// SPDX-License-Identifier: MIT pragma solidity ^0.8.15; contract HelloWorld { function sayHelloWorld() public pure returns (string memory) { return "Hello World"; } }
The first line, pragma solidity ^0.8.15 specifies that the source code is for a Solidity version greater than 0.8.15. Pragmas are common instructions for compilers about how to treat the source code (e.g., pragma once).
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain. Learn more about the constructor and memory in the docs.
Now, We have to deploy our smart contract on BNB Smart Chain Network. For that, we have to connect to Web3 world, this can be done by many services like MetaMask, Brave, Portis etc. We will be using MetaMask. Please follow this tutorial to setup a Metamask Account for configuring the MetaMask wallet to use with BSC.
Open Metamask and select Custom RPC from the networks dropdown
Follow the following steps to deploy the HelloWorld smart contract on the BNB Smart Chain Testnet.
Step1: Navigate to the Deployment Page.
Step2: Select Injected Provider in the Environment dropdown
Step3: Confirm the Connection Request on the MetaMask notification.
Step4: Once Metamask is connected to Remix, click on the "Deploy" button which would generate another metamask popup that requires transaction confirmation.
Congratulations! You have successfully deployed a simple Smart Contract on the BSC Testnet. Now you can interact with the Smart Contract. Check the deployment status here: https://testnet.bscscan.com/
Verify the deployed contract on BscScan
The first and foremost step is to flatten the solidity contract into a single file to be able to get it verified on BscScan.
Copy and Paste your smart contract into a local file on your system named as HelloWorld.sol.
Install Truffle Flattener by running the command npm install truffle-flattener on your terminal or command prompt.
Flatten the contract by running the command in the npx truffle-flattener HelloWorld.sol > FlatHelloWorld.sol contracts directory
Clean up the licensing information.
The flattened contract will have the same licensing note imported from each of the files.
Multiple licensing notes in one file break the BscScan verification, so you have to leave one licensing note for the entirety of the flattened contract.
The easiest way to clean up is to search for the SPDX mentions in the file and remove all of them except for the very first one.
This tutorial guided you through the basics of creating and deploying a simple smart contract using the Remix IDE and MetaMask Web Wallet. It also provides step-by-step guide on how to verify and publish your deployed smart contract. This tutorial uses testnet, however, the exact same instructions and sequence will work on the mainnet as well.
Using Replit IDE for Deploying Smart Contracts on BSC
Replit is a coding platform that allows you to write code and host apps. Replit supports Solidity programming language and provides all of the features and functionality that are required by Web3 developers for creating and deploying smart contracts.
There is no need for any local environment settings for deploying solidity smart contracts on BSC using Replit.
All you require is a browser-based Web3 wallet (e.g. MetaMask) to interact with the BSC Testnet and deployed contracts. If you are already using MetaMask, it is recommended to create a new account for testing with Replit. You can do this from the account menu, which appears when you click on the account avatar in the top right corner of MetaMask interface.
You must set up all of the following Pre-requisites to be able to deploy your solidity smart contract on BSC:
Every Repl that you create is a fully functional development and production environment. Follow the steps to create a solidity starter Repl:
Login or create an account. After creating your Replit account, your home screen will include a dashboard where you can view, create projects, and manage your account.
Once logged in, create a Solidity starter repl, Select + Create Repl from the left panel or + in the top right corner of the screen.
Note
The Solidity starter repl comes with a friendly web interface, built using the Web3 Ethereum JavaScript API, which you can use to deploy and interact with your smart contracts. For this tutorial, we will deploy smart contract on to BNB Smart Chain Testnet.
Once your contract has been deployed, it will show up as expandable boxes below the drop-down box. Expand it and take a look at all the different functions available. You can now interact with your contract using the provided user interface or from a sharable URL shown on the interface.
Replit allows you to publish your projects to a personal profile. After publishing, projects will show up on your spotlight page for others to explore, interact with, clone, and collaborate.
This tutorial guided you through the basics of creating and deploying a smart contract using the Replit IDE. We also provided steps on how to interact with the deployed contract online and publish your replit project. This tutorial uses testnet, however, the exact same instructions and sequence will work on the mainnet as well.
JSON-RPC endpoints refers to the network location where a program could transfer its RPC requests to access server data. Once you connect a decentralized application to an RPC endpoint, you can access the functionalities of different operations, which could enable real-time usage of blockchain data. BNB Chain provides several RPC endpoints for connectinto both its Minent and Testnet. In this section, we list the JSON-RPC endpoints that can be used for connecting to BNB Smart Chain.
The rate limit of BSC endpoint on Testnet and Mainnet is 10K/5min.
note
eth_getLogs is disabled on below Mainnet endpoints, please use 3rd party endpoints from here.
If you need to pull logs frequently, we recommend using WebSockets to push new logs to you when they are available.
BNB Smart Chain is an innovative solution to bring programmability and interoperability to BNB Beacon Chain. BNB Smart Chain relies on a system of 50 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality.
Ideally, BNB Smart Chain should build such staking and reward logic into the blockchain, and automatically distribute rewards as the blocking happens. Cosmos Hub, who also build on top of Tendermint consensus like BNB Beacon Chain, works in this way.
However, as BSC wants to remain compatible with Ethereum as much as possible. On the other side, BNB Beacon Chain already has a staking module and could be extended to support both BC and BSC. In this way, all the staking related operations are recorded in BC. Once there are any changes about BSC's validator set or voting power, the new message will be transferred to BSC through cross-chain communication.
The staking token is BNB, as it is a native token on both blockchains anyway
The staking, i.e. token bond and delegation actions and records for BSC, happens on BC.
The BSC validator set is determined by its staking and delegation logic, via a staking module built on BC for BSC, and propagated every day UTC 00:00 from BC to BSC via Cross-Chain communication.
The reward distribution happens on BC around every day UTC 00:00 after.
Validators are ranked by their power and operator address. The more its delegation tokens, the higher ranking is. If two validators get the same amount of delegated tokens, validator with smaller address bytes has higher ranking.
Since BSC uses PoSA as its consensus engine, all the delegators of validators can receive some share of the validators’ reward. However, the rewards(fees) are collected on BSC while the staking info is stored on BC. So, the main idea is we transfer all the rewards from BSC to BC once every day and execute the distribution on BC.
ValidatorSet is updated in BreatheBlock, the frequency is once a day. let’s assume it happens on day N.
The info of validator set changes of day N would be transmitted to BSCthrough interchain communication.
The validator set contract on BSC would receive and update the new validatorset. After that, it would trigger several interchain transfer to transfer the fees that every previous validators collected in this period to their addresses on BC. we can see that fees belongs to the validators of day N-1.
To make some room for the error handling, we distribute the fees of day N-1 in the next breathe block (day N+1).
Even if validator set or any their voting powers are not changed on that day, we still transmit the validator set info to BSC.
The validator set contract maintains the history of the fees that every validators collected after the previous period(We define the period as the time between two contract calls of validator set changes). The actual fees are collected on the contract address.
The interchain transfer to send fees from the contract address to each validator’s distribution address on BC. Note the distribution address is auto generated on BC when handling the create-validator tx, so no private key is corresponded to that address and no one except the distribution module can move the tokens on that address. This address is displayed as Distribution Addr in validator info.
Validator Fee Address: tbnb15mgzha93ny878kuvjl0pnqmjygwccdadpw5dxf Operator Address: bva15mgzha93ny878kuvjl0pnqmjygwccdad08uecu Validator Consensus Pubkey: Jailed: false Status: Bonded Tokens: 5000000000000 Delegator Shares: 5000000000000 Description: {Elbrus "" www.binance.org This is Elbrus org on chapel network.} Bond Height: 74158 Unbonding Height: 0 Minimum Unbonding Time: 1970-01-01 00:00:00 +0000 UTC Commission: {rate: 75000000, maxRate: 90000000, maxChangeRate: 3000000, updateTime: 2020-05-22 12:24:19.478568234 +0000 UTC} Distribution Addr: tbnb1srkkfjk8qctvvy4s3cllhpnkz9679jphr30t2c Side Chain Id: chapel Consensus Addr on Side Chain: 0xF474Cf03ccEfF28aBc65C9cbaE594F725c80e12d Fee Addr on Side Chain: 0xe61a183325A18a173319dD8E19c8d069459E2175
We have a lower limit of the value of interchain transfer, at least the value can cover the transfer fee. Also, interchain transfer will only allow max 8 decimals for the amount. The tiny left part would be kept in the contract or put into the system reward pool.
Reward:(totalfees \* (1-commissionRate)) would be distributed in proportion to the delegations, the left part would be sent to the validator fee address.
If the cross-chain transfer failed, the tokens would be sent back to a specified address(i.e. the SideFeeAddr in the store section, validators can change this address via the EditValidator tx). After that, validators can manually deposit the tokens to its own DistributionAddr on BC via Transfer tx. We do not force the validator to do so, but it’s an indicator that can help delegators choose validators.
The initial commission rate percentage, it has 8 decimal places.
Yes
--commission-max-rate
95000000 (0.95 or 95%)
The maximum commission rate percentage, it has 8 decimal places. You can not update this rate.
Yes
--commission-max-change-rate
3000000 (0.03 or 3%)
The maximum commission change rate percentage (per day). You can not update this rate.
Yes
--side-chain-id
chapel
chain-id of the side chain the validator belongs to
Yes
--side-cons-addr
0x1234abcd
consensus address of the validator on side chain, please use hex format prefixed with 0x
Yes
--side-vote-addr
0x1234abcd
vote pub key of the validator on side chain, please use hex format prefixed with 0x
Yes
--bls-wallet
/path/to/bls/wallet
absolute path of BLS wallet
Yes
--side-fee-addr
0xabcd1234
address that validator collects fee rewards on side chain, please use hex format prefixed with 0x.
Yes
--home
/path/to/cli_home
home directory of bnbcli data and config, default to “~/.bnbcli”
No
Some address parameters we need to highlight here:
Field Name
Usage
DelegatorAddr
Self delegator address. For BC, this address also used to collect fees.
ValidatorAddr
validator operator’s address, used in governance ops like voting.
SideConsAddr
block producer’s address on side chain, i.e. consensus address. BC has another parameter named PubKey, here SideConsAddr replaced that for BSC. Only BSC validators need this parameter.
SideVoteAddr
A bls public key. It's used by validators to vote for blocks, so the BSC chain can finalize blocks within two block periods in normal. ｜
SideFeeAddr
fees are collected in this address on BSC, Only BSC validators need this parameter. Due to different token units, there are some BNB left as dust when sending block rewards from BNB Smart Chain to BNB Beacon Chain. Those BNB will be sent to fee address.
How to Redelegate Your BNB With Binance Extension Wallet
By staking you BNB, you participate in the selection process of BNB Smart Chain validators and earn rewards. Staking BNB is critical for securing the network. Validators can self-bond, meaning they can delegate BNB to themselves, and they can also receive delegations from any other BNB holders.
Redelegations between a unique delegator, source validator, and destination validator can only happen once every 7 days
Click on Redelegate
Select a new validator and input amount to redelegate
Confirm your transaction in extension wallet
Upon Success you will see a similar output
Refresh and see your delegation changes
How to Undelegate Your BNB with Binance Extension Wallet
For a BEP20 token which has been mirrored to BC, anyone can call the sync method to balance the total supply on BC and BSC. Thus, the total supply among two Blockchains will remain the same.
Select sync function and fill-in with your BEP20 address
The value here should be no less than syncFee+ relayFee.
Time stamp should be greater than unix_timestamp(now()). The difference should be between 120 and 86400. It's recommended to use unix_timestamp(now())+1000
2.1 You can refer to BEP20 Template and modify it according to your own requirements.
NOTE 1: Ensure the BEP20 symbol is identical to the prefix of a BEP2 token symbol. Suppose a BEP2 token symbol is ABC-123, then the BEP20 symbol must be ABC.
NOTE 2: Ensure the total supply equals to the BEP2 token total supply. As we know, the decimals of BEP2 tokens are 8, if the BEP20 decimal is 18, then the BEP20 total supply must be BEP2_total_supply*10^10.
NOTE 3: If your BEP2 token is mintable, then you'd better implement mint in BEP20 contract. Otherwise, you'd better remove mint in BEP20 contract.
2.2 Compile your contract with Remix and get contract byte code:
Edit script/contract.json to add contract byte code:
{ "contract_data":"" }
Fill contract byte code to contract_data
Deploy contract, bind and transfer ownership:
./script/bind.sh {mainnet/testnet}{bep2TokenIssuerKeyName}{password, for ledger key, use empty string: ""}{peggyAmount}{bep2 token symbol}{token owner}{path to bnbcli or tbnbcli}
Suppose you have already issued BEP2 token, deployed BEP20 contract and sent bind transaction, now you just want to approve bind from your Ledger device:
Connect ledger to your machine and open Ethereum app.
The dual-chain architecture of BNB Beacon Chain & BNB Smart Chain empowers you to build your own decentralized apps. The native cross-chain communication mechanism allows tokens to be transferred between BC and BSC easily.
BNB Smart Chain and BNB Beacon Chain work together to ensure that one token can circulate in both formats with confirmed total supply and be used in different use cases.
-
+
diff --git a/docs/tokens.html b/docs/tokens.html
index a930189e3d..8ff0b63e5a 100644
--- a/docs/tokens.html
+++ b/docs/tokens.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
The symbol doesn't have to be unique, "-" followed by random 3 letters will be appended to the provided symbol to avoid uniqueness constraint.
Those 3 letters are the first three letters of tx hash of the issue transaction.
For example, "NNB-B90". Only BNB does not have this suffix.
Total Supply: an int64 boosted by 1e8 for decimal part. The max total supply is 90 billion.
Mintable: that means whether this token can be minted in the future. To set the tokes to be mintable, you need to add --mintable, otherwise just omit this field to set this token to be non-mintable.
Example on mainnet:
# To issue a NNB mintable token with total-supply 1 billion on mainnet > ./bnbcli token issue --token-name "new token" --total-supply 100000000000000000 --symbol NNB --mintable --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
# To issue a NNB non-mintable token with total-supply 1 billion on mainnet > ./bnbcli token issue --token-name "new token" --total-supply 100000000000000000 --symbol NNB --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
Example on testnet:
# To issue a NNB mintable token with total-supply 1 billion on testnet > ./tbnbcli token issue --token-name "new bnb" --total-supply 100000000000000000 --symbol NNB --mintable --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node Committed at block 1887(tx hash: B90A055DDD570AE42A7050182993A0B4DBC81A0D, ... Issued NNB-B90...)
# To issue a NNB non-mintable token with total-supply 1 billion on testnet > ./tbnbcli token issue --token-name "new bnb" --total-supply 100000000000000000 --symbol NNB --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node Committed at block 1887(tx hash: B90A055DDD570AE42A7050182993A0B4DBC81A0D, ... Issued NNB-B90...)
Tokens that is "mintable"(specified when issue) can use this function. The amount is boosted by 1e8 for decimal part. The total supply after mint is still restricted by 90 billion. Note only the owner of the token can use this transaction.
Example on mainnet:
> ./bnbcli token mint --amount 100000000000000000 --symbol NNB-B90 --from alice --chain-id Binance-Chain-Tigris --node https://dataseed5.defibit.io:443 --trust-node
Example on testnet:
> ./tbnbcli token mint --amount 100000000000000000 --symbol NNB-B90 --from alice --chain-id=Binance-Chain-Ganges --node=data-seed-pre-2-s1.bnbchain.org:80 --trust-node
Burn is to destroy certain amount of token, after which that amount of tokens will be subtracted from the operator's balance. The total supply will be updated at the same time. Notice that only the owner of the token has the permission to burn token. The amount is boosted by 1e8 for decimal part.
Freeze would move the specified amount of token into "frozen" status, so that these tokens can not transferred, spent in orders or any other transaction until they are unfreezed.
Anyone can (only) freeze or unfreeze tokens on their account with status in "free". The amount is boosted by 1e8 for decimal part.
-
+
diff --git a/docs/trading-spec.html b/docs/trading-spec.html
index 5c059c11ad..acbb0c4cfc 100644
--- a/docs/trading-spec.html
+++ b/docs/trading-spec.html
@@ -9,7 +9,7 @@
-
+
@@ -32,7 +32,7 @@
existing orders on the order book can still be traded.
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Mainnet as of 2021-03-21 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
bnbcli offers you a multi-send command to transfer multiple tokens to multiple people. 20% discount is available for multi-send transactions. For now, multi-send transaction will send some tokens from one address to multiple output addresses. If the count of output address is bigger than the threshold, currently it's 2, then the total transaction fee is 0.0003 BNB per token per address.
For example, if you send 3 ABC token,1 SAT token and 1 ABC to 3 different addresses.
Trading fees are subject to complex logic that may mean that individual trades are not charged exactly by the rates below, but between them instead; this is due to the block-based matching engine in use on the DEX.
The current fee for trades, applied on the settled amounts, is as follows:
Transaction Type
Pay in non-BNB Asset
Pay in BNB
Trade
0.1%
0.05%
Trading fee can be queried at here. It's under the "params/DexFeeParam/". "FeeRate" and "FeeRateNative" are both under unit of 10^-6.
Fees are variable and may change over time as governance proposals are proposed and voted on. The current fees table for Testnet as of 2021-03-17 is as follows:
Transaction Type
Pay in Non-BNB Asset
Pay in BNB
Exchange (DEX) Related
New Order
0
0
Y
Cancel (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
Order Expire (No Fill)
Equivalent 0.00005 BNB
0.00001 BNB
Y
IOC (No Fill)
Equivalent 0.00025 BNB
0.000005 BNB
Y
Transfer
N/A
0.000075 BNB
N
crossTransferOut
N/A
0.000075 BNB
N
Multi-send
N/A
0.00006 BNB
N
Issue Asset
N/A
10 BNB
Mint Asset
N/A
0.002 BNB
N
Transfer ownership
N/A
0.002 BNB
N
Burn Asset
N/A
0.002 BNB
N
Freeze/Unfreeze Asset
N/A
0.001 BNB
N
Lock/unlock/relock Asset
N/A
0.002 BNB
N
List Asset
N/A
200 BNB
N
Submit Proposal
N/A
1 BNB
N
Deposit
N/A
0.000125 BNB
N
Enable Memo Check
N/A
0.2 BNB
N
Disable Memo Check
N/A
0.2 BNB
N
HTLT
N/A
0.000075 BNB
N
depositHTLT
N/A
0.000075 BNB
N
claimHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
refundHTLT
N/A
0.000075 BNB
N
TinyIssueFee
N/A
0.4 BNB
N
MiniIssueFee
N/A
0.6 BNB
N
SetTokenUri
N/A
0.000075 BNB
N
List BEP8 Token
N/A
1 BNB
N
Create A New Smart Chain Validator
N/A
2 BNB
N
Edit Smart Chain Validator Information
N/A
0.2 BNB
N
Delegate Smart Chain Validator
N/A
0.0002 BNB
N
Redelegate Smart Chain Validator
N/A
0.0006 BNB
N
Undelegate Smart Chain Validator
N/A
0.0004 BNB
N
Unjail A Smart Chain Validator
N/A
0.5 BNB
N
Submit Byzaitine Behavior Evidence of A Smart Chain Validator
Trade fee is calculated based on trade notional value, while fees for other transactions are fixed.
It is free to send new GTE order, cancel a partially filled order, and you will not be charged a fee when the system expires a partially filled order (GTE or IOC).
Non-Trade related transactions will be charged a fee when the transactions happen, and can only be paid in BNB. The transaction will be rejected if the address does not have enough BNB.
Trade related transaction would be charged with fee when an order is filled, or canceled/expired/IOC-expired with no fills. If there is enough BNB to pay, BNB fee structure would be used, otherwise, non-BNB fee structure would be used to charged.
If the whole order value and free balance for the receiving asset are not enough to pay the fee, all the receiving asset and its residual balance would be charged.
Recommendations for Windows
If you're running Truffle on Windows, you may encounter some naming conflicts that could prevent Truffle from executing properly. Please refer to the official Truffle Documentation to find solutions for resolving naming conflicts.
Once the above mentioned softwares are installed, we only need one command to install Truffle:
npm install -g truffle
To verify that Truffle is installed properly, type truffle version on a terminal. If you see an error, make sure that your npm modules are added to your path.
If you're new to Truffle then please follow the Getting Started by truffle, To setup the truffle environment.
For creating a scaffold project for getting started, you can use the Truffle Boxes, BSC Starter Box which is a boilerplate to jump start development on the BNB Smart Chain.
For this tutorial, we have used the MetaCoin box as an example, which creates a token that can be transferred between accounts. Use the command truffle unbox metacoin to unbox the metacoin box.
NOTE: You can use the truffle unbox <box-name> command to download any of the other Truffle Boxes. Another alternative is to create a bare Truffle project with no smart contracts included using the truffle init command.
Once this operation is completed, you'll now have a project structure with the following items:
contracts/: Directory for Solidity contracts
migrations/: Directory for scriptable deployment files
test/: Directory for test files for testing your application and contracts
Update the truffle-config with bsc-network-crendentials.
constHDWalletProvider=require('@truffle/hdwallet-provider'); const fs =require('fs'); const mnemonic = fs.readFileSync(".secret").toString().trim(); module.exports={ networks:{ development:{ host:"127.0.0.1",// Localhost (default: none) port:8545,// Standard BSC port (default: none) network_id:"*",// Any network (default: none) }, testnet:{ provider:()=>newHDWalletProvider(mnemonic,`https://data-seed-prebsc-1-s1.bnbchain.org:8545`), network_id:97, confirmations:10, timeoutBlocks:200, skipDryRun:true }, bsc:{ provider:()=>newHDWalletProvider(mnemonic,`https://bsc-dataseed1.bnbchain.org`), network_id:56, confirmations:10, timeoutBlocks:200, skipDryRun:true }, }, // Set default mocha options here, use special reporters etc. mocha:{ // timeout: 100000 }, // Configure your compilers compilers:{ solc:{ version:"^0.8.0",// A version or constraint - Ex. "^0.5.0" } } }
NOTE: Notice, it requires mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new .secret file in root directory and enter your 12 word mnemonic seed phrase to get started. To get the seedwords from metamask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words, refer here for more details.
Configure the plugin in truffle-config.js using the following command
constHDWalletProvider=require("@truffle/hdwallet-provider"); // const infuraKey = "fj4jll3k....."; // const{ mnemonic,BSCSCANAPIKEY}=require('./env.json'); module.exports={ plugins:[ 'truffle-plugin-verify' ], api_keys:{ bscscan:BSCSCANAPIKEY }, networks:{ testnet:{ provider:()=>newHDWalletProvider(mnemonic,`https://data-seed-prebsc-1-s1.bnbchain.org:8545`), network_id:97, timeoutBlocks:200, confirmations:5, production:true// Treats this network as if it was a public net. (default: false) } }, // Set default mocha options here, use special reporters etc. mocha:{ timeout:100000 }, // Configure your compilers compilers:{ solc:{ version:"0.5.16",// Fetch exact version from solc-bin (default: truffle's version) // docker: true, // Use "0.5.1" you've installed locally with docker (default: false) settings:{// See the solidity docs for advice about optimization and evmVersion optimizer:{ enabled:false, runs:200 }, evmVersion:"byzantium" } }, }, };
If you're running Truffle on Windows, you may encounter some naming conflicts that could prevent Truffle from executing properly. Please see the section on resolving naming conflicts for solutions.
Once we have those installed, we only need one command to install Truffle:
npm install -g truffle
To verify that Truffle is installed properly, type truffle version on a terminal. If you see an error, make sure that your npm modules are added to your path.
Update the truffle-config with bsc-network-crendentials.
constHDWalletProvider=require('@truffle/hdwallet-provider'); const fs =require('fs'); const mnemonic = fs.readFileSync(".secret").toString().trim(); module.exports={ networks:{ development:{ host:"127.0.0.1",// Localhost (default: none) port:8545,// Standard BSC port (default: none) network_id:"*",// Any network (default: none) }, testnet:{ provider:()=>newHDWalletProvider(mnemonic,`https://data-seed-prebsc-1-s1.bnbchain.org:8545`), network_id:97, confirmations:10, timeoutBlocks:200, skipDryRun:true }, bsc:{ provider:()=>newHDWalletProvider(mnemonic,`https://bsc-dataseed1.bnbchain.org`), network_id:56, confirmations:10, timeoutBlocks:200, skipDryRun:true }, }, // Set default mocha options here, use special reporters etc. mocha:{ // timeout: 100000 }, // Configure your compilers compilers:{ solc:{ version:"^0.6.12",// A version or constraint - Ex. "^0.5.0" } } }
Notice, it requires mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new .secret file in root directory and enter your 12 word mnemonic seed phrase to get started. To get the seedwords from metamask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words.
Updating geth is as easy as it gets. You just need to download and install the newer version of geth, shutdown your node and restart with the new software. Geth will automatically use the data of your old node and sync the latest blocks that were mined since you shutdown the old software.
-
+
diff --git a/docs/validator/Penalty-overview.html b/docs/validator/Penalty-overview.html
index 08e0fd34f6..081725b20a 100644
--- a/docs/validator/Penalty-overview.html
+++ b/docs/validator/Penalty-overview.html
@@ -9,7 +9,7 @@
-
+
@@ -21,7 +21,7 @@
The penalty message will be sent back to the BC chain through the cross-chain bridge;
A predefined amount of BNB would be slashed from the self-delegated BNB of the validator; Both validator and its delegators will not receive the staking rewards;
The slashed BNB will be allocated to the other validators’ custody addresses, and distributed to all delegators in the same way as blocking reward.
The liveness of BSC relies on everyone in the Proof of Staked Authority validator set can produce blocks timely when it is their turn. Validators can miss their turn due to any reason, especially problems in their hardware, software, configuration or network. This instability of the operation will hurt the performance and introduce more indeterministic into the system.
There can be an internal smart contract responsible for recording the missed blocking metrics of each validator. Once the metrics are above the predefined threshold, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. In such a way, the poorly-operating validator should be gradually voted out of the validator set as their delegators will receive less or none reward. If the metrics remain above another higher level of threshold, the validator will be dropped from the rotation, and this will be propagated back to BC, then a predefined amount of BNB would be slashed from the self-delegated BNB of the validator. Both validators and delegators will not receive their staking rewards.
Slashing is part of the on-chain governance, to ensure the malicious or negative behaviors are punished. BSC slash can be submitted by anyone. The transaction submission requires slash evidence and cost fees but also brings a larger reward when it is successful.
Two block headers have same height and same parent block hash
Two block headers are sealed by the same validator
Two signatures of these two blocks must not be the same
The time of these two blocks must be within the validity of the evidence, which is 24 hours
If the evidence is valid:
1000BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 1000BNB, then the unbonding delegation balance would be slashed if it exists until totally 1000BNB slashed from self-delegator of the validator. However, if all the slashed BNB is less than 1000, all the remaining stake of the self-delegator will be slashed
100 of slashed BNB would allocate to the submitter as a reward
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with duration of 7 days, and remove it from validator set by an instance BSC validator set update Cross-Chain update
There can be an internal smart contract responsible for recording the missed blocking metrics of each validator.
If a validator missed more than 50 blocks in 24h, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. If it missed more than 150 blocks in 24h, then this will be propagated back to BC where another Slashing will happen:
50BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 50BNB, then the unbonding delegation balance would be slashed if it exists until totally 50BNB slashed from self-delegator of the validator. However, if all the slashed BNB is less than 1000, all the remaining stake of the self-delegator will be slashed
10 of slashed BNB would allocate to the validators on BC as block fee
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with duration of 2 days, and remove it from validator set by an instance BSC validator set update Cross-Chain update
The malicious validators who are slashed by the previous cases will be set to jailed along with a duration setting as well due to the malicious or negative behaviors. We can set it to ‘unjailed’ by sending a side-unjail transaction if the validation passed.
When your validator is unjailed on BNB Chain, it must wait for the next UTC 0:00 to join validatorsest again.
Slashing validators of BSC for the malicious behavior of double-sign by submitting evidence consisting of two block headers with same height but signed by one signer
-
+
diff --git a/docs/validator/best-practice.html b/docs/validator/best-practice.html
index f213b340eb..8f362f9590 100644
--- a/docs/validator/best-practice.html
+++ b/docs/validator/best-practice.html
@@ -9,7 +9,7 @@
-
+
@@ -21,7 +21,7 @@
[::] will be parsed as localhost (127.0.0.1). If your nodes are on a local network check each individual host machine and find your IP with ifconfig
If your peers are not on the local network, you need to know your external IP address (use a service) to construct the enode URL.
Copy this value and in the console of the first node run,
Update config.toml file of validator node
# make node invisible NoDiscovery = true # connect only to sentry StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]
This will return true if successful, but that doesn’t mean the node was added successfully.
To confirm run admin.peers and you should see the details of the node you just added.
That way your validator node will try to peer with your provided sentry nodes only.
Confirm the connection
To confirm run admin.peers and you should see the details of the node you just added.
geth uses several TCP ports for different purposes.
geth use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.
If you need to run JSON-RPC, you'll also need TCP port 8545. Note that JSON-RPC port should not be opened to the outside world, because from there you can do admin operations.
You are incentivized to set a voting key which will be used for fast finality voting. Voters will receive due rewards.
geth bls account new --datadir ./node
This command will create a bls wallet and generate a voting key. During the process, you will need to set the wallet password and another password used to encrypt the voting key. The former is required when running the validator, and the latter is only used to import the voting key into the existing wallet. Do not disclose the voting key, otherwise it may be used for malicious voting!
If you already have a voting key, create a bls wallet and use the keyfile to recover it:
VPS running recent versions of Mac OS X, Linux, or Windows.
IMPORTANT 3 TB of free disk space, solid-state drive(SSD), gp3, 8k IOPS, 250 MB/S throughput, read latency <1ms. (if node is started with snap sync, it will need NVMe SSD)
16 cores of CPU and 64 GB of memory (RAM)
Suggest m5zn.3xlarge instance type on AWS, c2-standard-16 on Google cloud.
A broadband Internet connection with upload/download speeds of 5 MB/S
Download latest chaindata snapshot from here. Follow the guide to structure your files.
note
Your --datadir flag should point to the folder where the extracted snapshot data is.
In our case, we created a new folder named node, and we moved the extracted snapshot data to this folder.
Make sure you use the version of geth you downloaded with wget above, and not your local installation of geth, which might be the wrong version.
tip
It is recommended to run a fast node, which is a full node with the flag --tries-verify-mode none set if you want high performance and care little about state consistency.
Check here for full details on running a fast node.
To sync from genesis block, you would need a more powerful hardware. Server should at least have 40k IOPS and be at least an i3/i3en series server.
Write genesis state locally
./geth --datadir node init genesis.json
You could see the following output:
INFO [05-19|14:53:17.468] Allocated cache and file handles database=/Users/huangsuyu/Downloads/bsc/node/geth/chaindata cache=16.00MiB handles=16 INFO [05-19|14:53:17.498] Writing custom genesis block INFO [05-19|14:53:17.501] Persisted trie from memory database nodes=21 size=56.84KiB time=357.915µs gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=-574.00B INFO [05-19|14:53:17.502] Successfully wrote genesis state database=chaindata hash=7d79cc…fb0d1e INFO [05-19|14:53:17.503] Allocated cache and file handles database=/Users/huangsuyu/Downloads/bsc/node/geth/lightchaindata cache=16.00MiB handles=16 INFO [05-19|14:53:17.524] Writing custom genesis block INFO [05-19|14:53:17.525] Persisted trie from memory database nodes=21 size=56.84KiB time=638.396µs gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=-574.00B INFO [05-19|14:53:17.528] Successfully wrote genesis state database=lightchaindata hash=7d79cc…fb0d1e
Start fullnode
## start a full node ./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --txlookuplimit 0
There are two sync modes for running a full node: snap and full which can be specified by flag --syncmode.
The snap sync mode is used for initial sync, which will download the latest states rather than execute the blocks from the genesis. When the initial sync is done, it will switch to full sync automatically.
The full sync mode can also be used to do initial sync, which will execute all the blocks since genesis. But it is not recommended, since the amount of historical data is too large. Instead, you can download a snapshot from the official repo and start full sync from the snapshot.
If the flag --syncmode is not provided, the default sync mode will depend on the state of the data folder. It will be snap mode if you sync from genesis or full mode if you start from a snapshot.
As best practice, it is advisable to keep monitoring the event log of the slash contract on the BSC scanner at
https://bscscan.com/address/0x0000000000000000000000000000000000001001#events. Additionally, you can also check the slash indicator by reading the contract and pay attention to those above 30. Once it exceeds 150, the validator contract will be jailed.
According to the test, the performance of a full node will degrade when the storage size reaches a high volume(previously it was 1.5TB, which is an experimental value, the latest number needs to be updated). We suggest that the fullnode always keep light storage by pruning the storage.
Run nohup geth snapshot prune-state --datadir {the data dir of your bsc node} &. It will take 3-5 hours to finish.
Start the node once it is done.
The maintainers should always have a few backup nodes in case one of the nodes is getting pruned.
The hardware is also important, make sure the SSD meets: 2 TB of free disk space, solid-state drive(SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms.
Ancient data is block data that is already considered immutable. This is determined by a threshold which is currently set at 90000. This means that blocks older than 90000 are considered ancient data. We recommend the --prunceancient flag to users who don't care about the ancient data. This is also advised for users who want to save disk space since this will only keep data for the latest 90000 blocks. Note that once this flag is turned on, the ancient data will not be recovered again and you cannot go back running your node without this flag in the start-up command.
A new offline feature introduced in v1.1.8 to prune undesired ancient block data. It will discard block, receipt, and header in the ancient database to save space.
When the node crashes or been force killed, the node will sync from a block that was a few minutes or a few hours ago. This is because the state in memory is not persisted into the database in real time, and the node needs to replay blocks from the last checkpoint once it start. The replaying time depends on the configuration TrieTimeout in the config.toml. We suggest you raise it if you can tolerate with long replaying time, so the node can keep light storage.
BNB Smart Chain is an innovative solution to bring programmability and interoperability to BNB Beacon Chain. BNB Smart Chain relies on a system of 56 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality.
Other than the 40 active validators (21 Cabinets and 19 Candidates), BSC will introduce more validators, e.g. another 16 inactive validators, into the validator set as backups, which will be called “Candidates”.
Candidates will produce blocks and charge gas fees in BSC mainnet, but in a much less chance than the official validator set of 40 elected. The unavailable candidates will be slashed as well though in a smaller size. A decent motivation is expected to be maintained so that the candidate validators are willing to ensure the quality and help secure BSC.
In an extreme case, if a majority of the active 40 validators (21 Cabinets and 19 Candidates) get attacked and offline, Candidate Validators can report to BNB Beacon Chain about the stale blocking, resume it and eventually propose a re-election of active validator set.
BNB Smart Chain relies on a set of validators who are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by signing blocks that contain cryptographic signatures signed by each validator's private key. The validator set is determined by a staking module built on BNB Beacon Chain for BNB Smart Chain, and propagated every day 00:00 UTC from BC to BSC via Cross-Chain communication.
Validator's rewards come from transaction fees and commission fees from delegators.
Let us also assume that the reward for a block is 100 BNB and that a certain validator has 20% of self-bonded BNB and sets its commission rate to 20%. These tokens do not go directly to the proposer. Instead, they are shared among validators and delegators. These 100 BNB will be distributed according to each participant's stake:
The rewards for motivating validators to vote for Fast Finality also comes from transaction fees. The specific rules can refer to BEP126
If validators double sign, malicious vote or frequently offline, their staked BNB (not including BNB of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.
You can learn to see the revenue history from BitQuery's chart or a table of BscScan
10000 staked BNB will be slashed for the validator.
The Double-Sign Jail time is 2^63-1 seconds, which means the candidate cannot become a validator anymore.
Note: Rewards for submitting double-sign evidence:1000BNB Anyone can submit a slashing request on BC with the evidence of Double Sign of BSC, which should contain the 2 block headers with the same height and parent block, sealed by the offending validator.
10000 staked BNB will be slashed for the validator.
The Double-Sign Jail time is 2^63-1 seconds, which means the candidate cannot become a validator anymore.
Note: Rewards for submitting Malicious Vote evidence:50BNB. Only relayers can submit a slash request on BSC with the evidence of Malicious Vote of BSC for now, which should contain the 2 votes, signed by the offending validator. Open access to anyone is planned.
If a validator missed more than 50 blocks every 24 hours, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. If it missed more than 150 blocks every 24 hours, then this will be propagated back to BC where another slashing will happen
-
+
diff --git a/docs/validator/run-val.html b/docs/validator/run-val.html
index 652c633612..ee792e1235 100644
--- a/docs/validator/run-val.html
+++ b/docs/validator/run-val.html
@@ -9,7 +9,7 @@
-
+
@@ -21,7 +21,7 @@
then you may add the flag to specify it: –blswallet /<path>/bls/wallet
Step 4: restart
You may only provide the flag: --vote, if you did not specify it in config.toml
Then you may go ahead, just restart the node.
This repository is a place for validator candidates to give potential delegators a brief introduction about your team and infrastructure, and present your ecosystem contributions.
-
+
diff --git a/docs/validator/security.html b/docs/validator/security.html
index b6aac57147..61604d0113 100644
--- a/docs/validator/security.html
+++ b/docs/validator/security.html
@@ -9,7 +9,7 @@
-
+
@@ -19,7 +19,7 @@
[::] will be parsed as localhost (127.0.0.1). If your nodes are on a local network check each individual host machine and find your IP with ifconfig
If your peers are not on the local network, you need to know your external IP address (use a service) to construct the enode URL.
Copy this value and in the console of the first node run,
Update config.toml file of validator node
# make node invisible NoDiscovery = true # connect only to sentry StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]
This will return true if successful, but that doesn't mean the node was added successfully.
To confirm run admin.peers and you should see the details of the node you just added.
That way your validator node will try to peer with your provided sentry nodes only.
Confirm the connection
To confirm run admin.peers and you should see the details of the node you just added.
geth uses several TCP ports for different purposes.
geth use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.
If you need to run JSON-RPC, you'll also need TCP port 8545. Note that JSON-RPC port should not be opened to the outside world, because from there you can do admin operations.
bnbcli slashing bsc-submit-evidence \--from={Name or address of private key with which to sign} \--evidence={Evidence details, including two bsc block headers with json format} \--evidence-file={File of evidence details} \--chain-id={the chain id of BNB Chain}
Evidence details, including two bsc block headers with json format
Option
--evidence-file
/user/evidence.json
File of evidence details, if evidence-file is not empty, --evidence will be ignored
Option
In the above command, --evidence and --evidence-file are optional parameters. If --evidence-file is not empty, --evidence will be ignored. --from and --chain-id are mandatory parameters.
If you run bsc with flag monitor.maliciousvote, evidence will be output into logs when votes violating rules are detected, then the tool maliciousvote-submit can be used to submit the evidence.
Two block headers have the same height and the same parent block hash
Two block headers are sealed by the same validator
Two signatures of these two blocks must not be the same
The time of these two blocks must be within the validity of the evidence, which is 24 hours
If the evidence is valid:
10,000BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 10,000BNB, then the unbonded delegation balance would be slashed if it exists until totally 10,000BNB slashed from the self-delegator of the validator. However, if all the slashed BNB is less than 10,000, all the remaining stake of the self-delegator will be slashed
1000 of slashed BNB would allocate to the submitter as a reward
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with a duration of 292 years, and remove it from validator set by an instance BSC validator set update Cross-Chain update
Only relayers can submit a slash request on BSC with the evidence of Malicious Vote of BSC for now. Open access to anyone is planned.
The target number voted by two votes lags behind the block header of the canonical chain by no more than 256
The source numbers of the two votes are both smaller than their respective target numbers
The source hash and target hash of the two votes are both not equal
The target number of the two votes is the same or the span of one vote includes the span of the other vote
The two votes are signed by the same voting key, and the verification of signatures are both passed
The voting key used for signing is in the list sent by the last two breathe blocks
If the evidence is valid:
10,000BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 10,000BNB, then the unbonded delegation balance would be slashed if it exists until totally 10,000BNB slashed from the self-delegator of the validator. However, if all the slashed BNB is less than 10,000, all the remaining stake of the self-delegator will be slashed
50BNB would allocate to the submitter from the systemreward contract as a reward if the validator is active when the evidence submitted
The slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with a duration of 292 years, and remove it from validator set by an instance BSC validator set update Cross-Chain update
There can be an internal smart contract responsible for recording the missed blocking metrics of each validator.
If a validator missed more than 50 blocks in 24h, the blocking reward for the validator will not be relayed to BC for distribution but shared with other better validators. If it missed more than 150 blocks in 24h, then this will be propagated back to BC where another Slashing will happen:
50BNB would be slashed from the self-delegated BNB of the validator
If the self-delegator’s stake amount on the validator is less than 50BNB, then the unbonded delegation balance would be slashed if it exists until totally 50BNB slashed from self-delegator of the validator. However, if all the slashed BNB is less than 50, all the remaining stake of the self-delegator will be slashed
10 of slashed BNB would allocate to the validators on BC as block fee
The rest of slashed BNB will allocate to the custody addresses of which validators would take part in the next distribution. If no matched validators found, then the rest of slashed BNB will allocate to validators on BC as block fee
Set the validator ‘jailed’ with a duration of 2 days, and remove it from validator set by an instance BSC validator set update Cross-Chain update
Jailed validator nodes due to their malicious or bad behavior, may request for release by sending side-unjail transactions provided they passed initial validation. After release, to re-join the validator set again, the validator must wait for the following UTC 0:00. The fees to unjail a smart contract validator is 1 BNB. Whereas, the fee for submitting a byzantine behavior evidence of a validator is 10 BNB.
bnbcli slashing side-unjail \--from= {this address has to be the operator address of the validator to be unjailed. Name or address of private key with which to sign} \--side-chain-id= {chain-id of the side chain the validator belongs to} \--chain-id= {the chain id of BNB Chain}
Parameter Name
Example
Explanation
Required
--chain-id
Binance-Chain-XXX
the chain id of binance chain
Yes
--from
bnb19awsmku5ch689lp0rj0c6su7x0n5wxhjm65hdd
This address has to be the operator address of the validator to be unjailed. Name or address of private key with which to sign.
Yes
--side-chain-id
BSC-XXX
chain-id of the side chain the validator belongs to
Updating geth is as easy as it gets. You just need to download and install the newer version of geth, shutdown your node and restart with the new software. Geth will automatically use the data of your old node and sync the latest blocks that were mined since you shut down the old software.
Step 1: Compile the New Version or download new pre-build binaries from release
git clone https://github.com/bnb-chain/bsc # Enter the folder bsc was cloned into cd bsc # Compile and install bsc make geth
A wallet provider is a service that allows DApps to provide wallets to their end-users without having to deal with the security concerns of key management. It is a great way to make your Dapp ready to onboard a more mainstream audience.
Arkane allows you to easily integrate your app with the BNB Smart Chain, whether you already have an Dapp integrated with web3 or are building a new application from scratch. Arkane provides a smooth and delightful experience for you, your users on both web and mobile.
Arkane will help you interact with the BNB Smart Chain, create blockchain wallets, create different asset types such as fungible (BEP20, ERC20), and non-fungible tokens - NFTs - (ERC721, and ERC1155) and interact with smart contracts. Next to a superior developer experience, you can give your users a user-friendly interface.
Each application is unique and has different needs, therefore they provide different ways of interacting with Arkane. Applications that have support for Web3 are recommended to integrate the Arkane Web3 provider, others are suggested to use the Arkane Widget.
If you already support Web3-technology, you can improve the UX within your application by integrating the Arkane Web3 provider, a smart wrapper around the existing Web3 Ethereum JavaScript API.
By making use of our Web3 provider you are able to leverage the full potential of Arkane with minimal effort and you will be able to onboard users that are less tech savvy without making them leave your application or download third party plugins. Integrating just takes 2 steps and 5 minutes
After adding the javascript file to your page, a global Arkane object is added to your window. This object is the gateway for creating the web3 wrapper and fully integrates the widget - Arkane Connect.
If you are looking for a user-friendly BNB Smart Chain wallet, consider creating an Arkane wallet. It allows you to enable the recovery mechanism and comes with end-user support via their in-app chat, making sure you are never lost in the wonderful land of cryptocurrency.
Now that you've configured your PIN, you are ready to create a BNB Smart Chain wallet. Just select BNB Smart Chain from the list.
To create a new wallet press 'Create new wallet'
Once you've press the button, Arkane will ask you to confirm using your PIN (the one you configured a few steps before). After that your wallet will be created and you will be taken to your Dashboard.
Binance Extension Wallet is a crypto Wallet for BNB Beacon Chain and BNB Smart Chain. You can send and receive funds on BNB Beacon Chain, BNB Smart Chain and cross-chain transfers between both of BNB Chain’s blockchains.
In the future, Binance Extension Wallet will add support for Ethereum blockchain and enable access for distributed applications, or "Dapps" in your browser!
Paste the provided Passphrase/ Private Key into the confirmation box.
After copying & saving your Passphrase, tick the “Backup your recovery key” box to confirm & back up the provided Passphrase & Private Key. Please note that this information is crucial to keeping your assets safe.
Tick the remaining boxes to confirm you’re aware of the risks.
Click Create Wallet.
Your BNB Wallet will instantly be displayed on the home screen. You can also click Manage to check your wallets.
How to receive BNB and BEP20 tokens to Coin98 Mobile Wallet
Step 1: Select your BNB (BEP20) wallet on the home screen.
Step 2: Click Receive.
Step 3: Click the copy icon to copy the wallet address.
Step 4: Send BNB tokens to this address.
How to send BNB and BEP20 tokens from Coin98 Mobile Wallet
Step 1: Select your BNB (BEP20) wallet on the home screen.
Step 2: Click Send.
Step 3: Fill in the amount of tokens, the receiver’s wallet address, messages (if necessary) and adjust the gas fee to your needs.
Step 4: Slide Send to complete.
Note:
The default gas fee on Coin98 Wallet has been set at the standard rate that offers the most optimized speed at a reasonable cost.
The gas fee is approximately 0.000105 BNB for each transaction on BNB Smart Chain.
Bitcoin Improvement Proposal (BIP) 39 defines a formula for the generation of a mnemonic sentence (also referred to as mnemonic words, seed phrase, recovery phrase, etc.)the generation of a seed from that mnemonic sentence. That seed is used to produce your private and public keys, but those details will be covered in the next post in this series.
BIP 32 is a specification for creating Hierarchical Deterministic wallets. They are wallets that, from a root it can generate multiple "child" private keys in a deterministic way. You only need to remember the "path" of the child key.For example hardware wallets use them from a single root you can generate separate keys for Bitcoin (with path m/44'/0'/0'/0) and Ethereum (path m/44'/60'/0'/0).
Binance Extension wallet would use a similar way to generate keys as Ethereum, i.e. derive the private key using BIP32/BIP44 with HD prefix as "44'/60'/", which is the same as Ethereum's derivation path.
Whenever you click on “Add Account”, your seed is extended at the end by a counter value which makes it possible to automatically derive an unlimited number of new addresses in your extension wallet.
Your first step is to plug your Ledger into your computer. Ensure it powers on and then input the pin you chose when setting up your ledger.
Select and open the Ethereum Application. If you haven't installed Ethereum Application, please read this guide
Enabling contract data for BEP20. The first item in the settings menu is “Contract Data”. Push down both buttons to select it. Once you have set your ledger up like this the first time, you won’t have to do it again each time you want to use it with Binance Extension wallet.
Open BNB Chain Extension Wallet and select "BNB Smart Chain" network
Choose "Hardware Wallet" in Settings. Then, click on "Connect"
Choose HD Path. Use "Legacy" by default
Finally, you can see a new account with LEDGER tag
!!! Warning
Please note you cannot use Ledger account for BNB Chain network.
When resetting your password for your Binance Extension wallet, you will need your 12 or 24 word seed phrase. If you do not already have your seed phrase saved someplace safe, please make sure to read How to Reveal Your Seed Phrase
Before trying these steps, confirm that you have your seed phrase with you as you will not be able to reset your password otherwise and will risk becoming locked out of your wallet.
If your wallet is currently unlocked, please lock your wallet first.
Click Import Import seed phrase
Enter your seed phrase in the "Seed Phrase" text box
Enter your new password
Retype your password to confirm it was written correctly
Wallets are a bit of a shift in thinking. Financial freedom and the ability to access and use funds anywhere comes with a bit of responsibility – there’s no customer support in crypto.
Centralized exchanges will link your wallet to a username and password that you can recover in a traditional way. Just remember you’re trusting that exchange with custody over your funds. If that company is attacked or folds, your funds are at risk.
When dealing with cryptocurrencies or crypto assets like BNB or BUSD, it is important to always be aware of and have your private keys, seed phrases and passwords backed up in case the unexpected occurs.
When you create a new Binance Extension Wallet account, you are given your 12 word seed phrase is the most important bit of information for you to record and keep safe when managing your extension account.
You can write your seed phrase down on a piece of paper, store it on a flash drive or we also make it optional to download a file containing this information.
Backing Up After You Install Binance Extension Wallet
If for some reason you forgot to record your 12 word seed phrase or you lost the original copy, you can reveal your seed phrase so you can back it up again.
Select Dropdown Menu (on top-right corner) --> Manage Accounts
Tokens not visible after withdrawing from Binance
Many users who interact with a centralized exchange like Binance eventually want to withdraw to a wallet that they fully control, like MetaMask. So once you've used their withdraw form, what could be scarier than not seeing your tokens?
First, you'll need to use the MetaMask add Custom Network feature to add the BNB Beacon Chain or BNB Smart Chain's RPC URLs endpoints to your MetaMask.
Once you've added the BNB Beacon Chain or the BNB Smart Chain to your MetaMask, you will be able to select different networks to view the assets (you may need to add Custom Tokens too) held by your selected account on that network.
if you try to send tokens without having any BNB in your account you will be told you have insufficient funds. This means you do not have enough BNB in your account to cover the cost of gas. Each transaction (including token and contract transactions) require gas and that gas is paid in BNB. You can think of this like a transaction fee.
You can remedy this by sending 0.001 BNB to that account in order to be able to make the transaction.
A standard Ether transfer TX will be 21000 gas & a gas price of 15 Gwei.
With tokens, the amount of gas is typically gas, so the total TX fee increases to 0.002 BNB - 0.003 BNB.
Infinity Wallet is the ultimate easy to use, secure, multicurrency, practical and convenient self-custodial cryptocurrency wallet, that provides all a user will ever need in one platform. With a wide range of new and innovative features to access digital assets, empowering financial freedom.
Advancing the world of decentralized finance with an all-in-one digital wallet experience and streamlining adoption of cryptocurrency. Infinity Wallet is packed with a wealth of features and designed for the best possible user experience. With a simple and modular interface allowing to interact, monitor, trade, transact, view news and much more in a secure environment, as the one-stop application that a user will ever need for decentralized finance.
Connect to DeFi protocols and Dapps directly on desktop or mobile from within the Infinity Wallet, to securely use decentralized platforms without compromising your assets. Providing enhanced ease of use and security, as well as support for multiple chains.
The Infinity Wallet is currently available to be downloaded for desktop devices on Windows, macOS and Linux. In the coming months there will be a mobile wallet released to accompany our revolutionary desktop wallet.
Launch the Infinity Wallet to create your local account and wallet
Create a local account, you can name this anything as the account name is only used locally within your own device
Create a password for your local account and confirm your password
Select to either create a new wallet or recover an existing wallet (You can import your 12 or 24 word seed phrase from most other wallets into the Infinity Wallet as we follow the standard)
Give your wallet a name so you can easily identify it within your local account
If you would like to have additional security, you can create an individual pin for each of your wallets (This is optional)
Select if you want to use a 12 or 24 word seed
You will now need to confirm that you understand that you have to backup your 12 or 24 word seed to be able to recover your wallet. We recommend keeping your seed phrase offline and somewhere secure (Never share your seed with anyone, including the Infinity Wallet support team)
Make a backup of the words on the screen, we recommend making a paper backup and not an online backup. If you ever lose access to your computer or forget your password, you will need your 12 or 24 word seed to recover your wallet (Keep these words secure and never share them with anyone, as these words grant full access to your wallet)
Confirm a selection of the words in the correct order as requested, to generate your wallet
Congratulations you have successfully created your Infinity Wallet and can now access the vast array of features it has to offer
Now that you have created your wallet you can monitor and manage a wide range of different cryptos within the Infinity Wallet, including BNB and BNB Smart Chain Tokens
To receive BNB on the BNB Smart Chain you will have to enable it by going to My Wallet and clicking on + Add asset, then select to enable BNB Coin (BSC). All BSC tokens on the Infinity Wallet will use the same address as BNB BSC
Now that BNB Coin (BSC) is enabled go back to My Wallet and select BNB Coin (BSC), to get your receive adddress click on the receive button
Copy your receive address by clicking on it, or select one of the options to print, share or request an amount to generate a decentralized link to request funds
To send go to My Wallet, select BNB Coin (BSC) and then click on the send button
Either enter an address to send to, select from your contact list, or scan a QR request by importing, scanning with a webcam, or using our drag and scan desktop technology
If you select to use the drag and scan QR technology, then all you need to do is drag the window over a QR code you have been shared and it will automatically detect the address and fill it in for you as the send address
Infinity Wallet supports the ability for users to connect securely to decentralized application on the BNB Smart Chain, BNB Beacon Chain and Ethereum.
To connect your wallet make sure the platform you are connecting to supports Wallet Connect, then go to your Infinity Wallet and click WalletConnect in the bottom left corner.
In the popup that will show you can select one of 3 options to connect, the recommended and easiest option will be to use the "Desktop Scan" which uses our drag and scan desktop technology
Drag and resize the desktop QR scanner over the QR you want to scan, in this case we will be connecting to Infinity Crypto (https://infinitycrypto.com/)
Approve the connection between the platform and your wallet. All transactions on the platform will be pushed to be confirmed and signed within the Infinity Wallet, ensuring your keys are never shared and providing maximum security while interacting with Dapps and DeFi
After sucessfully approving the connection between the Infinity Wallet and the Dapp or DeFi platform, you will see that the WalletConnect icon in the bottom left of the Infinity Wallet will be green, signifying that your wallet is now connected to the Dapp or DeFi platform
Congratulations you can now start interacting with the Dapp or DeFi platform and confirming all transactions securely from the safety of your Infinity Wallet
On creating a transaction on the Dapp or DeFi platform you will receive a popup request within your Infinity Wallet to send, sign or approve a transaction. You can review the information of the transaction and either accept or decline it
After confirming an interaction, the Infinity Wallet will sign the transaction and push it over the network, without revealing your key to the platform you are interacting with. Within the Infinity Wallet and on the Platform you should see a success message that the transaction was signed and pushed
The Infinity Wallet is aiming to push crypto innovation to its limits and has a wide range of future features and UI enhancements on the roadmap, to further expedite global adoption of cryptocurrency. Along with its companion platform Infinity Crypto, which is revolutionizing the DeFi and exchange space on BNB Smart Chain and Ethereum.
-
+
diff --git a/docs/wallet/ledger.html b/docs/wallet/ledger.html
index 057ee38346..e4dce9d449 100644
--- a/docs/wallet/ledger.html
+++ b/docs/wallet/ledger.html
@@ -9,7 +9,7 @@
-
+
@@ -18,7 +18,7 @@
The existing Ethereum App is compatible with BNB Smart Chain
1) Plug in and unlock your Ledger device, open Ledger Live on your computer, then open the "Manager" panel.
2) Within the "Manager" pane, type in "Ethereum" in the search field. Locate "Ethereum", then click on "Install". (Note: Do not use the "BNB Chain" App)
3) The Ethereum app will now install on your Ledger device.
!!! Tip
Please ensure your enabled contract data before transferring BEP20 tokens
If you want to send BEP-20 tokens, you need to activate contract data on your device. Otherwise, invalid status 6a80 is returned.
Steps:
Connect and unlock your Ledger device.
Open the Ethereum application.
Press the right button to navigate to Settings. Then press both buttons to validate.
In the Contract data settings, press both buttons to allow contract data in transactions.
BNB Smart Chain is compatible with MetaMask. Users can use MetaMask as a bridge between Ledger Nano S and BNB Smart Chain to make transactions to the BNB Smart Chain testnet.
1) Connect MetaMask to BSC Testnet by following this guide to add a custom network
One of the key innovations of a dual-chain architecture is that token issuer can manage its assets on both chains. They could bind BEP2 tokens and BEP20 tokens together. In BNB Chain Ganges Testnet, there are several pegged tokens:
Input the the amount of tokens you want to transfer and then press the "Next" button
Click on the "Market" icon to modify the default gas fees
Go to Advanced Options to edit the default gas fees
Update the "Max Base Fee" and the "Priority Fee" options to a higher value than the default. For mainnet set it to 3 GWEI. Make sure to select the "Always use these value and advanced setting as default". Then click on the save button.
Confirm your transaction by clicking the confirm button.
Once your transaction is confirmed, check it on block explorer. Click on the transaction to open its details and then on "View on Block Explorer".
caution
Since the release of v8.1.3, MetaMask sometimes displays the warning message "Invalid Custom Network". To solve this issue, click on "Settings" and enter Chain ID of BNB Smart Chain network again. If 56 doesn’t work, try 0x38.
Confirm your transaction in The Binance Extension wallet
Upon Success you will see a similar output
View your delegation overview
You can see the staking history
How to Redelegate Your BNB with Binance Extension Wallet
By staking your BNB, you participate in the selection process of BNB Smart Chain validators and earn rewards. Staking BNB is critical for securing the network. Validators can self-bond, meaning they can delegate BNB to themselves, and they can also receive delegations from any other BNB holders.
Redelegations between a unique delegator, source validator, and destination validator can only happen once every 7 days.
Click on Redelegate
Select a new validator and input amount to redelegate
Confirm your transaction in the Binance Extension Wallet
Upon Success you will see a similar output
Refresh and see your delegation changes
How to Undelegate Your BNB with Binance Extension Wallet
Click on Undelegate
Input the amount
Confirm your transaction in the Binance Extension Wallet
BNB Smart Chain is compatible with MetaMask. Users can use MetaMask as a bridge between Trezor and BNB Smart Chain to make transactions to the BNB Smart Chain testnet.
1) Connect MetaMask to BSC Testnet by following this guide to add a custom network
Please refer to MetaMask Doc, the only difference is we injected a different object.
BinanceChain.on('accountsChanged',(accounts)=>{ // Handle the new accounts, or lack thereof. // "accounts" will always be an array, but it can be empty. }); BinanceChain.on('chainChanged',(chainId)=>{ // Handle the new chain. // Correctly handling chain changes can be complicated. // We recommend reloading the page unless you have a very good reason not to. window.location.reload(); });
This snippet explains how to accomplish the three most common requirements for web3 sites:
Detect which BinanceChain network the user is connected to
Get the user's BinanceChain account(s)
/**********************************************************/ /* Handle chain (network) and chainChanged (per EIP-1193) */ /**********************************************************/ // Normally, we would recommend the 'eth_chainId' RPC method, but it currently // returns incorrectly formatted chain ID values. let currentChainId = BinanceChain.chainId; BinanceChain.on('chainChanged', handleChainChanged); function handleChainChanged(_chainId) { // We recommend reloading the page, unless you must do otherwise window.location.reload(); } /***********************************************************/ /* Handle user accounts and accountsChanged (per EIP-1193) */ /***********************************************************/ let currentAccount = null; BinanceChain .request({ method: 'eth_accounts' }) .then(handleAccountsChanged) .catch((err) => { // Some unexpected error. // For backwards compatibility reasons, if no accounts are available, // eth_accounts will return an empty array. console.error(err); }); // Note that this event is emitted on page load. // If the array of accounts is non-empty, you're already // connected. BinanceChain.on('accountsChanged', handleAccountsChanged); // For now, 'eth_accounts' will continue to always return an array function handleAccountsChanged(accounts) { if (accounts.length === 0) { // Binance Extension Wallet is locked or the user has not connected any accounts console.log('Please connect to Binance Extension Wallet.'); } else if (accounts[0] !== currentAccount) { currentAccount = accounts[0]; // Do any other work! } } /*********************************************/ /* Access the user's accounts (per EIP-1102) */ /*********************************************/ // You should only attempt to request the user's accounts in response to user // interaction, such as a button click. // Otherwise, you popup-spam the user like it's 1999. // If you fail to retrieve the user's account(s), you should encourage the user // to initiate the attempt. document.getElementById('connectButton', connect); function connect() { BinanceChain .request({ method: 'eth_requestAccounts' }) .then(handleAccountsChanged) .catch((err) => { if (err.code === 4001) { // EIP-1193 userRejectedRequest error // If this happens, the user rejected the connection request. console.log('Please connect to MetaMask.'); } else { console.error(err); } }); }
!!! warning
You should never rely on any of these methods, properties, or events in practice.
This section documents MetaMask's legacy provider API.
To be compatible with existing dApps that support MetaMask, Binance Extension Wallet implements them as well, but please don't rely on them. We may deprecate them soon in the future.
Since BNB Smart Chain and Ethereum follow the same address generation algorithm. In some cases, users may mistakenly choose the wrong network type when withdrawing tokens to BNB Smart Chain network.
Please refer to MetaMask Doc, the only difference is we injected a different object.
BinanceChain.on('accountsChanged',(accounts)=>{ // Handle the new accounts, or lack thereof. // "accounts" will always be an array, but it can be empty. }); BinanceChain.on('chainChanged',(chainId)=>{ // Handle the new chain. // Correctly handling chain changes can be complicated. // We recommend reloading the page unless you have a very good reason not to. window.location.reload(); });
This snippet explains how to accomplish the three most common requirements for web3 sites:
Detect which BinanceChain network the user is connected to
Get the user's BinanceChain account(s)
/**********************************************************/ /* Handle chain (network) and chainChanged (per EIP-1193) */ /**********************************************************/ // Normally, we would recommend the 'eth_chainId' RPC method, but it currently // returns incorrectly formatted chain ID values. let currentChainId = BinanceChain.chainId; BinanceChain.on('chainChanged', handleChainChanged); function handleChainChanged(_chainId) { // We recommend reloading the page, unless you must do otherwise window.location.reload(); } /***********************************************************/ /* Handle user accounts and accountsChanged (per EIP-1193) */ /***********************************************************/ let currentAccount = null; BinanceChain .request({ method: 'eth_accounts' }) .then(handleAccountsChanged) .catch((err) => { // Some unexpected error. // For backwards compatibility reasons, if no accounts are available, // eth_accounts will return an empty array. console.error(err); }); // Note that this event is emitted on page load. // If the array of accounts is non-empty, you're already // connected. BinanceChain.on('accountsChanged', handleAccountsChanged); // For now, 'eth_accounts' will continue to always return an array function handleAccountsChanged(accounts) { if (accounts.length === 0) { // Binance Extension Wallet is locked or the user has not connected any accounts console.log('Please connect to Binance Extension Wallet.'); } else if (accounts[0] !== currentAccount) { currentAccount = accounts[0]; // Do any other work! } } /*********************************************/ /* Access the user's accounts (per EIP-1102) */ /*********************************************/ // You should only attempt to request the user's accounts in response to user // interaction, such as a button click. // Otherwise, you popup-spam the user like it's 1999. // If you fail to retrieve the user's account(s), you should encourage the user // to initiate the attempt. document.getElementById('connectButton', connect); function connect() { BinanceChain .request({ method: 'eth_requestAccounts' }) .then(handleAccountsChanged) .catch((err) => { if (err.code === 4001) { // EIP-1193 userRejectedRequest error // If this happens, the user rejected the connection request. console.log('Please connect to MetaMask.'); } else { console.error(err); } }); }
!!! warning
You should never rely on any of these methods, properties, or events in practice.
This section documents MetaMask's legacy provider API.
To be compatible with existing dApps that support MetaMask, Binance Extension Wallet implements them as well, but please don't rely on them. We may deprecate them soon in the future.
Open imToken, click "Create Identity" and click to agree to the terms of service.
Fill in your identity name and wallet password. Next, click "Create", copy the backup mnemonic phrase with pen and paper and keep it in a safe place. Confirm the mnemonic words in order again and click "Next" to successfully create a wallet.
BSC is the abbreviation of BNB Smart Chain. The chain adopts PoSA (Proof of Staked Authority), which means holders of BNB (BSC's native token) vote to select 55 validators that are responsible for on-chain transaction verification and block production.
Since BSC is EMV-compatible, developers can easily deploy smart contracts and build DApps on the chain. Compared with Ethereum, BSC has lower gas fees and faster transaction settlement with lower security guarantees.
With imToken wallet, we do not only support BSC DApps and watching token balances but also the DeFi Portfolio feature, providing a holistic BSC experience.
Click on "Ecosystem Applications" on the asset homepage to view and experience recent popular DApps on the BSC chain.
How to Send Funds from Binance to your imToken Wallet
To withdraw BSC assets from Binance to imToken, you can follow the steps below. We use the BNB token as an example.
Click on the wallet address, enter the payment page, and click "Copy".
Open Binance, click "Funds"-"Withdraw", select "BNB" or other BSC-supported assets.
Select "BEP20 (BSC)" in "Network", paste the copied address, and enter the withdrawal password to proceed with withdrawal. Make sure it’s the correct address.
Withdraw coins from imToken wallet to Binance Exchange
If you want to recharge assets on BSC from imToken to Binance Exchange, you can follow the steps below, here is BNB as an example.
Enter Binance Exchange, click "Assets"-"Recharge", select "BNB" or other BSC-supported assets.
Select "BEP20 (BSC)" in "Network" and click to copy the BNB recharge address.
On the asset page, click BNB to enter the transfer page, click "Transfer", paste Binance's recharge address, enter the withdrawal amount, and click "Next" to complete the transfer after paying the miner's fee.
Risk Warning: The content of this article does not constitute any form of investment advice or recommendation. imToken does not make any guarantees and promises for the third-party services and products mentioned in this article, nor assume any responsibility. Digital asset investment has risks. You should carefully evaluate these investment risks and consult with relevant professionals to make your own decisions.
-
+
diff --git a/docs/wallets/tutorial/how-to-create-a-wallet-on-trustwallet.html b/docs/wallets/tutorial/how-to-create-a-wallet-on-trustwallet.html
index df21201bb8..cad795834a 100644
--- a/docs/wallets/tutorial/how-to-create-a-wallet-on-trustwallet.html
+++ b/docs/wallets/tutorial/how-to-create-a-wallet-on-trustwallet.html
@@ -9,7 +9,7 @@
-
+
@@ -25,7 +25,7 @@
30+ Blockchains, including Bitcoin, Ethereum,
BNB, XRP and many more.
Exchange these cryptocurrencies with our upcoming coin swap function and buy Bitcoin, Ethereum and more with your credit card.
2) Click "Unlock wallet" on the top right navigation bar
The recommended way for unlocking is by WalletConnect or Ledger.
If you use Ledger, please select the address you want to use for this session.
After unlocking your wallet, make sure that your balance is correct by clicking the "Balance" button on the navigation bar. Then, you will go to: https://www.binance.org/en/balances
4) Place your order (Found on the bottom right of the page)
At the moment, Binance DEX only supports Limit Orders.
You can use the "Best Ask" to input the minimum price that you can currently buy for.
You use the "Best Bid" to input the highest price that you can currently sell for.
"Price" - The number of tokens per token that you are willing to buy / sell for. "Price" can only be changed with "Tick Size". For $ONE, the tick size is 0.00000001
"Amount" the number of tokens you wish to buy / sell. "Amount" can only be changed with "Lot Size". For $ONE, the lot size is 10.
"25% / 50% / 75% / 100%" This will allocate the selected percentage of your funds to either be sold or used to buy.
For example on the buy side if you want to buy 100$ONE and your limit price is 0.0006625. Then, the total notional for this order is 0.06625.
Click "Buy ONE" Confirm the submission of your order.
"Not enough balance" A common error that will occur if the number of tokens required to execute the order is more than the total number of tokens displayed in your "Total" balance.
Price warning - if the price you inputted an order at is above 2% higher than the latest market price then you will be notified. Proceed with caution.
A note will pop up on the right corner of your screen after you confirmed your order.
5) Verifying your order was created and placed
Once you made an order, you can see that in your order history on the first tab at the bottom left of the page.
Once filled you can view your completed trades under "Order History" on the second tab at the bottom left of the page.
To check wallet balance click the "Balance" button
6) Cancelling open orders
To cancel an order that has either not been filled or has only been partially filled you can click on the "X" at the right side of the "Open Orders" tab on the bottom right of the screen.
-
+
diff --git a/docs/wallets/tutorial/ledger-nano-s-usage-guide.html b/docs/wallets/tutorial/ledger-nano-s-usage-guide.html
index 01c31c09d2..d235217507 100644
--- a/docs/wallets/tutorial/ledger-nano-s-usage-guide.html
+++ b/docs/wallets/tutorial/ledger-nano-s-usage-guide.html
@@ -9,7 +9,7 @@
-
+
@@ -20,7 +20,7 @@
If it is, the installation has been successful.
Choose one address to use for this session and click on "Confirm".
You will then be redirected to the Trading Interface.
For your security, please read the information displayed in the following popup and confirm that the address shown on your Ledger device matches the one shown on-screen.
Press the right button on your device to confirm that the address matches (You must do this to continue).
This guide will show you how to use your Trezor Model T hardware wallet with BNB Beacon Chain and Binance DEX.
Please follow best security practices when using any hardware wallet to store cryptocurrency.
Please note that the Trezor Model One is not supported yet.
Tutorials on Using Third-Party Wallets on BNB Smart Chain
BNB Smart Chain offers extensive support of third-party wallets that can be used for sending/receiving/buying/exchanging/staking BNB Tokens. Below we provide a list of the most popular wallets.
BNBChain List is a list of BSC-related networks, including BNB Smart Chain (BSC) and its Application Sidechains (BAS). Users can use the information to connect their wallets and Web3 middleware providers to the appropriate Chain ID and Network ID to connect to the correct chain.
For production we need to store our metadata in a permanent location that can exist for the life of the token.
In the bottom left-hand side of the interface, you can locate Open Orders, Order History, Trade History, and Balances.
.png)
Congratulations, you have successfully deployed your smart contract to the blockchain and verified it, now it's time to interact with your deployed smart contract.
You can also verify your NFT on 
icon in the bottom left corner of the IDE to generate new keypair to perform transactions. You can skip this step if you already have generated a keypair. On the Keypair Manager, click on the CREATE button to generate new keypair.
in our case.
to build your smart contract. Upon successful build, the project navigation pane reflects a new folder named build. This folder contains contracts folder that has json files of the contracts built. All of the contracts imported in our BSCNFT contract are also built and imported as json files. 
for deploying your smart contract. Specify the details for your contract, as shown below, then click on the Estimate & Deploy button. The wizard will auto-estimate and fill the gas limit for your contract. Then click the Deploy button. 
icon to open the web interface for deloyment in a new browser tab.
