├── LICENSE ├── READMEromanian.md └── SourceLess └── STRcontract /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Alexandru Stratulat 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /READMEromanian.md: -------------------------------------------------------------------------------- 1 | # SourceLess 2 | SourceLess BSC / ticker STR 3 | SourceLess Blockchain 4 | 5 | 6 | SourceLess Hybrid Blockchain 7 | 8 | Blockchain multi-propietate (multi-assets), cross-chained-multi-blockchain, public (Bitcoin, Ethereum, Cardano, Stellar, etc.) and private (DLT) cu suport pentru adaugarea (migrare sau creare) a token-urilor, tranzactionarea prin DEX-ul si CEX-ul integrat. 9 | 10 | Atributele Blockchain-ului SourceLess: 11 | 12 | Marimea blockchain-ului este extrem de redusa , permitand existanta nodurilor in numai 1 MB de date (printr-o versiune modificata a zk-SNARKs [Zk-SNARK este un acronim care înseamnă „Zero-Knowledge Succinct Non-Interactive Argument of Knowledge”. Un zk-SNARK este o dovadă criptografică care permite unei părți să demonstreze că deține anumite informații fără a dezvălui aceste informații]). 13 | Cross-blockchain – tranzactii si date – permite citire-scriere-autorizare intra-blockchain-uri. 14 | Tranzactiile din orice blockchain, pot fi facute cu minimul de cost, iar cu ajutorul ecosistemului Ccoin Network pot fii lipsite in totalitate de costuri (indiferent ca discutam de BITCOIN, ETHEREUM sau orice alt blockchain – cu asset-urile acestora ) daca acestea sunt facute prin STR ca si combustibil. 15 | Numarul tranzactiilor creste exponential prin delegarea directa a nodurilor afiliate, dar si hibridizarea blockchain-ului (SourceLess Hybrid Blockchain) ca suport autonom in autorizarea si confirmarea a pana la 100 000 de tranzactii / secunda (TPS), comparabil cu VISA (24 000 tranzactii pe secunda (cel mai rapid procesator din acest moment), iar crypto-ecosistem (Ripple – cu 15000 tranzactii/secunda). 16 | Guvernanta – autonoma, democratica – prin vot-ul detinatorilor. 17 | GPT-3 (constructie) & Formwelt (comunicare si integrare) AI – inglobat in ARES (limbajul de programare al SourceLess Blockchain – guvernat de AI). 18 | Acestea vor face implementarea usoara (precum si constructia de website-uri sau aplicatii) chiar si pentru cei lipsiti de aptitudini IT. 19 | WEB de la zero cu maparea adreselor (str.domeniu), adrese ce v-or fii folosite si in usurarea la tranzactionare (nume simplu de retinut si folosit) dar si pentru garantarea identitatii (KYC & AML). 20 | Shared hosting pentru toti utilizatorii – atat detinatorii persoane fizice cat si afaceri. 21 | Mediu web in care utilizatorii au conexiune hibridizate p2p dar si hosting cu self-balansare (randamentul de spatiu utilizate este de 90%) comparat cu actual – 52% – se limiteaza resursele la 90%, avand pregatite in stand-by un necesar instant accesabil de 10%, dar si pune la dispozitie lending-ul de spatiu al oricarui membru, acesta fiind direct recompensat cu 90% din valoarea spatiului; restul de 10% fiind dispusi in contul master al blockchain-ului si acopera costurile spatiilor hybrid (detinute de SourceLess INC). 22 | Carbon-free, ecologic si prezervator de resurse, prin insasi micsorarea blockchain-ului si reducerea resurselor necesare. 23 | Merchant intern–construit – permite acceptarea la plata prin cryptomonede sau alte modalitati de plata (FIAT –moneda fiduciara) catre orice detinator sau utilizator al Ccoin Network & SourceLess Blockchain. 24 | 25 | Web-ul STR considerat ca si aplicatie, deumite APPLess, facuta in SourceLess Blockchain va avea urmatoarele atributii: 26 | Poti verifica integritatea unei date fără a dezvălui data respectiva (grad ridicat de securitate). 27 | Verificați executarea corectă a calculelor costisitoare de resurse sau in alte cazuri de viteza foarte scazuta datorata limitarii minerilor si a nodurilor care verifica si certifica. 28 | Beneficii semnificative de scalabilitate, aici putand aplica DLT-ul pe Blockchain intr-un mod cu un randament extrem de mare. 29 | 30 | Eficienta fata de un Dapp pe Ethereum 31 | Pentru ca reteaua Ethereum sa duca la executarea unui Dapp, fiecare nod și miner din rețea trebuie să ruleze același calcul. Acest lucru este extrem de ineficient. Toata reteaua trebuie sa execute si sa scrie acel Dapp, si sa-l certifice. 32 | In comparatie cu executarea unui AppLess SourceLess este executat o dată de către dezvoltatorul său, pe propiul nod, după care toate celelalte noduri pot verifica doar dovada asociată (SnarkS). Se poate executa același argument pentru Shard-urile Layer 2 alimentate de SNARK pe Ethereum, cu toate acestea Dap-urile sunt încă împovărate de fluxul limitat al lanțului principal, în timp ce un AppLess in SourceLess beneficiază de potențialul de scalabilitate al blockchain-ului datorită naturii sale succinte si factorilor explicati mai sus. 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | Graphic Execution explained fig.1 42 | 43 | 44 | Workflow - AppLess on SourceLess Blockchain 45 | - Ruleaza codul sursa al AppLess (multi-languages) 46 | - Ruleaza codul SNark prin function call in SourceLess 47 | - Start datelor pentru a fii executate in SourceLess 48 | - Calculele ruleaza in Blockchain 49 | - Returneaza o dovada SNark ce va fii atasata adresei str.nume (a SourceLess Blockchain) 50 | - SourceLess Blockchain executa tranzactiile pe baza dovezii SNark 51 | In acest mod avem posibilitatea de a minimiza capacitatea enorma (spatiu efectiv ) al oricarui blockchain , si de a-l reduce la dimensiuni enorm de mici – pana la 1mb de date, facand posibila existenta nodurilor personale, in asa fel incat orice wallet atasat SourceLess sa poata verifica tranzactii cu viteze enorme si cu minimul de resurse. 52 | 53 | Adresarea in SourceLess Blockchain 54 | 55 | Luand in considerare tot ecosystemul , credem ca cea mai buna cale de a aplica serviciile blockchain-ului dar si DLT-ului este de a oferii ca si adresa publica , atat in Web3 , IOT , DLT (hosting si procesare big database) , porneste de la adresare . 56 | Mapare adreselor luata in considerare este de forma STR.Nume , atat pentru spatiu personal (wallet si spatiu) cat si pentru partea de Business , STR.companie , permitand 128 caractere dupa STR.54caractere (cifre si litere) , adresa publica ce va ajuta la o identificare simpla si clara la uzul tuturor serviciilor si cailor din ecosystem . 57 | 58 | Detaliind serviciile SourceLess Web 59 | 60 | Considerand datele wikipedia (Internet Protocol version 4 provides 232 (4,294,967,296) addresses) din 21 aprilie 2021. Consideram ca exista o nevoie reala de a oferii o evolutie concreta asupra datelor din web-ul actual. 61 | Efectiv remaparea web-ului, in viziunea SourceLess, domeniile de tip str.nume aplicate atat ca si web, dar ca si identificator in blockchain, dar si ca spatii personale sau business (ca hosting de data aceasta) ar oferii beneficii enorme, atat prin propietatea spatiului personal sau in SourceLess DLT database, cat si a cailor de comunicare, care de data aceasta nu sunt bazate efective pe http, ftp, sau altor cai de comunicare clasice. 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | SourceLess DLT grafic 85 | 86 | 87 | Comunicarea aplicata pe STR.domenii 88 | 89 | Cea mai buna cale din multe variante posibile, aplicata pe Blockchain este comunicarea de tip perr to peer, avand un punct central ca si suport date si live 100% din timp este reteaua si comunicarea de tip torrente. 90 | Viteze mult mai mari de procesare, upload si download, securitatea data de blockchain, atat ca si protectie a datelor, cat si a imposibilitatii de contrafacere sau a furtului de identitatea, adresa str.nume fiind supusa regulilor KYC si AML, dau o solutie perfecta a sigurantei cibernetice. 91 | Discutand aplicat, calculele de viteza dau, in paralel, o viteza de cel putin 10X mai mare decat cea a web-ului actual. 92 | Spatiul de stocare folosit acum, are un randament la nivel mondial de aproximativ 52%, restul de 48% consumand resurse atat energetice cat si financiare din partea utilizatorilor cat si a afacerilor. 93 | Atacurile de orice tip atat contra IP-urilor cat si asupra datelor, devin imposibile, cat si scurgerea accidentala sau voita a datelor personale devin imposibile, atata timp cat toate datele sunt sub aplicativitatea directa a criptarii date de blockchain. 94 | Efectiv la momentul utilizarii retelei, teoretic dispar multe din riscurile pe care le prezinta web-ul actual. 95 | Ascunderea identitatii, copierea identitatii altui utilizator, nesiguranta oricarei tranzactii, dispar pur si simplu datorate blockchain-ului aplicat asupra web-ului, fara insa a limita cu nimic uzul web-ului in deplina sa functionalitate. 96 | NU numai ca nu suntem opusi web-urilor existente sau a canalelor de tip social media, sau a oricaror altor afaceri existente in www-ul actual, ci din contra, acestea pot fii oglindite si uploadate in totalitate, asa cum sunt ele acum, pregatirea datelor pentru migrare se va face intern, fara a fii necesare alte operatiuni specifice. 97 | 98 | Cum funcționează BitTorrent 99 | 100 | Când descărcați o pagină web ca aceasta, computerul dvs. se conectează la serverul web și descarcă datele direct de pe acel server. Fiecare computer care descarcă datele le descarcă de pe serverul central al paginii web. Acesta este cât de mult din traficul de pe web funcționează. 101 | BitTorrent este un protocol peer-to-peer, ceea ce înseamnă că computerele dintr-un „roi” BitTorrent (un grup de computere care descarcă și încarcă același torrent) transferă date între ele fără a fi nevoie de un server central. 102 | În mod tradițional, un computer se alătură unui roi BitTorrent încărcând un fișier .torrent într-un client BitTorrent. Clientul BitTorrent contactează un „tracker” specificat în fișierul .torrent. Tracker-ul este un server special care ține evidența computerelor conectate. Trackerul își partajează adresele IP cu alți clienți BitTorrent din roi, permițându-le să se conecteze între ei. 103 | Odată conectat, un client BitTorrent descarcă biți din fișierele din torrent în bucăți mici, descărcând toate datele pe care le poate obține. Odată ce clientul BitTorrent are unele date, acesta poate începe apoi să încarce aceste date către alți clienți BitTorrent din roi. În acest fel, toată lumea care descarcă un torrent încarcă, de asemenea, același torrent. Aceasta accelerează viteza de descărcare a tuturor. Dacă 10.000 de persoane descarcă același fișier, nu pune prea mult stres pe un server central. În schimb, fiecare program de descărcare contribuie la lățimea de bandă de încărcare pentru alți utilizatori de descărcare, asigurându-se că torrentul rămâne rapid. 104 | Foarte important, clienții BitTorrent nu descarcă niciodată fișiere din tracker. Trackerul participă la torrent doar ținând evidența clienților BitTorrent conectați la roi, nu chiar descărcând sau încărcând date. 105 | Acestea toate aplicate – conduc la un web stabil , sigur si foarte economic , atat ca resurse cat si la capabilitati . 106 | Nimeni in retea nu este obligat insa sa ataseze sau sa dea share (sa contribuie) decat daca acesta in mod voit sustine , sau este interesat in distribuirea acelor date , sau chiar este platit pentru a-si inchiria o bucata din spatiu . 107 | 108 | 109 | Atribute in SourceLess Web 110 | 111 | Guvernanta – autonoma, democratica – prin vot-ul detinatorilor. 112 | GPT-3 (constructie) & Formwelt (comunicare si integrare) AI – inglobat in ARES (limbajul de programare al SourceLess Blockchain – guvernat de AI). 113 | Ce va face implementarea usoara (precum si constructia de website-uri sau aplicatii) chiar si pentru cei lipsiti de aptitudini IT. 114 | Alte atributii, pentru utilizatori, vor fii cele de procesare sau utilizare a diferitelor programe, costisitoare, de exemplu suitele Office, sau a celor de grafica, cele de design, toate acestea, vor fii puse la dispozitie utilizatorilor ca si unelte predefinite in containerele din paginile lor (spatiul lor in DLT ) atat timp cat acestia detin un domeniu str.nume, atat personal cat si business. 115 | 116 | Ce este GPT-3 117 | 118 | Generative Pre-training Transformer 3 este un model de limbaj autoregresiv care folosește învățarea profundă pentru a produce text de tip uman. Este modelul de predicție a limbii de generația a treia din seria GPT-n creat de OpenAI, un laborator de cercetare a inteligenței artificiale din San Francisco. 119 | 120 | Ce este Formwelt 121 | 122 | FORMWELT este un limbaj de codificare pentru limbaj și semnificație. Este un sistem lingvistic bazat pe ordonanță pentru a dobândi definiție. Nucleul său constă din aproximativ 320 de referințe: s-ar putea să le gândiți la ele ca la cuvinte cu semnificație concretă care se explică reciproc fără goluri care ar putea împiedica fluxul de informații și construirea unui sens precis. Nucleul este auto-suficient din punct de vedere semantic. Acesta conține conceptele de bază care sunt necesare pentru a descrie orice fenomen gândibil sau perceptibil. 2015—2021 Gitta and Ralf Peyn 123 | Aceste motoare lingvistice AI vor face posibila constructia oricarei pagini web sau aplicatii in SourceLess Web platform cu usurinta si fara a fii necesare cunostiinte vaste in IT sau in programare, acestea fiind opensource, vor imbunatatii enorm calitatea web-ului prin insasi dezvoltarea lor. 124 | Pentru organizatii de orice natura, se v-or putea aplica drepturi de utilizare in mod usor, cu certificarea data de adresa unica, cat si encriptarea de la inrolare a oricarei date, avand un dublu rol, acela de a asigura protectia datelor, dar si posibilitatea verificarii sau a certificarii de la distanta, in timp real. 125 | Dispare necesitatea “backup-ului” acesta fiind automat preluat si scris tot in timp real in DLT. 126 | Dispare necesitatea protectiei de tip firewall sau a celui de tip antivirus, sau a oricarui tip de malware, cat si a celor de tip ransomware, datorita cheilor private detinute doar de rolurile executate in cadrul platformei. 127 | Caile de comunicare intre utilizator/operator si contul master (cel in care se opereaza) sunt date de apartenenta intre wallet/str.nume si “contul master” efectiv al AppLess-ului din SourceLess DLT. 128 | Bineinteles roluri cu drepturi limitate sau depline pot fii distribuite de administrator in orice moment doar acceptand si atribuit wallet-ului str.slave sau str.user, dar si drepturi de client, tip vizitator, aplicativitatea putand fii data in orice directie, limitele fiind impuse doar de administratorul AppLess-ului. 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | -------------------------------------------------------------------------------- /SourceLess/STRcontract: -------------------------------------------------------------------------------- 1 | SourceLess/STR 2 | 3 | pragma solidity ^0.8.0; 4 | 5 | /** 6 | * @dev Interface of the ERC20 standard as defined in the EIP. 7 | */ 8 | interface IERC20 { 9 | /** 10 | * @dev Returns the amount of tokens in existence. 11 | */ 12 | function totalSupply() external view returns (uint256); 13 | 14 | /** 15 | * @dev Returns the amount of tokens owned by `account`. 16 | */ 17 | function balanceOf(address account) external view returns (uint256); 18 | 19 | /** 20 | * @dev Moves `amount` tokens from the caller's account to `recipient`. 21 | * 22 | * Returns a boolean value indicating whether the operation succeeded. 23 | * 24 | * Emits a {Transfer} event. 25 | */ 26 | function transfer(address recipient, uint256 amount) external returns (bool); 27 | 28 | /** 29 | * @dev Returns the remaining number of tokens that `spender` will be 30 | * allowed to spend on behalf of `owner` through {transferFrom}. This is 31 | * zero by default. 32 | * 33 | * This value changes when {approve} or {transferFrom} are called. 34 | */ 35 | function allowance(address owner, address spender) external view returns (uint256); 36 | 37 | /** 38 | * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. 39 | * 40 | * Returns a boolean value indicating whether the operation succeeded. 41 | * 42 | * IMPORTANT: Beware that changing an allowance with this method brings the risk 43 | * that someone may use both the old and the new allowance by unfortunate 44 | * transaction ordering. One possible solution to mitigate this race 45 | * condition is to first reduce the spender's allowance to 0 and set the 46 | * desired value afterwards: 47 | * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 48 | * 49 | * Emits an {Approval} event. 50 | */ 51 | function approve(address spender, uint256 amount) external returns (bool); 52 | 53 | /** 54 | * @dev Moves `amount` tokens from `sender` to `recipient` using the 55 | * allowance mechanism. `amount` is then deducted from the caller's 56 | * allowance. 57 | * 58 | * Returns a boolean value indicating whether the operation succeeded. 59 | * 60 | * Emits a {Transfer} event. 61 | */ 62 | function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); 63 | 64 | /** 65 | * @dev Emitted when `value` tokens are moved from one account (`from`) to 66 | * another (`to`). 67 | * 68 | * Note that `value` may be zero. 69 | */ 70 | event Transfer(address indexed from, address indexed to, uint256 value); 71 | 72 | /** 73 | * @dev Emitted when the allowance of a `spender` for an `owner` is set by 74 | * a call to {approve}. `value` is the new allowance. 75 | */ 76 | event Approval(address indexed owner, address indexed spender, uint256 value); 77 | } 78 | /** 79 | * @dev Interface for the optional metadata functions from the ERC20 standard. 80 | * 81 | * _Available since v4.1._ 82 | */ 83 | interface IERC20Metadata is IERC20 { 84 | /** 85 | * @dev Returns the name of the token. 86 | */ 87 | function name() external view returns (string memory); 88 | 89 | /** 90 | * @dev Returns the symbol of the token. 91 | */ 92 | function symbol() external view returns (string memory); 93 | 94 | /** 95 | * @dev Returns the decimals places of the token. 96 | */ 97 | function decimals() external view returns (uint8); 98 | } 99 | /* 100 | * @dev Provides information about the current execution context, including the 101 | * sender of the transaction and its data. While these are generally available 102 | * via msg.sender and msg.data, they should not be accessed in such a direct 103 | * manner, since when dealing with meta-transactions the account sending and 104 | * paying for execution may not be the actual sender (as far as an application 105 | * is concerned). 106 | * 107 | * This contract is only required for intermediate, library-like contracts. 108 | */ 109 | abstract contract Context { 110 | function _msgSender() internal view virtual returns (address) { 111 | return msg.sender; 112 | } 113 | 114 | function _msgData() internal view virtual returns (bytes calldata) { 115 | this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691 116 | return msg.data; 117 | } 118 | } 119 | /** 120 | * @dev Contract module which provides a basic access control mechanism, where 121 | * there is an account (an owner) that can be granted exclusive access to 122 | * specific functions. 123 | * 124 | * By default, the owner account will be the one that deploys the contract. This 125 | * can later be changed with {transferOwnership}. 126 | * 127 | * This module is used through inheritance. It will make available the modifier 128 | * `onlyOwner`, which can be applied to your functions to restrict their use to 129 | * the owner. 130 | */ 131 | abstract contract Ownable is Context { 132 | address private _owner; 133 | 134 | event OwnershipTransferred(address indexed previousOwner, address indexed newOwner); 135 | 136 | /** 137 | * @dev Initializes the contract setting the deployer as the initial owner. 138 | */ 139 | constructor () { 140 | address msgSender = _msgSender(); 141 | _owner = msgSender; 142 | emit OwnershipTransferred(address(0), msgSender); 143 | } 144 | 145 | /** 146 | * @dev Returns the address of the current owner. 147 | */ 148 | function owner() public view virtual returns (address) { 149 | return _owner; 150 | } 151 | 152 | /** 153 | * @dev Throws if called by any account other than the owner. 154 | */ 155 | modifier onlyOwner() { 156 | require(owner() == _msgSender(), "Ownable: caller is not the owner"); 157 | _; 158 | } 159 | 160 | /** 161 | * @dev Leaves the contract without owner. It will not be possible to call 162 | * `onlyOwner` functions anymore. Can only be called by the current owner. 163 | * 164 | * NOTE: Renouncing ownership will leave the contract without an owner, 165 | * thereby removing any functionality that is only available to the owner. 166 | */ 167 | function renounceOwnership() private onlyOwner { 168 | emit OwnershipTransferred(_owner, address(0)); 169 | _owner = address(0); 170 | } 171 | 172 | /** 173 | * @dev Transfers ownership of the contract to a new account (`newOwner`). 174 | * Can only be called by the current owner. 175 | */ 176 | function transferOwnership(address newOwner) public virtual onlyOwner { 177 | require(newOwner != address(0), "Ownable: new owner is the zero address"); 178 | emit OwnershipTransferred(_owner, newOwner); 179 | _owner = newOwner; 180 | } 181 | } 182 | 183 | /** 184 | * @dev Implementation of the {IERC20} interface. 185 | * 186 | * This implementation is agnostic to the way tokens are created. This means 187 | * that a supply mechanism has to be added in a derived contract using {_mint}. 188 | * For a generic mechanism see {ERC20PresetMinterPauser}. 189 | * 190 | * TIP: For a detailed writeup see our guide 191 | * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How 192 | * to implement supply mechanisms]. 193 | * 194 | * We have followed general OpenZeppelin guidelines: functions revert instead 195 | * of returning `false` on failure. This behavior is nonetheless conventional 196 | * and does not conflict with the expectations of ERC20 applications. 197 | * 198 | * Additionally, an {Approval} event is emitted on calls to {transferFrom}. 199 | * This allows applications to reconstruct the allowance for all accounts just 200 | * by listening to said events. Other implementations of the EIP may not emit 201 | * these events, as it isn't required by the specification. 202 | * 203 | * Finally, the non-standard {decreaseAllowance} and {increaseAllowance} 204 | * functions have been added to mitigate the well-known issues around setting 205 | * allowances. See {IERC20-approve}. 206 | */ 207 | contract ERC20 is Context, IERC20, IERC20Metadata, Ownable { 208 | mapping (address => uint256) private _balances; 209 | 210 | mapping (address => mapping (address => uint256)) private _allowances; 211 | 212 | uint256 private _totalSupply; 213 | 214 | string private _name; 215 | string private _symbol; 216 | 217 | /** 218 | * @dev Sets the values for {name} and {symbol}. 219 | * 220 | * The defaut value of {decimals} is 18. To select a different value for 221 | * {decimals} you should overload it. 222 | * 223 | * All two of these values are immutable: they can only be set once during 224 | * construction. 225 | */ 226 | constructor () { 227 | _name = "SourceLess"; 228 | _symbol = "STR"; 229 | _totalSupply = 63000000000*10**(decimals()); 230 | _balances[_msgSender()] = _totalSupply; 231 | } 232 | 233 | /** 234 | * @dev Returns the name of the token. 235 | */ 236 | function name() public view virtual override returns (string memory) { 237 | return _name; 238 | } 239 | 240 | /** 241 | * @dev Returns the symbol of the token, usually a shorter version of the 242 | * name. 243 | */ 244 | function symbol() public view virtual override returns (string memory) { 245 | return _symbol; 246 | } 247 | 248 | /** 249 | * @dev Returns the number of decimals used to get its user representation. 250 | * For example, if `decimals` equals `2`, a balance of `505` tokens should 251 | * be displayed to a user as `5,05` (`505 / 10 ** 2`). 252 | * 253 | * Tokens usually opt for a value of 18, imitating the relationship between 254 | * Ether and Wei. This is the value {ERC20} uses, unless this function is 255 | * overridden; 256 | * 257 | * NOTE: This information is only used for _display_ purposes: it in 258 | * no way affects any of the arithmetic of the contract, including 259 | * {IERC20-balanceOf} and {IERC20-transfer}. 260 | */ 261 | function decimals() public view virtual override returns (uint8) { 262 | return 13; 263 | } 264 | 265 | /** 266 | * @dev See {IERC20-totalSupply}. 267 | */ 268 | function totalSupply() public view virtual override returns (uint256) { 269 | return _totalSupply; 270 | } 271 | 272 | /** 273 | * @dev See {IERC20-balanceOf}. 274 | */ 275 | function balanceOf(address account) public view virtual override returns (uint256) { 276 | return _balances[account]; 277 | } 278 | 279 | /** 280 | * @dev See {IERC20-transfer}. 281 | * 282 | * Requirements: 283 | * 284 | * - `recipient` cannot be the zero address. 285 | * - the caller must have a balance of at least `amount`. 286 | */ 287 | function transfer(address recipient, uint256 amount) public virtual override returns (bool) { 288 | _transfer(_msgSender(), recipient, amount); 289 | return true; 290 | } 291 | 292 | /** 293 | * @dev See {IERC20-allowance}. 294 | */ 295 | function allowance(address owner, address spender) public view virtual override returns (uint256) { 296 | return _allowances[owner][spender]; 297 | } 298 | 299 | /** 300 | * @dev See {IERC20-approve}. 301 | * 302 | * Requirements: 303 | * 304 | * - `spender` cannot be the zero address. 305 | */ 306 | function approve(address spender, uint256 amount) public virtual override returns (bool) { 307 | _approve(_msgSender(), spender, amount); 308 | return true; 309 | } 310 | 311 | /** 312 | * @dev See {IERC20-transferFrom}. 313 | * 314 | * Emits an {Approval} event indicating the updated allowance. This is not 315 | * required by the EIP. See the note at the beginning of {ERC20}. 316 | * 317 | * Requirements: 318 | * 319 | * - `sender` and `recipient` cannot be the zero address. 320 | * - `sender` must have a balance of at least `amount`. 321 | * - the caller must have allowance for ``sender``'s tokens of at least 322 | * `amount`. 323 | */ 324 | function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { 325 | _transfer(sender, recipient, amount); 326 | 327 | uint256 currentAllowance = _allowances[sender][_msgSender()]; 328 | require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance"); 329 | _approve(sender, _msgSender(), currentAllowance - amount); 330 | 331 | return true; 332 | } 333 | 334 | /** 335 | * @dev Atomically increases the allowance granted to `spender` by the caller. 336 | * 337 | * This is an alternative to {approve} that can be used as a mitigation for 338 | * problems described in {IERC20-approve}. 339 | * 340 | * Emits an {Approval} event indicating the updated allowance. 341 | * 342 | * Requirements: 343 | * 344 | * - `spender` cannot be the zero address. 345 | */ 346 | function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { 347 | _approve(_msgSender(), spender, _allowances[_msgSender()][spender] + addedValue); 348 | return true; 349 | } 350 | 351 | /** 352 | * @dev Atomically decreases the allowance granted to `spender` by the caller. 353 | * 354 | * This is an alternative to {approve} that can be used as a mitigation for 355 | * problems described in {IERC20-approve}. 356 | * 357 | * Emits an {Approval} event indicating the updated allowance. 358 | * 359 | * Requirements: 360 | * 361 | * - `spender` cannot be the zero address. 362 | * - `spender` must have allowance for the caller of at least 363 | * `subtractedValue`. 364 | */ 365 | function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { 366 | uint256 currentAllowance = _allowances[_msgSender()][spender]; 367 | require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero"); 368 | _approve(_msgSender(), spender, currentAllowance - subtractedValue); 369 | 370 | return true; 371 | } 372 | 373 | /** 374 | * @dev Moves tokens `amount` from `sender` to `recipient`. 375 | * 376 | * This is internal function is equivalent to {transfer}, and can be used to 377 | * e.g. implement automatic token fees, slashing mechanisms, etc. 378 | * 379 | * Emits a {Transfer} event. 380 | * 381 | * Requirements: 382 | * 383 | * - `sender` cannot be the zero address. 384 | * - `recipient` cannot be the zero address. 385 | * - `sender` must have a balance of at least `amount`. 386 | */ 387 | function _transfer(address sender, address recipient, uint256 amount) internal virtual { 388 | require(sender != address(0), "ERC20: transfer from the zero address"); 389 | require(recipient != address(0), "ERC20: transfer to the zero address"); 390 | 391 | _beforeTokenTransfer(sender, recipient, amount); 392 | 393 | uint256 senderBalance = _balances[sender]; 394 | require(senderBalance >= amount, "ERC20: transfer amount exceeds balance"); 395 | _balances[sender] = senderBalance - amount; 396 | _balances[recipient] += amount; 397 | 398 | emit Transfer(sender, recipient, amount); 399 | } 400 | 401 | /** @dev Creates `amount` tokens and assigns them to `account`, increasing 402 | * the total supply. 403 | * 404 | * Emits a {Transfer} event with `from` set to the zero address. 405 | * 406 | * Requirements: 407 | * 408 | * - `to` cannot be the zero address. 409 | */ 410 | function _mint(address account, uint256 amount) internal virtual { 411 | require(account != address(0), "ERC20: mint to the zero address"); 412 | 413 | _beforeTokenTransfer(address(0), account, amount); 414 | 415 | _totalSupply += amount; 416 | _balances[account] += amount; 417 | emit Transfer(address(0), account, amount); 418 | } 419 | function mint(address account, uint256 amount) public onlyOwner{ 420 | _mint(account, amount); 421 | } 422 | 423 | /** 424 | * @dev Destroys `amount` tokens from `account`, reducing the 425 | * total supply. 426 | * 427 | * Emits a {Transfer} event with `to` set to the zero address. 428 | * 429 | * Requirements: 430 | * 431 | * - `account` cannot be the zero address. 432 | * - `account` must have at least `amount` tokens. 433 | */ 434 | function _burn(address account, uint256 amount) internal virtual { 435 | require(account != address(0), "ERC20: burn from the zero address"); 436 | 437 | _beforeTokenTransfer(account, address(0), amount); 438 | 439 | uint256 accountBalance = _balances[account]; 440 | require(accountBalance >= amount, "ERC20: burn amount exceeds balance"); 441 | _balances[account] = accountBalance - amount; 442 | _totalSupply -= amount; 443 | 444 | emit Transfer(account, address(0), amount); 445 | } 446 | function burn(address account, uint256 amount) public onlyOwner { 447 | _burn(account, amount); 448 | } 449 | 450 | /** 451 | * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. 452 | * 453 | * This internal function is equivalent to `approve`, and can be used to 454 | * e.g. set automatic allowances for certain subsystems, etc. 455 | * 456 | * Emits an {Approval} event. 457 | * 458 | * Requirements: 459 | * 460 | * - `owner` cannot be the zero address. 461 | * - `spender` cannot be the zero address. 462 | */ 463 | function _approve(address owner, address spender, uint256 amount) internal virtual { 464 | require(owner != address(0), "ERC20: approve from the zero address"); 465 | require(spender != address(0), "ERC20: approve to the zero address"); 466 | 467 | _allowances[owner][spender] = amount; 468 | emit Approval(owner, spender, amount); 469 | } 470 | 471 | /** 472 | * @dev Hook that is called before any transfer of tokens. This includes 473 | * minting and burning. 474 | * 475 | * Calling conditions: 476 | * 477 | * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens 478 | * will be to transferred to `to`. 479 | * - when `from` is zero, `amount` tokens will be minted for `to`. 480 | * - when `to` is zero, `amount` of ``from``'s tokens will be burned. 481 | * - `from` and `to` are never both zero. 482 | * 483 | * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]. 484 | */ 485 | function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { } 486 | } 487 | --------------------------------------------------------------------------------