v1.2.17

Announcing Verus v1.2.17 - URGENT AND MANDATORY VERUS-ETHEREUM BRIDGE RESTORATION AND RECOVERY UPDATE FOR VERUS AND ALL PBaaS CHAINS

UPDATE NODES TO v1.2.17 OR GREATER AS SOON AS POSSIBLE TO REMAIN CONNECTED TO THE VERUS NETWORK - ACTIVATION AND BEGINNING OF RESTORATION WILL OCCUR ON ALL CHAINS TUESDAY, JULY 7TH, 2026 AT 5:00 PM UTC, YOU MUST BE UPGRADED BY THEN TO STAY CONNECTED TO THE CHAIN BEING RESTORED AND RECOVERED NOTIFICATION ORACLES WILL BE USED TO PAUSE NODES NOT UPGRADED TO EASE THE UPGRADE PROCESS AT A LATER DATE

To our knowledge, this release represents a first in the history of blockchain and a path forward for the Verus network and community. Due to the nature of the Verus protocol, currencies on connected chains can be sent across chains and used in liquidity baskets to provide combined portfolio baskets that also earn fees for basket holders, currently through conversions and identity registrations. While deep nesting of baskets is not recommended, as we do not see the value when it gets more than 2-3 levels, people have made baskets that nest more deeply than that even contain basket reserves spanning all chains in a variety of ways as well.

After the May 17th exploit that after some asset recovery, resulted in the network loss of about 26.6% of the ETH and tBTC held in the Ethereum contract and being used to back the ETH and tBTC on Verus, the Verus network was left with many wallets and numerous liquidity baskets across 4 blockchains that had one or both of those currencies and also other baskets, which contained those currencies as reserves. At the same time, the vETH and tBCT.vETH currencies across all chains only had 73.4% of its reserves to restore to the Ethereum contract for backing.

To recover the full function of the network and have confidence in its provability, function, and continued ease of use going forward, we had to achieve the following:

1. A deep understanding and full mitigation of all weaknesses, whether seemingly small or more significant on all sides of the protocol implementation that enabled the exploit, and more than that, a plan for addressing every aspect of those weaknesses and any others found from a comprehensive, multi-party, AI-assisted audits looking for any others that might exist.
2. A plan to get specifically the vETH currencies and tBTC.vETH currencies across all chains back to a 1:1 backed state without significantly affecting pricing activity and triggering a massive, arbitrage driven volatility spike (“Arbageddon” as coined by community members), instead continuing to enable Verus’s signature constructive arbitrage to balance smoothly across other markets. This aspect of the plan is driven by the understanding that all users will expect 1:1 backing of these assets so they may easily and intuitively use the Verus PBaaS network.
3. A way for those users who lost funds from the exploit, either tBTC.vETH or vETH directly or indirectly via baskets containing them or baskets containing baskets that contained them up to multiple levels of nesting to recover their funds over time, at a rate that will depend on the usage level of the Verus Ethereum Bridge and could even result in more than a 100% return if usage rises significantly due to DREAM apps or other scalable usage of the Verus network capabilities.

While this is easy to write down as a set of ideal recovery goals, we believe that the plan we have collectively put into action responds to the challenges we have faced together to show how a non-VC backed, decentralized, community project responds to adversity with strength and resilience.

This release has involved more collective work by a number of engineers, developers, and community members with more advanced AI assistance in security review and analysis than any update ever. It will activate in phases designed to get all blockchains on the network and affected baskets, currencies, and users back to full function and a path to usage-driven loss-recovery with the least market disruption possible. These are the key points of the plan that is implemented in Verus v1.2.17:

1. The network upgrades to the broadly hardened daemon between now and Tuesday July 7th, 5:00PM UTC.
2. About ½ an hour before activation, a notification oracle will pause all listening nodes that have not yet upgraded, so that they may upgrade in the future with the least disruption.
3. Tuesday, 5:00PM UTC, the network will update to a new block solution version with a more constrained and easily verified, yet compatible transaction proof that simplifies and hardens the contract’s ability to disambiguate and prove that a submitted import is absolutely a validated export from Verus and nothing else from the Verus chain made to look like it. This is in preparation for the contract upgrade, which will verify using this enhanced transaction component proof.
4. At the same time as #3, all UTXOs containing any affected currency, whether directly vETH or tBTC.vETH will be locked for adjustment across all chains and unavailable for use for the duration of the cleanup window, which will last 2 days and 1 hour until Thursday, July 9 at 6:00PM UTC.
5. Shortly after the beginning of the window, a restricted form of DeFi will be enabled, which will result in all pending DeFi transactions to be refunded. There will also be an adjusting, multisig identity on each chain that will be able to use DeFi functions for the necessary adjustments. Normal DeFi transactions during the window will be rejected.
6. Ethereum <-> Verus notarization and bridgekeeper function will resume during the DeFi window to enable voting for the contract upgrade. All actual cross-chain imports and exports between Verus and Ethereum will continue to remain paused. This release defaults to those running bridgekeeper voting for the contract upgrade, which is essential to network restoration.
7. During the window, all affected UTXOs and baskets will be adjusted to reflect the ~26.6% change in vETH and tBTC.vETH as follows:
8. UTXOs will be adjusted such that every address controlling affected currencies will have the total value of those currencies initially reduced.
9. If addresses hold affected currencies that are baskets, all of the reserve currencies in those baskets that are not affected will be sent directly to the address that had its basket balance reduced, and this will happen on all chains, even sometimes refunding a basket reserve to an address that was holding it on one chain to another chain where the basket operates. For example, if an address on the vARRR chain is holding Bridge.vETH currency, the amount of Bridge.vETH currency it is holding will be reduced by ~26.6%, and the MKR, DAI, and VRSC that was controlled by that 26.6% reduction will be sent directly from the basket to their address on the Verus chain. These reimbursements have been implemented with full recursion, which means that if an address holds a basket with multiple levels of nesting across multiple chains, they will see reimbursements of unaffected reserves across all of the chains and nested baskets.
10. After calculation for all recursion across chains and baskets, each address with direct or indirect reduction of vETH or tBTC.vETH will get, instead of a reserve reimbursement, a “restitution credit”, based on the value of the vETH and tBTC.vETH reduced in its number and will be distributed at that amount after the Verus Ethereum bridge has been restored. The amount of this currency will be calculated to reflect a 1:1 amount of the loss in ETH value of both vETH or tBTC.vETH. The tBTC.vETH conversion rate is calculated at the conversion price of the returned ETH funds when converted to tBTC.
11. All baskets containing any affected currency are also considered affected currencies and will be reduced by ~26.6% in supply. Because of the reduction and reimbursement of reserves, all changes in all baskets will be reflected in currency states and the changes will affect liquidity, but will be price neutral relative to the market at the time DeFi was paused on the Verus network.
12. All cross-chain accounting will be adjusted to reflect the changes as well.
13. All adjustments and transactions along with every address change and the transactions will be posted both on chain, and in a detailed format with numbers, so people can identify and review their addresses and the changes that affect them.
14. After all adjustments have been made, we will undertake a process of verifying that all changes have occurred as expected, that all functions are complete, and that contracts are upgraded and fully functional as expected.
15. Once all of that has happened, the recovery funds will be sent back to the contract, and DeFi and cross-chain will be reenabled.
16. After cross-chain has been re-enabled and all functions hardened and restored, the usage currency will be sent in the appropriate amounts to all affected addresses and the process will be complete. The usage currency will earn a portion of bridge fees from the Verus Ethereum bridge usage, which can be minor with minor use or substantial with substantial use of the bridge. At any time, a holder may redeem the usage currency for whatever backing of ETH the currency has earned to date, prorated by the amount they hold relative to the total supply. This redemption is a one way process, and any redemption will reduce the supply but not the fee inflow, making the remaining holders earn more in a shorter period of time. There will be no way to generate more of this currency after initial distribution. The portion of fees from bridge usage put into the currency will continue for 3 years, regardless of how much it accrues, and after 3 years, if it has not yet recovered to a 1:1 backing of Ethereum, the protocol will continue to funnel a portion of usage fees into the currency until it does.

We realize that this has been a long description of both the update and how all changes will roll out, but it has been an incredible challenge and a great deal of work by a number of contributors. Our goal has been to get the Verus network back to full function and restore the network while giving users that experienced loss a way to recover. We have worked incredibly hard to get this release ready as soon as possible, but no sooner than when we could believe and feel confident that we had covered every aspect of a full recovery and hardened everything we needed to to ensure that this event or even something similar could not occur in the future. We look forward to a fast upgrade, full recovery, and a bright future for the Verus network.

Please be sure to update as soon as possible.

General VerusId, Verus DeFI, and Public Blockchains as a Service (PBAAS) Capabilities

• On-chain Self Sovereign, Provable Identities, NFTs, and Individual or Organizational Profiles
• On-chain Launches of Token, Centralized Currency, and Liquidity Basket AMMs
• On-chain Launches and Merge Mining of Independent, Connected, Interoperable Blockchains without Programming

Verus ID and NFT Marketplace

Buy and sell VerusIDs on-chain, advertising your offer directly to the owner of an ID or NFT, or posting the sale of your NFT on the worldwide blockchain for all the world to see. Execute transactions in a completely decentralized way. Pay or offer to pay from a transparent or zero-knowledge private address, still auditable by you. Accept payment to either as well, and best of all, execute your transactions directly, peer-to-peer without any intermediary necessary. Don’t worry the on-chain model still makes room for owners to select and share proceeds with value added agents, marketing organizations, or other participants in a new economy of provable digital ownership. It’s the next step in the evolution of VerusID, the most powerful self-sovereign identity and secure storage model for funds in the digital world.

Verus Vault

With Verus Vault you can now protect funds on a VerusID, even from theft of a private key! If you lock your VerusID with Vault you cannot spend funds from that identity at all until it is again unlocked. While locked, you can still stake those same funds on the Verus network and earn by doing so. Of course, you can also still receive funds.

IT IS IMPORTANT TO NOTE THAT ENABLING REVOCATION, RECOVERY, AND ALL VERUS VAULT CAPABILITIES REQUIRE YOU TO HAVE ONE PRIMARY IDENTITY, AND AT LEAST ONE REVOCATION/RECOVERY ID CONFIGURED.

A locked VerusID can always be revoked and recovered by its revocation and recovery authority identities, which circumvents the lock. At the same time, anyone with only the primary keys, even a multisig of primary keys must first unlock, then wait for the predetermined unlock time before they can spend or access funds. This gives you, or maybe a company that specializes in watching the blockchain to whom you've assigned the revocation ID to revoke and recover whenever an unauthorized unlock occurs. That means that like a bank, setting a 24 hour unlock delay on your locked IDs actually provides the first decentralized solution to the infamous 5 dollar wrench attack.

In addition to a new level of blockchain protection and decentralized funds recovery, Verus Vault provides the same security for your IDs and NFTs as well as time locks for other purposes, such as vesting schedules, trusts, and inheritance. With Verus Vault, you can now protect and recover your funds, preserving all your assets and generational blockchain wealth from common forms of crypto loss or theft, no bank required.

New Verus Multicurrency, Multichain, DeFi Enabled Testnet

With an easy GUI for basic operations or command line for more advanced functions. Without any programming, you can now create new identities, currencies, liquidity pools, and blockchains for your business, your government, your projects, a worthy cause, your family, or your next decentralized application suite. Send currencies worldwide on the same chain, or across blockchains with ease. Even convert currencies to others on the network without an exchange by sending to yourself and converting along the way.

The new Verus testnet is a full-featured, intrinsically decentralized multi-chain blockchain platform with an unlimited number of identities, currencies, liquidity pools, and blockchains. It is accessible from the released versions of Verus Desktop and Verus CLI wallets, and it is the beginning of a new age in crypto. There are so many things you can do with Verus that you cannot with any other cryptocurrency platform, and you can try them all today.

As Verus PBaaS offers completely new capabilities that go beyond today’s decentralized platforms in many fundamental ways, the worldwide Verus community put its energy into creation, rather than convincing everyone that its capabilities are possible. Members across the Verus worldwide community have worked hard to make this all possible, and we are more than excited that you can now experience it firsthand. If you have an interest in the future of crypto, you owe it to yourself to learn about Verus, an unlimited scale, decentralized future with truth and privacy for all.

The Verus testnet, available in the Verus Desktop or cli wallets as the VRSCTEST coin, has the following capabilities, which to our knowledge are unique in crypto today.

Self sovereign, revocable, recoverable identities (currently on mainnet) VerusID

• Enables permissionless registration of friendly name strong identities and funds addresses that are simultaneously fully self-sovereign, revocable, and recoverable.

Staking-capable time locking and theft prevention (Verus Vault)

• Enables identities to be locked, preventing any funds under their control from being spent while locked, but still allowing seamless staking of funds. When locked, a user specifies an unlock delay, typically long enough to notice when someone who might have compromised a user’s keys would have to unlock the ID before spending. The only way to circumvent the unlock delay is to revoke and recover an ID. Users may also choose to create and use fresh private keys when unlocking an ID as well. This enables virtually theft proof workflow and a solution to inheritance, trusts, vesting schedules, the 5$ wrench attack, and identity theft. IDs may be used as friendly name cryptocurrency addresses for all currencies on all Verus PBaaS blockchains in the Verus network. The VerusID protocol is a protocol, which can also be implemented on non-Verus systems.

Multi-currency, user created, decentralized tokens and merge-mineable, interoperable blockchains without programming

• Enables any user with an ID to create their own token currency or even full fledged, multi-currency, ID-issuing 50% POW/50% POS, 51% hash attack resistant blockchain that can send and receive from the Verus chain which launched it. All PBaaS chains run from the same daemon, and projects may choose to join the worldwide Verus community in improving the daemon. In doing so, they will start with a complete, multi-currency, ID-capable blockchain with DeFi capabilities that is merge-mineable and stakeable with other blockchains in the Verus network.

Consensus integrated DeFi liquidity pools and fractional currency baskets

• Any ID owner may define Verus DeFi fractional basket currencies with one or more asset currencies backing the liquidity pool at a fractional percentage ranging from 5% to 100% backing. The Verus DeFi protocol ensures that all currency conversions that use a particular liquidity pool and are mined into one block are solved and priced simultaneously, addressing the problems of miner extracted value (MEV) and front-running, while providing fee-based DeFi integrated incentives to miners and stakers, ensuring smooth consensus operation and fee conversion capabilities by integrating DeFi liquidity pools directly into the consensus and cross-chain bridge protocols.

Simultaneous blockchain and blockchain liquidity pool launches

• Launch of a world class, worldwide, merge-mineable blockchain along with a fully decentralized or centralized “bridge” converter liquidity pool as part of defining a new blockchain. Bridge converter currencies have the same flexibility as other fractional 100% asset backed or partially asset backed currencies, but is bound to the launch of the new blockchain, runs on the new blockchain, and all fees generated via cross chain fee conversions or general use of the liquidity pool are earned on the new blockchain with no rent going back to the Verus blockchain, only seamless connectivity.

Blockchain-based, crowdfunding currency launches with minimum participation or automatic refunds, including for dual launches (blockchain and bridge)

• Set required minimum levels of worldwide participation in your preferred currencies on chain. If by the start time of your blockchain, minimums are not met, all participants will automatically get a refund of all of their pre-conversions, less the network fees. The launch options also provide for maximum participation in one or more currencies, pre-launch discounts, price neutral pre-allocations to select IDs that increase the fractional reserve ratio to issue currencies, similarly price neutral carve-outs of proceeds, and pre-launch discounts for early participants. Using VerusIDs, launches can also include vesting schedules in the pre-allocations as well.

An interoperable, multichain network for new use cases and unlimited scale**

• The Verus multi-currency, multi-chain network allows the creation of an unlimited number of interoperable blockchains in the Verus network. Notary IDs, specified at chain definition, provide decentralized blockchain-specific bridge confirmation, enabling public blockchains available to the world for merge mining and staking, as well as private, internal blockchains, which are easy to setup with easy bridging of public currencies into an organization and onto their internal private network and back, with all features and currencies of the public chain but none of the access. There is no limit on the number of blockchains that may continuously operate and interoperate on the Verus network. While there is some overhead for cross notarization, the model for the Verus blockchain network is fractal, enabling an unlimited number of simultaneously operating, interoperable blockchains.

Locking and Unlocking IDs

• Time Lock:
  The unlockatblock parameter defines the unlock height of the identity.

run setidentitytimelock "id@" '{"unlockatblock": <Unlock block height>}'

• Time Delay:
  The setunlockdelay parameter defines how many blocks to delay an ID's unlock when the flags are set back to an unlocked state.

run setidentitytimelock "id@" '{"setunlockdelay": <Unlock block delay>}'

• Revoking an identity will clear its locked status, regardless of time delay or unlock height.
• A locked identity cannot revoke itself.

Conversion Queries

The getcurrencyconverters API retrieves all currencies that have at least 1000 VRSC in reserve, are greater than 10% VRSC reserve ratio, and have all listed currencies as reserves

• E.g. BTC ETH:

run getcurrencyconverters btc eth

Will return all currencies that have btc/eth markets at or above the liquidity threshold.

Sending and Converting Currency

Warning: All testnet coins/currencies have no value and will disappear whenever VRSCTEST is reset

The sendcurrency API can be used to send and convert funds.

• Sending VRSCTEST from a single address (bob@) to a single recipient (alice@):

run sendcurrency "bob@" '[{"currency":"vrsctest","address":"alice@","amount":10}]'

• Sending VRSCTEST from all private wallet funds to two recipients with friendly-name z-addresses (alice@:private and bob@:private):

run sendcurrency "*Z" '[{"currency":"vrsctest","address":"alice@:private","amount":10},{"currency":"VRSCTEST","address":"bob@:private","amount":10}]'

• Converting VRSCTEST to a fractional basket currency, VRSC-BTC using IDs as a funding source:

run sendcurrency "*i" '[{"address":"bob@","amount":10, "convertto":"VRSC-BTC"}]'

• Converting VRSCTEST to another reserve, BTC through a fractional currency, VRSC-BTC:

run sendcurrency "*" '[{"address":"bob@","amount":10, "convertto":"BTC","via":"VRSC-BTC"}]'

• Preconverting to new currency, NEWCOIN, before it is active:

run sendcurrency "*" '[{"address":"alice@","amount":10, "convertto":"NEWCOIN", "preconvert":true, "refundto":"alice@"}]'

• Sending VRSCTEST cross-chain to PBaaSChain:

run sendcurrency "*" '[{"address":"RXLYm4J6qi7yam9zXtkEkRwbvCrnWKGZuv","amount":10, "exportto":"Bridge.PBaaSChain"}]'

• Converting VRSCTEST cross-chain to PBaaSChain:

run sendcurrency "*" '[{"address":"RXLYm4J6qi7yam9zXtkEkRwbvCrnWKGZuv","amount":10, "convertto":"PBaaSChain","exportto":"Bridge.PBaaSChain","via":"Bridge.PBaaSChain"}]'

• Converting PBaaSChain to VRSCTEST:

verus -chain=PBaaSChain sendcurrency "*" '[{"address":"RXLYm4J6qi7yam9zXtkEkRwbvCrnWKGZuv","amount":10, "convertto":"VRSCTEST","exportto":"VRSCTEST","via":"Bridge.PBaaSChain"}]'

Defining a Currency

Currency Options

OPTION_FRACTIONAL = 1                  // allows reserve conversion using base calculations when set
OPTION_ID_ISSUANCE = 2                 // clear is permissionless, if set, IDs may only be created by controlling ID
OPTION_ID_STAKING = 4                  // all IDs on chain stake equally, rather than value-based staking
OPTION_ID_REFERRALS = 8                // if set, this chain supports referrals
OPTION_ID_REFERRALREQUIRED = 16        // if set, this chain requires referrals
OPTION_TOKEN = 32                      // if set, this is a token, not a native currency
OPTION_SINGLECURRENCY = 64             // for PBaaS chains or gateways to potentially restrict to single currency
OPTION_GATEWAY = 128                   // if set, this routes external currencies
OPTION_PBAAS = 256                     // this is a PBaaS chain definition
OPTION_GATEWAY_CONVERTER = 512         // this means that for a specific PBaaS gateway, this is the default converter and will publish prices
OPTION_GATEWAY_NAMECONTROLLER = 1024   // when not set on a gateway, top level ID and currency registration happen on launch chain 
OPTION_NFT_TOKEN = 2048                // single satoshi NFT token, tokenizes control over the root ID

To create a currency of a specific name, you need an ID of the same name. The controller of this ID is the only one who can create a currency of that name, and they can only do so once.
So, let's hypothetically assume I have 3 IDs, one named gold@, one named mycoin@, and one named mike@. I would like to have one currency, gold@,
that I somehow launch in a way that maps it in a way that can be widely trusted to a specific, auditable store of gold.
I also would like to launch a token called mycoin@, which is something like a Kickstarter, where a business, "my", offers to attribute the coins some utility or product value if the purchase exceeds a certain level.
First, I could define the currency "gold" as follows:

run definecurrency '{"name":"gold","options":32,"currencies":["vrsctest"],"conversions":[0.01],"minpreconversion":[1000],"preallocations":[{"mike@":50000000.00000000}]}'

of course, since this is a test currency, I send myself some to start. The identity of the currency must be funded with at least 10 VRSCTEST before sending the transaction returned from this command to
initiate a currency launch that will start at 50 blocks from when it was made (default), and that must have 1000 VRSCTEST preconverted at 0.01 VRSCTEST per GOLD in order to launch.
all of this happens as part of the mining process, since mining the blocks that launch a currency earn the 0.025% conversion fees of participation
in the launch, converting VRSCTEST to GOLD. I could send the following command before the block where GOLD token launches.
After it launches, the only way at present to create new tokens is with a centralized issuance option. To convert VRSCTEST to GOLD, you could issue the command:

run sendcurrency "*" '[{"address":"mike@","convertto":"gold","preconvert":1,"amount":100}]'

that would effectively park my conversion until the token launches, at which point, I will either find 0.975 GOLD in my wallet, or I will have my VRSCTEST back.
Assuming it launches, and I later want to create mycoin, which can be converted to with either GOLD or VRSCTEST, I can create mycoin with:

run definecurrency '{"name":"mycoin","options":33, "proofprotocol":2,"currencies":["vrsctest", "gold"],"minpreconversion":[10000,5.1298]}, "initialsupply":20000'

In "mycoin", I set proofprotocol to 2, which is PROOF_CHAINID. That means that the controller of the chain ID can mint new coins as follows:

run sendcurrency "mycoin@" '[{"address":"mike@","currency":"mycoin","mintnew":1,"amount":10000}]'

Defining a PBaaS blockchain

  {
  "name": "PBaaSChain",
  "options": 264,
  "currencies": [
    "VRSCTEST"
  ],
  "conversions": [
    1
  ],
  "eras": [
    {
      "reward": 1200000000,
      "decay": 0,
      "halving": 0,
      "eraend": 0
    }
  ],
  "notaries": [
    "Notary1@",
    "Notary2@",
    "Notary3@"
  ],
  "minnotariesconfirm": 2,
  "nodes": [
    {
      "networkaddress": "111.111.111.111:10000",
      "nodeidentity": "Node1@"
    },
    {
      "networkaddress": "111.111.111.112:10000",
      "nodeidentity": "Node2@"
    }
  ],
  "gatewayconvertername": "Bridge",
  "gatewayconverterissuance": 1000000
}

The bridge definition has overridable defaults

  {
  "currencies": [
    "VRSCTEST",
    "PBaaSChain",
    "USD"
  ],
  "initialcontributions": [
    380228.12033701,
    0,
    1000000
  ],
  "initialsupply": 3000000
}

Now pass those definitions to definecurrency

run definecurrency '{"name":"PBaaSChain","options":264,"currencies":["VRSCTEST"],"conversions":[1],"eras":[{"reward":1200000000,"decay":0,"halving":0,"eraend":0}],"notaries":["Notary1@","Notary2@","Notary3@"],"minnotariesconfirm":2,"nodes":[{"networkaddress":"111.111.111.111:10000","nodeidentity":"Node1@"},{"networkaddress":"111.111.111.112:10000","nodeidentity":"Node2@"}],"gatewayconvertername":"Bridge","gatewayconverterissuance":1000000}' '{"currencies":["VRSCTEST","PBaaSChain","USD"],"initialcontributions":[371747.20398827,0,1000000],"initialsupply":3000000}'

Exporting an ID to a PBaaS chain

run sendcurrency "*" '[{"address":"IDNAME@","exportto":"PBaaSChainName","exportid":"true","amount":100,"currency":"vrsctest"}]'

Signing transactions from multi-signature IDs (testnet and mainnet)

Create transaction, get raw transaction data:

verus sendcurrency <multi-signature-ID>@ '[{"address":"<destination_address>","amount":<transaction_amount>}]'
verus z_getoperationstatus <operation_id_returned_by_sendcurrency>

Take the raw hex transaction data provided by z_getoperationstatus to each additional wallet(s) containing the additional signing addresses/IDs:

verus signrawtransaction <raw_hex_transaction>

After the last necessary signature is applied, broadcast on the network using:

verus sendrawtransaction <raw_hex_signed_transaction>

Tokenizing ID control (next generation NFT):

The currency definition have flags OPTION_NFT_TOKEN + OPTION_TOKEN, and a max supply of 1 satoshi that is either pre allocated or pre-converted to. If the token is pre-allocated, then the maximum pre-conversion must be 0.

run definecurrency '{"name":"ID","options":2080,"preallocations":[{"ControlTokenRecipient@":0.00000001}],"maxpreconversion":[0]}'

Creating an identity with a fractional currency as its parent

registernamecommitment now takes two more positional arguments to specify a currency parent and a funding address. Use quotes "" to leave fields blank, the example below specifies a parent currency, vrsc-btc , but no referrer. We're now able to use z_addresses to fund the name commitment and identity registration

# run registernamecommitment name controladdress referral parent sourceoffunds
run registernamecommitment subID RDnf7mH7RQki9b7PqdBD2Er6WXv3DTawGr "" vrsc-btc zs1s2mteau9tcalvk55cnepw3aq7dr6w7f447pqqkxczat3a02208d3ersx60wz9srw3nkd25ppfny

Specify the parent in the identity definition. Enter false for returntx to sign and submit the id registration, 0 for the feeoffer to use the default fee, and the funding identity, transparent address, or z-address

# run registeridentity '{ID registration with name commitment}' returntx feeoffer sourceoffunds

run registeridentity '{"txid": "67635331cbccb7a2cbf408a9e97b3f8986133964e0315a8b9fd237a5fd95ac8f","namereservation": { "version": 1,  "name": "ID",  "parent": "i84mndBk2Znydpgm9T9pTjVvBnHkhErzLt", "salt": "b7070f2ca7495e49c85ab41b5a368150e2c217be6d08cc4102a1b682cddb6f01", "referral": ""},"identity":{"primaryaddresses":["RDnf7mH7RQki9b7PqdBD2Er6WXv3DTawGr"],"minimumsignatures":1,"name":"ID","parent":"vrsc-btc@"}}' false 0 zs1s2mteau9tcalvk55cnepw3aq7dr6w7f447pqqkxczat3a02208d3ersx60wz9srw3nkd25ppfny

If a currency's ID issuance require permission from the currency's identity then it must sign the name commitment and identity registration. Either use the parent identity to fund those transactions, or receive a raw transaction to give the identity owner to sign by setting returntx to true

Limitations in multi-currency to be aware of:

1. (GUI and CLI) You will not be able to make a currency from an ID that has a properly encoded i-address as its actual name, not its calculated ID. Generally, the advice is “don’t do that”. Using an i-address when referring to a currency will only be interpreted as referring to the currency or identity which has that i-address calculated based on its name registration. As a general rule, making an ID with an i-address as its name is not prevented by the protocol, but will cause problems whenever an i-address or name may be used (many cases) and will not be supported for creating currencies. To reduce any potential for user confusion, even though the naming system provides will also be expanding the set of characters that will not be allowed for currency registrations.

2. (GUI) If a currency is supported in the Verus Desktop already, such as BTC or ETH, you will not be able to use those same named currencies as a PBaaS chain. This limitation is considered errata for this testnet release and will not be a limitation before mainnet availability.

Disclaimer

This is experimental and unfinished software. Use at your own risk! No warranty for any kind of damage!
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The enclosed copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

MacOS: https://www.virustotal.com/gui/file/a58284a3471329b0e85101167030da688a552374880be64499323603bc9aa428/detection
Linux-x86-64: https://www.virustotal.com/gui/file/bfdc0144706f182903fc3f2ba7be92c3f0b8f90363e2586692d158e7aeecab11/detection
Linux-ARM64: https://www.virustotal.com/gui/file/64a28f392b573a38d0ecc4b4d7e0ebb34d720dc45c66ce683ab4d28712f5c2c5/detection
Windows: https://www.virustotal.com/gui/file/fbcb959c4b7eccce0c13c67be30547bcfc7f219125074e7d4476b187d2bac2be/detection

Avast and Kaspersky may flag the software as "not-a-virus" or "PUP". These are warnings that you are installing mining software, which may be installed by a third party to exploit your PC.
To find out more about the false positives, review the following resources:
https://blog.malwarebytes.com/detections/pup-optional-bitcoinminer/
https://www.kaspersky.com/blog/not-a-virus/18015/

Verifying Downloads

A txt file containing the signer, standard sha256 file checksum, and signature, is included for each download. These packages have been signed with the identity "Verus Coin Foundation Releases@".

1. Extract downloaded archive
2. Verify signature for the extracted app or installer using the extracted textfile.